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 I described why this fails for enterprise data. Here's the maturity ladder that emerged after building seven production servers with 52 tools across nine APIs.
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.
Level 4: Self-Teaching (<2%)
The domain knowledge is in the tool description and the input/output schemas — the only channels the agent reads reliably on every call. 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.
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.
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?"
For the full pattern — the five-phase method for getting to Level 4, the feedback architecture, and six recommendations for the MCP spec — grab the white paper.