MCP for Data: Connecting AI 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.
- Data queries, in some catalogs, to run read-only SQL against a source through the catalog's permission checks rather than with a database password.
- Write tools, to add descriptions, tags or owners, for identities allowed to change the catalog.
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.
Marmot's MCP server
Marmot has an MCP server built into the binary at /api/v1/mcp, so it's running as soon as Marmot is. It gives an assistant these tools:
| Tool | What it answers |
|---|---|
discover_data | Finds assets by name, type, provider, tags or metadata |
find_ownership | Who owns an asset, and everything a person or team owns |
lookup_term | Glossary definitions and the assets linked to a term |
explore_data_products | Which data products exist and the assets in each |
explore_teams | Teams and their members |
trace_lineage | What feeds an asset and what depends on it |
update_documentation, manage_tags, manage_owners | Writes descriptions, tags and owners, for identities that can manage assets |
list_queryable_sources, query_data | Runs read-only SQL against a source set up to answer queries |
query_data is what lets an assistant go from "which table holds failed orders" to the rows themselves. Marmot checks the caller's permission to query before the statement reaches the source, refuses anything that isn't a single read, returns the rows without storing them and records the query in the query audit. The source runs the statement with its own credentials, so the assistant never holds a database password. On Marmot Cloud, a statement runs only when every table it reads is covered by one of the caller's grants. We cover the pattern in governed data access for AI agents.
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's no separate package to run, and the Marmot MCP docs have the configuration for Claude Code, Claude Desktop, Cursor, Cline and LibreChat. Clients can also sign in with OAuth instead of an API key, including hosted clients such as claude.ai once you allow their host.
An assistant that signs in with your key has your permissions. An agent that runs on its own should have its own service account, so you can limit what it reaches and see what it did in the query audit. For agents you build in code, Marmot's LangChain and Claude Agent SDK integrations connect to the same catalog, and the Marmot skill teaches coding agents the CLI and API.
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. Marmot's built-in MCP server documents the setup for Claude Code, Claude Desktop, Cursor, Cline and LibreChat, and also accepts OAuth sign-in.
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. When the MCP server can also run SQL, the same rule applies to data: Marmot checks each query against the caller's permissions before it reaches the database and records it in a query audit.
Related
- What Is Data Lineage?
- What Is an AI Context Layer?
- AI Data Engineering: Giving Agents Real Context
- Data Governance
- AI Agent Database Access
- Data Catalogs as the AI Context Layer: A 2026 Comparison
Marmot's built-in MCP server
Marmot ships MCP in the binary. Connect Claude, Cursor, Cline or LibreChat to your catalog and governed queries.