Skip to main content

MCP for Data: Connecting AI Agents to Your Catalog

← All resources

MCP for data, connecting agents to your catalog

The Model Context Protocol (MCP) is an open standard for connecting AI assistants to external systems, including data catalogs, through a common interface. For data teams it is the cleanest way to let tools like Claude and Cursor read governed context about your stack.

This guide explains what MCP is, how it works with a data catalog, how it compares to a plain API, and how to connect an assistant to your catalog.

What is MCP (Model Context Protocol)?​

MCP is an open standard that lets AI assistants discover and call tools exposed by an external system, over one common interface. Before MCP, wiring an assistant to your metadata meant a bespoke integration per tool. MCP standardises it: the system exposes tools the model can discover and call, so Claude, Cursor, ChatGPT and others reach the same context without custom glue for each.

For a data catalog, this is what turns it into a live context source for agents rather than a UI people log into. The catalog publishes its capabilities as MCP tools, and any MCP-aware assistant can use them.

How MCP works with a data catalog​

A catalog exposes its context as MCP tools, and the assistant calls them on demand. In practice there are three moving parts:

  • The catalog runs an MCP server that describes its tools, for example search assets, find ownership and traverse lineage.
  • An MCP client inside the assistant connects and authenticates, usually with an API key.
  • The model chooses which tools to call from a natural language request, and the catalog returns context scoped to the key's permissions.

So a question like "who owns the orders table and what feeds it" becomes a couple of tool calls against the catalog, answered from live metadata rather than the model's guesses.

What an MCP server for a catalog exposes​

The exact tools vary by product, but a catalog's MCP server typically offers:

  • Search and discovery, to find assets by name, type or domain.
  • Ownership lookup, to answer "who is responsible for this".
  • Lineage traversal, to follow what feeds an asset and what depends on it.
  • Glossary lookup, to resolve business terms to their agreed meaning.

Each call returns context scoped to the caller, so the assistant works with governed data, not a raw export.

MCP vs API​

Both matter, and they serve different callers. A REST API is best for deterministic automation you control, where your code knows exactly which endpoint to hit. MCP is best for AI assistants, because the tools are described to the model and it decides what to call from a natural language request.

A good catalog offers both, with the MCP server wrapping the same API and the same governance. That way a pipeline can call the API directly while an assistant reaches the identical context over MCP, and neither sees more than its credentials allow. We go deeper on giving agents context in AI data engineering.

Native MCP vs a separate MCP server​

Some catalogs build MCP into the product, others ship it as a separate package. With native MCP the server is part of the catalog, so it is available the moment the catalog runs, with nothing extra to deploy or version. A separate MCP server is a distinct component you install and keep in step with the platform.

Both speak the same protocol to assistants, so the difference is operational rather than functional: one fewer moving part against an additional service to run. It is one of the axes we compare across tools in Data Catalogs as the AI Context Layer.

How to connect a data catalog to Claude or Cursor​

If the catalog has an MCP server, connecting an assistant is a short, standard setup. The shape is the same across clients:

  • Get an API key from the catalog, scoped to what you want the assistant to access.
  • Point the MCP client in Claude Desktop, Claude Code, Cursor or Cline at the catalog's MCP endpoint.
  • Authenticate with the key, and the assistant discovers the catalog's tools.

From there the assistant can query assets, ownership and lineage in natural language, scoped to that key. Marmot ships its MCP server in the binary, so there is no separate package to run; the Marmot MCP docs walk through the exact steps.

Frequently asked questions​

What is the Model Context Protocol (MCP)?​

The Model Context Protocol (MCP) is an open standard for connecting AI assistants to external systems, including data catalogs, through a common interface. The system runs an MCP server that describes the tools it offers, and the assistant's MCP client connects and calls them. It means a tool like Claude or Cursor can reach your data context without a bespoke integration built for each one.

How does MCP work with a data catalog?​

The catalog runs an MCP server that exposes tools such as search assets, find ownership and traverse lineage. An MCP client inside the assistant connects and authenticates, usually with an API key. The model chooses which tools to call from a natural language request, and the catalog returns context scoped to that key's permissions, so the assistant can answer questions about your data without a custom connector.

What is the difference between MCP and a REST API?​

A REST API is best for deterministic automation you control, where your code knows exactly which endpoint to call. MCP is best for AI assistants, because the tools are described to the model and it decides which to call from natural language. They are complementary: a good catalog exposes a stable API and an MCP server that wraps the same governed data, so both callers reach it.

How do I connect a data catalog to Claude or Cursor?​

If the catalog has an MCP server, you point the MCP client in Claude Desktop, Claude Code, Cursor or Cline at the catalog's MCP endpoint and authenticate with an API key. The assistant then discovers the catalog's tools and can query assets, ownership and lineage in natural language, scoped to the permissions of the key you provided.

What is the difference between native MCP and a separate MCP server?​

Native MCP means the server is built into the catalog, so it is available the moment the catalog runs, with nothing extra to deploy. A separate MCP server is a distinct package you install and version alongside the platform. Both expose the same protocol to assistants; the difference is operational, one fewer moving part with native MCP versus an additional component to run and keep in step.

Is MCP access to a data catalog secure?​

It can be, when access is scoped at the point of the query. A well-designed catalog authenticates the MCP client with an API key and returns only what that key is permitted to see, never a raw dump of the whole catalog. That means an agent connected over MCP stays inside the same permissions a person with that key would have.

Marmot's built-in MCP server

Marmot ships MCP in the binary. Connect Claude, Cursor or Cline in minutes.

Read the MCP docs
Last updated on