Skip to content

docs: initial draft of built-in MCP server integration page#35604

Open
bobbyiliev wants to merge 3 commits intoMaterializeInc:mainfrom
bobbyiliev:mcp-docs
Open

docs: initial draft of built-in MCP server integration page#35604
bobbyiliev wants to merge 3 commits intoMaterializeInc:mainfrom
bobbyiliev:mcp-docs

Conversation

@bobbyiliev
Copy link
Copy Markdown
Contributor

@bobbyiliev bobbyiliev commented Mar 24, 2026

Initial draft of the built-in MCP server documentation.

Fixes https://linear.app/materializeinc/issue/DEX-6/mcp-user-documentation

@github-actions
Copy link
Copy Markdown
Contributor

Thanks for opening this PR! Here are a few tips to help make the review process smooth for everyone.

PR title guidelines

  • Use imperative mood: "Fix X" not "Fixed X" or "Fixes X"
  • Be specific: "Fix panic in catalog sync when controller restarts" not "Fix bug" or "Update catalog code"
  • Prefix with area if helpful: compute: , storage: , adapter: , sql:

Pre-merge checklist

  • The PR title is descriptive and will make sense in the git log.
  • This PR has adequate test coverage / QA involvement has been duly considered. (trigger-ci for additional test/nightly runs)
  • If this PR includes major user-facing behavior changes, I have pinged the relevant PM to schedule a changelog post.
  • This PR has an associated up-to-date design doc, is a design doc (template), or is sufficiently small to not require a design.
  • If this PR evolves an existing $T ⇔ Proto$T mapping (possibly in a backwards-incompatible way), then it is tagged with a T-proto label.
  • If this PR will require changes to cloud orchestration or tests, there is a companion cloud PR to account for those changes that is tagged with the release-blocker label (example).

@bobbyiliev bobbyiliev force-pushed the mcp-docs branch 2 times, most recently from acc7f50 to 886d305 Compare March 24, 2026 14:19
@bobbyiliev bobbyiliev marked this pull request as ready for review March 24, 2026 14:20
@bobbyiliev bobbyiliev requested a review from a team as a code owner March 24, 2026 14:20

- [MCP Server](/integrations/llm/)
- [Built-in MCP Server](/integrations/mcp/)
- [MCP Server (Python)](/integrations/llm/)
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not seeing the "(Python)" strangely:
Screenshot 2026-03-24 at 15 31 38
Looking at https://preview.materialize.com/materialize/35604/integrations/llm/

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, that's odd. The link text in _index.md says "MCP Server (Python)", might be a Hugo rendering issue with the sidebar. Let me check the frontmatter on the Python MCP page.

Comment on lines +51 to +52
- [Built-in MCP Server](/integrations/mcp/)
- [MCP Server (Python)](/integrations/llm/)
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems a bit strange to have both, why do we need both? Is one legacy? Which should you use?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 to this, but maybe if we launch in public preview we don't remove the old one quite yet?

I'm also totally fine with removing it as soon as we default the flag to on.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Python one supports stdio and sse transports and also gives users flexibility to either run it or deploy it separately if they don't want to enable it org wide. I'll add a short note clarifying the difference. Agree with Justin that we keep both for now and later on, deprecating the Python one.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@maheshwarip -- is the built-in mcp server launching as public preview? If yes, we probably should include {{< public-preview >}} on the mcp page.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we, per chance, want to create an AI agents folder under integrations folder and put these there? That way, the left hand side can be

Tools and integrations 
      ...
       AI Agents  >
          ...

