Exposing pipeline queries as MCP tools automatically

Every data platform eventually grows an integration layer: something wants to ask it questions, so someone writes an endpoint. Then something else wants to ask, so someone writes another.

On one platform I worked on, a pipeline declares its query operations as part of its definition — a typed field on the resource, alongside its stream id, its data sources, and its indexing script, not code in a service. The gateway reads those declarations and exposes each one as an MCP tool over JSON-RPC, with no gateway code written per pipeline. The exposure happens at deploy time: the moment the resource applies, the tools exist.

Nobody writes the integration. Declare five query operations and an external LLM can call five tools — in the vertical I owned, a semantic-tree lookup, three social-graph questions ("what are people talking about," "what do people care about," "what do people want"), and a user-detail lookup, each with the same authorization the pipeline already had.

The property worth noticing is that the tool surface cannot drift from the pipeline, because it is generated from the same declaration that defines the pipeline. There is no second artifact to keep in sync, and no possibility of a tool that describes an operation the pipeline no longer performs. The usual failure — a tool schema that still advertises a filter someone deleted three sprints ago — isn't fixed here, it's unrepresentable.

The cost is that your query operations have to be describable — named, typed, and meaningful to a model without surrounding context — which is a real constraint on how you factor a query layer. A generic "run this filter" operation is easy to declare and useless to expose. And every declared operation is exposed by default, so restriction is opt-out rather than opt-in: we had to explicitly fence off the ones we didn't want an external model calling. Automatic exposure cuts both ways, and the direction it cuts is toward more surface than you meant to publish.