--- title: "The Six Levels of MCP Servers" description: "Not all MCP servers are the same. How the types differ, as a six-level ladder from hollow API wrappers to apps that write back. Drawn from eleven in production." canonical: "https://davidgolverdingen.nl/en/insights/six-levels-of-mcp-servers" last-updated: "2026-09-29" --- # The Six Levels of MCP Servers Most MCP servers do the same thing: wrap an API, expose tools with one-sentence descriptions, and hope the model figures out the rest. In [a previous post](https://davidgolverdingen.nl/en/insights/your-data-is-fine) I described why this can fail for enterprise data. Here's the maturity ladder that emerged from an eleven-server, 90+ tool production snapshot across eleven APIs. I call it the **six-level MCP maturity model**. It classifies an MCP server by how much of the domain the server itself carries, on a ladder from Level 1 API Mappers, which expose bare endpoints and leave the model guessing, to Level 6 Secure Write Apps, which act on the system of record. I derived the six levels in 2026 from eleven production servers running at a Dutch HVAC installation company. Two different samples are at work below, and it is worth keeping them apart. The *ladder* comes from that eleven-server snapshot. The *share* column does not: those percentages come from reviewing 50+ publicly available MCP servers in March 2026, so they describe the public ecosystem, not my own estate, and they're a snapshot, not a tracked metric. Eleven servers could not tell you what 10,000 are doing. [The Missing Layer](https://davidgolverdingen.nl/en/the-missing-layer) sets out that review in full, with named examples at every tier. | Level | Name | Share of servers | What the server carries | | --- | --- | --- | --- | | 1 | API Mapper | ~70% | Endpoint names and nothing else | | 2 | Functional | ~20% | Grouped tools, longer descriptions | | 3 | Metadata-Rich | ~8% | Curated knowledge sitting next to the tool | | 4 | Self-Teaching | <2% | Domain knowledge inside the descriptions and schemas | | 5 | Interactive App | emerging | Rendered UI returned by the server | | 6 | Secure Write App | frontier | Validated writes back to the system of record | ## The types of MCP servers and how they differ They differ along a single axis: how much of the domain the server carries, versus how much it leaves the model to guess. That is what separates one type from the next. Each level below hands the model something the previous one withheld — starting from bare endpoint names, through typed metadata and descriptions that teach the model how to query, up to interactive apps that write back to the system of record. ## Level 1: API Mapper (~70% of servers) One tool per endpoint. One-sentence descriptions. No domain context. The model figures everything out alone from the tool name. Ask *"which projects are running over budget?"* and it will happily invent a filter, hit an empty endpoint, and tell you everything is fine. ## Level 2: Functional (~20%) Tools are grouped sensibly. Descriptions are longer. Someone thought about how a human would use this. Still no domain knowledge, no cross-tool references, no query strategies. This is the ceiling most commercial MCP implementations aim for today. ## Level 3: Metadata-Rich (~8%) Knowledge graphs, glossaries, data catalogs. The metadata is real, but it lives next to the tool rather than inside it, and it was typically curated by hand over weeks or months. In practice, manual curation doesn't scale, and the agent only reads it if it happens to call the right meta-tool. I built two of these layers (MCP Resources and a parameterless "guide" tool) and removed both after testing. No Claude client ever requested them unprompted. *Updated September 2026:* the guide tool deserved a second look. In later evals it was called 10 times in 10 once the description said "REQUIRED: call this first", against 0 in 10 for a soft hint ([Q8b](https://github.com/DaveGold/mcp-metadata-demo/blob/main/.claude/skills/rich-domain-mcp-server/references/evidence.md#delivery)). Unprompted it still goes unused; required, it works. ## Level 4: Self-Teaching (<2%) The domain knowledge is *in what the model actually receives*: the field names, the head of the tool description, the input schema, and the tool's response. Output schema validates the response, but no Claude host passes it to the model; only Codex and ChatGPT Work do ([Q11, HD](https://github.com/DaveGold/mcp-metadata-demo/blob/main/.claude/skills/rich-domain-mcp-server/references/evidence.md#delivery)). *Updated September 2026:* this used to say the description and input schema are the only reliable channels. Measured on Claude Code, only the first 2,048 characters of a description arrive, so the rules for reading a result now travel in the response ([Q7, Q15](https://github.com/DaveGold/mcp-metadata-demo/blob/main/.claude/skills/rich-domain-mcp-server/references/evidence.md#delivery)). And that knowledge wasn't written by humans scanning documentation; it was discovered by an AI examining real data, flagged with confidence levels, then validated by domain experts. I called the pattern **Introspective Context Engineering for MCP**. The difference is not subtle. A Level 1 server says *"query data from the ERP."* A Level 4 server says *"always start with `summaryOnly=true`, active projects accumulate thousands of records. Type codes determine which fields are populated. Use `get_budget` for planned costs, this tool for actuals. Report friction via `report_problem`."* Not the same product. Not the same category. ## Level 5: Interactive App (emerging) The server doesn't just return data. It returns **rendered UI**. Interactive charts, sortable tables, clickable maps, typed forms, all drawn by the server and displayed inline in the conversation. The agent coordinates; the server controls presentation. A table of 400 rows in a markdown code block is unreadable. A rendered, sortable, filterable table is a tool a business user can actually use. Level 5 is where the interface meets the user where they are. Working examples from an open-source demo server: [`render_chart`](https://github.com/DaveGold/mcp-metadata-demo/blob/main/src/tools/render-chart.ts) and [`render_table`](https://github.com/DaveGold/mcp-metadata-demo/blob/main/src/tools/render-table.ts), each a self-describing tool whose schema teaches the agent how to configure the view, no wrapper logic required. ## Level 6: Secure Write App (frontier) The server doesn't just read, it writes. Carefully. Two patterns: **agent-initiated bounded writes** for low-risk mutations (feedback, scores) through standard tools, and **user-initiated secure writes** for business-critical data through validated MCP App interactions. I call this the **WriteIntent pattern**: agent opens the door, user walks through it, server checks every step. Almost nobody is here yet. Most builders are still nervous about giving MCP servers write access at all, and until Level 6 patterns exist, they should be. ## The progression **Expose data (1) → organize tools (2) → understand the domain (3) → learn from data and feedback (4) → present through interactive apps (5) → act through secure writes (6).** Most of the public MCP ecosystem is stuck between 1 and 2. MCP isn't dead. Most MCP servers are empty. A different transport doesn't fix that; filling the tool interface with real domain knowledge does. If you're building an MCP server today, the most useful question isn't *"which framework should I pick?"* It's *"what level is mine, and what does Level N+1 look like?"* --- This post is one piece of a longer argument. [*Production MCP: A Practitioner's Guide*](https://davidgolverdingen.nl/en/insights/production-mcp-practitioners-guide) puts all of them in order, from understanding your data through to identity-bound deployment. Go deeper: read the full practitioner report, [*The Missing Layer*](https://davidgolverdingen.nl/en/the-missing-layer), or explore the [mcp-metadata-demo](https://github.com/DaveGold/mcp-metadata-demo) server, an open-source extract of these patterns, since the production servers run on private business data.