Skip to main content

Model Context Protocol (MCP)

Every deployed data product serves a Model Context Protocol (MCP) endpoint on the same base URL as the rest of the data plane. You do not enable it separately: if the product is running, its APIs are available to MCP clients as tools.

What you get​

  • One MCP tool per API operation defined in the data product. Tool names, titles, descriptions, and JSON input/output schemas come from the published manifest, so assistants and agents see the same surface you get from generated clients.
  • The same auth and identity model as HTTP and gRPC: callers present a valid Bearer token (for example Authorization: Bearer <jwt>) from your configured identity provider. The server enforces the same authorization as a direct API call.
  • JSON request and response bodies for tool calls: arguments map to the operation’s request type; results are returned as structured content suitable for MCP clients.

Endpoint​

MCP is mounted under /mcp on the data product’s HTTP endpoint (the host the control plane assigns to your product in a given region). For example, if your product is available at https://orders.example.com, the MCP scope is served from that host under the /mcp path (see your environment’s routing for the exact URL your clients should use).

Use this when you connect an MCP-compatible client (IDE extensions, assistant runtimes, or other tools that speak MCP over HTTP).

When to use MCP vs client libraries​

Use casePrefer
Production services, batch jobs, typed application codeClient libraries (per-language guides below)
AI assistants, coding agents, exploratory calls from MCP hostsMCP on the data product URL
Ingest/outlet streaming, lowest-level controlClient libraries or, for exceptional cases, the wire protocol reference

MCP exposes API operations as tools. It does not replace streaming ingest/outlet clients; use the official libraries for append and read streams.

External: Model Context Protocol specification.