What AI Agents Gain From an MCP Server on a Data Catalog

What goes wrong when an AI agent only sees raw tables?

An agent that only sees raw tables has to infer meaning from names, and names are a poor record of meaning. Ask it for "active customers last quarter" and it finds customers, dim_customer, crm_accounts_v2 and a column called status_cd. It picks the most plausible combination, writes SQL that runs, and returns a confident number. Nothing in the schema tells it that finance counts a customer as active only after the first paid invoice, that dim_customer is the certified table, or that crm_accounts_v2 was deprecated last spring.

The failure is quiet. The query succeeds, the number looks reasonable, and a second agent built by another team picks a different table and returns a different number. We have described why this breaks natural-language analytics in why text-to-SQL breaks in the enterprise. The short version: the information the agent needs exists in the organization, but it lives in a data catalog, a business glossary and people's heads, not in the warehouse schema.

The Model Context Protocol (MCP) is how agents reach systems they were not built for. An MCP server exposes a system's capabilities as tools an agent can discover and call. Point one at the warehouse and the agent can run queries. Point one at the catalog and the agent can find out what it should query in the first place.

What does an MCP server on a data catalog give an agent?

A catalog MCP server gives an agent the context that sits around the data: definitions, ownership, lineage, classification and status. Each answers a question the agent cannot answer from the tables alone.

The last row is where a catalog adds the most. A warehouse knows its own objects very well, and modern platforms add good semantic models for them. A catalog that connects the warehouse to the source systems, the transformation code and the BI layer can tell the agent that the "revenue" in a dashboard and the "revenue" in a semantic view are, or are not, the same thing.

How does an agent use catalog context to answer a question?

The agent treats the catalog as its first stop: it resolves the business terms in the question, picks the right data and only then queries it. Take a question a commercial director might ask an internal assistant: "How many active customers did we have in Germany last quarter, and how does that compare with the year before?"

1. Resolve the term. The agent searches the catalog for "active customer" and finds the glossary term. The definition says a customer is active after a paid invoice in the last twelve months, and it links to the tables and the semantic model that implement it.
2. Choose the source. Of the customer tables, one is documented, approved and linked to the term. Another is marked as deprecated. The agent uses the approved one.
3. Check the scope. The term's attributes show that country is taken from the billing address, not the shipping address. The agent filters accordingly.
4. Check sensitivity. The customer table carries a PII classification on contact fields. The agent aggregates and leaves those fields out.
5. Query the data. Only now does it call the warehouse, through its own MCP server or another interface, with one targeted query.
6. Answer with provenance. The reply states the definition it used, the source table and the owner to contact if the number looks wrong.

Steps one to four are all reads against the catalog, and they are cheap compared with the cost of a wrong number in a board deck. They also make agents consistent with each other. Two assistants built by two teams, asked the same question, resolve the same term to the same definition and the same table.

The same pattern helps coding agents. Before renaming a column or changing a dbt model, an agent can trace lineage downstream through the catalog and list the reports and data products that would be affected, which turns impact analysis from an investigation into a lookup.

Catalog MCP server vs warehouse MCP server

A warehouse MCP server answers "what is the number", a catalog MCP server answers "what does the number mean and can I trust it". Most data platforms now offer the first kind. The Snowflake-managed MCP server, for example, exposes Cortex Agents, Cortex Analyst, Cortex Search and SQL execution as tools, with Snowflake's role-based access control behind every call. It is a strong way to put Snowflake data in front of agents.

A catalog MCP server complements it. It covers the metadata of every connected platform, so the definitions, owners and lineage it returns are the same whether the data sits in Snowflake, Databricks, a transformation project or a BI tool. Agents that answer business questions usually need both, one to decide what to ask and one to ask it. For how the two protocols for agents relate, see MCP vs A2A, and for where agents themselves should run, see build AI agents where your data lives.

How do you govern what agents read from the catalog?

A catalog holds sensitive knowledge too: who owns what, which tables contain personal data, sample rows and internal documentation. Exposing it to agents is a governance decision, and the MCP specification gives a clear model for it. A remote server acts as an OAuth 2.1 resource server, accepts only tokens issued for it, and must validate tool inputs, enforce access controls, rate limit invocations and sanitize outputs. Clients are asked to confirm sensitive operations and log tool usage.

For a catalog specifically, five controls matter most:

