Domain knowledge belongs in the MCP server

97.1% of MCP tool descriptions carry at least one critical "smell" (opaque parameters, unstated limits, missing usage rules) across 856 tools in 103 servers. But fixing the smells isn't the real problem. Most "AI data problems" are documentation problems wearing a different name: the data is fine, what's broken is meaning. MCP isn't dead; most servers are empty. The agent can call every endpoint and understand nothing.

I shipped nine production MCP servers (50+ tools, five MCP Apps) at a 300-400 person Dutch engineering firm, used daily by non-developers through an agent like Claude. A maturity ladder emerged. Most servers just wrap an API. A rare few actually teach the agent the domain, with the knowledge discovered by AI, validated by experts, and living inside the tool description itself. And at the top, servers that render their own interactive apps and write data back, safely. Same data behind a thin wrapper versus a self-teaching tool is an entirely different product in production. This talk is about the one move that changes everything: getting the domain knowledge into the tool.

I'll show how to climb the ladder while you build the tool: scaffold from the API documentation and ship something simple, then run Introspective Context Engineering, a loop of Examine, Flag, Validate, Encode, Iterate. Point an AI at the real data; it flags every pattern by confidence; a domain expert confirms or kills the uncertain ones in an afternoon. Then production telemetry takes over: every call carries a queryIntent, and the logs reveal what the agent thought it was doing, exposing the exact metadata gap. Fixes are minutes, not design cycles.

You'll leave with the maturity model to rank your own servers, the discovery method that makes a self-teaching server reachable in days, and a runnable open-source example.