Doing so ... I think we can later on move the define data products out of the MCP and LLM pages (definitely doesn't need to be done for this PR).

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added a private preview for now since the feature flags default to false. Shall I flip it to public preview? We can upgrade to public preview when we're ready to flip the defaults?

@@ -0,0 +1,469 @@
---
title: Built-in MCP Server
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd recommend splitting up the docs into 1 page for the observatory, and another page for the agentic server!

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree! Makes sense for when we flesh out the observatory docs more. For now both sections are pretty short, want me to split now or once the observatory is more complete?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Short docs are ok! I think it'll be easier to point a customer to the right doc if we have 1 page for each


{{< /tabs >}}

## Define data products
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This section would go into the agent server.

Calling it data products is the right idea. But we use the phrase data products quite a bit with customers. I'd recommend being more verbose, and phrasing this as:

Define and document data products for your agents

The MCP server allows agents to discover and query documented data products. In Materialize, you can make the data product discoverable to customers by creating a Materialized View, adding an index, and adding a comment.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Neat, I like that! Done, rephrased to "Define and document data products for your agents" with the description you suggested.


## Define data products

A data product is any materialized view that has an
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a note of feedback on the product itself: do we really need things to be indexed? Why not just have it be MVs with a comment?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes good question, this is more of a product decision. The index is what makes the data product appear in mz_mcp_data_products today (the view joins on mz_indexes). If we want MVs with just a comment to be sufficient, we'd need to change the underlying view. Worth a follow-up discussion!

'The unique identifier for the order';
```

### 4. Set RBAC permissions {#rbac}
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: I'd rephrase as create a role and permissions for your agent

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done! renamed to "Create a role and permissions for your agent".

GRANT SELECT ON ALL TABLES IN SCHEMA mcp_schema TO mcp_agent;
GRANT USAGE ON CLUSTER mcp_cluster TO mcp_agent;

-- Lock the role to the dedicated cluster and schema
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Huh, this is interesting - I didn't realize we can do this. What does this command do? Does it mean that mcp_agent can only operate with mcp_cluster?
ALTER ROLE mcp_agent SET cluster TO mcp_cluster

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added inline comments explaining it!

It basically allows all queries from that role run on mcp_cluster and only see objects in mcp_schema by default without having to explicitly set the cluster via an options arg.


### `query`

{{< note >}}
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm are we still shipping with the query tool? I'm glad we are if so, but I thought we weren't shipping this!

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's behind a separate flag (enable_mcp_agents_query_tool, default false), so it's not exposed by default. Documenting it here so users know it exists if they opt in. Should I remove this section or add a clearer callout that it's opt-in only?


{{< /tabs >}}

## Feature flags
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd recommend phrasing this as "Enabling / Disabling the MCP endpoints" rather than "Feature Flags"

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done! Just renamed to "Enabling / Disabling the MCP endpoints".

@bobbyiliev bobbyiliev force-pushed the mcp-docs branch 2 times, most recently from b3b3028 to 8b29d50 Compare March 26, 2026 15:39
@bobbyiliev bobbyiliev requested review from def- and maheshwarip March 26, 2026 18:08
* **User ID:** Your email address or service account name.
* **Password:** An [app password](/security/cloud/users-service-accounts/create-service-accounts/).

```
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are we listing the agents endpoint here?

CREATE ROLE mcp_agent LOGIN PASSWORD 'secret';
```

The MCP endpoints are available on the HTTP listener port (default `6876`):
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This might get a bit hidden.

Wondering if we can put it up where we discuss the end points.


Two endpoints are available:

| Endpoint | Path | Purpose |
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we change Purpose -> Description, we could probably include the port info in here.


{{< tab "Self-Managed" >}}

```mzsql
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Q: for sm, is it that it'll be 1 mcp_agent login for all?
Otherwise, we might want to make it more like Cloud and make mcp_agent a functional role and then assign to a particular login role.

'The unique identifier for the order';
```

### 4. Create a role and permissions for your agent {#rbac}
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So ... this doesn't quite fall under your heading of "Define and document data products for your agents".

@bobbyiliev
Copy link
Copy Markdown
Contributor Author

Thanks for the review @kay-kim, just addressed all change requests!

Comment on lines +51 to +52
- [Built-in MCP Server](/integrations/mcp/)
- [MCP Server (Python)](/integrations/llm/)
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@maheshwarip -- is the built-in mcp server launching as public preview? If yes, we probably should include {{< public-preview >}} on the mcp page.

Comment on lines +51 to +52
- [Built-in MCP Server](/integrations/mcp/)
- [MCP Server (Python)](/integrations/llm/)
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we, per chance, want to create an AI agents folder under integrations folder and put these there? That way, the left hand side can be

Tools and integrations 
      ...
       AI Agents  >
          ...

Doing so ... I think we can later on move the define data products out of the MCP and LLM pages (definitely doesn't need to be done for this PR).

weight: 23
---

Materialize includes built-in [Model Context Protocol
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

includes -> provides

That way, if we want to go "Starting in v26.blah, Materialize provides ..."

Materialize includes built-in [Model Context Protocol
(MCP)](https://modelcontextprotocol.io/) endpoints that let AI agents discover
and query your real-time data products over HTTP. No sidecar process or external
server is required. The MCP interface is served directly by the database.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd flip the two sentence:

The MCP interface is served directly by the database; no sidecar process or external server is required.

| **Agents** | `/api/mcp/agents` | Discover and read data products (indexed views with comments). Designed for customer-facing AI agents. Available on the HTTP port (default `6876`). |
| **Observatory** | `/api/mcp/observatory` | Query `mz_*` system catalog tables for troubleshooting and observability. Available on the HTTP port (default `6876`). |

Both endpoints speak [JSON-RPC 2.0](https://www.jsonrpc.org/specification) over
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Both -> The
speak -> use

'The unique identifier for the order';
```

## Create a role and permissions for your agent {#rbac}
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we move this up to Authentication and rename that section Authentication and Access Control (or something).

and query your real-time data products over HTTP. No sidecar process or external
server is required. The MCP interface is served directly by the database.

Two endpoints are available:
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe just make this a heading ## MCP endpoints overview or something?


{{< /tabs >}}

## Enabling / Disabling the MCP endpoints
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wondering if this could go under the endpoints overview section as a child section

| `cluster` | string | Yes | Exact cluster name from the data product details. |
| `sql_query` | string | Yes | PostgreSQL-compatible `SELECT` statement. |

## Observatory endpoint
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd recommend adding more information here about the skills that we expose, as well as sample questions that the user can ask. For instance:

--
After you've connected to the observatory MCP server, your coding agents can answer questions such as:

  1. Why is my my materialized view stale?
  2. Has my source finished snapshotting yet?
  3. How much memory is my cluster using?

@@ -0,0 +1,469 @@
---
title: Built-in MCP Server
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor: I'd title this as MCP Server for Agents and MCP Server for Observability

@@ -0,0 +1,469 @@
---
title: Built-in MCP Server
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Short docs are ok! I think it'll be easier to point a customer to the right doc if we have 1 page for each

clusters, and limits visibility to only the data products you choose to expose.

```mzsql
CREATE CLUSTER mcp_cluster SIZE 'xsmall';
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's use cc sizes here, not tshirt!

@bobbyiliev
Copy link
Copy Markdown
Contributor Author

thanks @maheshwarip! those should be all done now!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants