Skip to content
AvelinLabs

MCP

MCP is an access mechanism for Avelin decision intelligence. It is not the product core and does not own Customer Grounding.

What Problem Does MCP Solve?

Section titled “What Problem Does MCP Solve?”

Applications can call Avelin through REST. AI clients and agent workflows often benefit from a tool-oriented interface. The Avelin MCP adapter makes selected Runtime API capabilities available as MCP tools without duplicating decision logic.

Current Controlled-Beta Model

Section titled “Current Controlled-Beta Model”

The controlled-beta release uses a customer-operated, client-side stdio adapter:

MCP client
    |
    | stdio
    v
Customer-operated Avelin adapter
    |
    | authenticated HTTPS
    v
Avelin Runtime API
    |
    v
Avelin Decision Layer

The customer runs the adapter in their own MCP client environment and configures it with:

  • AVELIN_MCP_API_BASE_URL;
  • AVELIN_MCP_RUNTIME_API_KEY;
  • optional AVELIN_MCP_REQUEST_TIMEOUT_SECONDS.

The Runtime API Key contract must allow the endpoint family used by the selected tool.

Current Tool Areas

Section titled “Current Tool Areas”

The adapter exposes selected job, occupation, market, Role Intelligence, and Customer Grounding operations.

Customer Grounding tools cover:

avelin_list_grounding_sources
avelin_register_grounding_source
avelin_ingest_grounding_text
avelin_generate_grounded_role_intelligence
avelin_get_grounding_trace
avelin_disable_grounding_source
avelin_delete_grounding_source

The current MCP ingestion tool accepts text or Markdown. Use the authenticated REST API for controlled-beta file ingestion.

See the MCP stdio launch guide, client configuration, and tool-call examples.

What the Adapter Does

Section titled “What the Adapter Does”

The adapter:

  • maps tool calls to authenticated Runtime API requests;
  • propagates a request identifier;
  • returns Runtime API decision outputs;
  • preserves runtime ordering and product semantics;
  • emits structured operational events without raw keys, source text, role context, prompts, or full payloads.

What the Adapter Does Not Do

Section titled “What the Adapter Does Not Do”

The current adapter does not:

  • read customer repositories or local documents directly;
  • parse or upload files independently;
  • query SQL or vector stores;
  • create or revoke Runtime API Keys;
  • call admin or internal control-plane APIs;
  • own retrieval, evidence selection, policy evaluation, or scoring;
  • provide shell or filesystem-write tools.

Tenant scope comes from authenticated account context. MCP tool input does not accept customer_id.

No Hosted Daemon or Remote Service

Section titled “No Hosted Daemon or Remote Service”

Avelin does not currently operate:

  • an Avelin-hosted MCP daemon;
  • a remote MCP service;
  • a managed remote MCP transport;
  • an MCP-owned grounding system.

The production-validated model is the customer-operated stdio adapter over the authenticated Runtime API. Documentation or examples that refer to an MCP server describe the local adapter process, not a hosted Avelin service.

Why It Is Different

Section titled “Why It Is Different”

MCP remains thin and replaceable. The Decision Layer owns grounding, evidence, confidence, review guidance, and decision semantics. The adapter exposes those capabilities without creating an MCP-specific version of the product.

This design keeps REST as the stable integration contract and allows applications and agents to receive consistent results across access channels.

Future Direction

Section titled “Future Direction”

Future MCP transports, hosted delivery models, or governed external-tool scenarios may be evaluated separately. They are roadmap possibilities, not commitments or current availability.

Any future model would require explicit review of authentication, tenant isolation, observability, auditability, transport behavior, and operational ownership before it could be documented as supported.

Next Steps

Section titled “Next Steps”