• The agent acts as the user. Every call runs with the signed-in user's identity and permissions, so an agent never sees catalog content its user could not open in the browser.
• Tools follow the role. The tool list itself is filtered, so a viewer's agent is never offered write tools it cannot use.
• Read and write are separate. Each tool is either read-only or read-write, which makes it possible to run the server read-only for most users.
• Administrators can narrow the surface. An environment-wide allowlist decides which tools exist at all, and users can narrow their own set further.
• Results are bounded and calls are logged. Paged, field-selected results keep responses small, and logging tool calls on the client or a gateway shows which agent asked what, for whom.

These controls are part of AI agent governance. The catalog is also where the rest of that program lives: the inventory of AI-approved assets, their owners and their classifications.

Can AI agents write back to a data catalog?

Yes, and for data stewards this is often where an MCP server saves the most time. Documentation is the work catalogs never have enough people for. An agent with write tools can draft descriptions for undocumented tables, propose glossary terms from a list, or find every object with "customer" or "client" in its name and apply a PII label and a GDPR classification. Work that used to be a quarter-long cleanup project becomes a supervised afternoon.

Supervised is the important word. Write access should be narrower than read access, limited to the people responsible for the content, and run with their own permissions. New content should land in a review state so a human approves it before it becomes the approved definition that other agents will rely on. An agent that writes a wrong definition into the glossary does more damage than one that answers a single question wrong, because every other agent will repeat it.

How the Dawiso MCP server works

Dawiso combines a data catalog, a business glossary and interactive data lineage in one platform and serves them to agents through the Dawiso MCP server. According to the Dawiso documentation:

• Read tools. Agents can search objects by name, full text or label, or run a semantic search over the catalog when Ask Dawiso AI is enabled. They can trace lineage upstream and downstream from an object, read its attributes, workflow state, concepts and attachments, and see which spaces, applications and object types exist.
• Write tools. Agents can create, update and delete objects, publish concepts in bulk, change workflow states, add comments and labels, apply classifications such as PII or GDPR, and, for administrators, manage spaces, applications and permissions.
• Role-filtered tools. tools/list returns only the tools the connecting user's role permits: read tools for viewers, read and write tools for contributors, the full set for administrators. Each tool is strictly read-only or read-write.
• Configurable write access. The server can run read-only, with full write access, or with write tools limited to chosen users and groups. Administrators keep an environment-wide allowlist and each user can narrow their own tools further.
• Compact results. List and search tools page at 20 items by default, up to 100, and accept parameters that choose how much detail and which fields come back.
• Same identity as the user. MCP uses the same API endpoint and authentication as Dawiso users, write tools still need a role that permits them and act only with the user's own permissions, and a change to a user's role or password takes effect for their connected AI tools too.

It is a remote server reached at the environment's /api/mcp endpoint, and any MCP-compatible agent can connect to it. Dawiso documents the setup of an organization-wide connector for Claude Enterprise and Team, and its MCP documentation also names Cursor as a client. The MCP server has to be activated for a customer environment. It is available for cloud customers, and on-premises customers contact their Customer Success Account Manager about support.

In practice, Seznam.cz connected its internal conversational analytics tool to Dawiso over MCP, so the tool asks Dawiso for the company's own definitions, ownership and the right data sources before it composes a query. According to the Seznam.cz case study, Dawiso governs 681,000 objects for the company, and the rollout counted 31 MCP users and more than 9,000 MCP calls during implementation.

How to connect AI agents to your data catalog

1. Start with the questions agents get wrong. Collect the metrics and terms that produce inconsistent answers today. They are the first glossary entries worth getting right.
2. Make the catalog worth reading. Each of those terms needs an approved definition, an owner, a link to the data that implements it and a status that marks trusted and deprecated assets.
3. Classify what is sensitive. Apply PII and other classifications before agents arrive, so they inherit the rules instead of discovering the data.
4. Connect read-only first. Give agents read tools under each user's identity. Add write tools later, for stewards, with a review step.
5. Instruct agents to ask the catalog first. In the agent's system prompt or configuration, make resolving terms and sources in the catalog the step before any query.
6. Watch the calls. Review which tools agents use and which questions come back empty. Gaps in the answers are a to-do list for the catalog.

For the protocol itself, see the complete guide to MCP. For the wider architecture an MCP server on a catalog belongs to, see how to implement an enterprise context layer for AI.

Sources

• Model Context Protocol, Specification 2026-07-28, Tools (security considerations for servers and clients)
• Model Context Protocol, Specification 2026-07-28, Authorization
• Snowflake Documentation, Snowflake-managed MCP server
• Dawiso Help, Dawiso Model Context Protocol (MCP)
• Dawiso Help, AI agentic tools: Example settings
• Dawiso, Seznam.cz case study