The boring part of an AI tool may be the part that decides whether the agent works.
Model Context Protocol, usually MCP, has become the popular way to connect AI applications to external systems: files, calendars, cloud resources, browser automation, databases, ticket trackers and custom internal tools. The official MCP documentation describes it as an open-source standard that lets AI apps connect to data sources, tools and workflows. Microsoft and Google Cloud now publish their own MCP server documentation, which tells you how quickly this has moved from experiment to enterprise plumbing.
But a new grading project from developer Teng Li points at the part that will separate useful agent tools from frustrating ones. After scanning 36 popular MCP servers for agent usability, Li reported that roughly a third received a D or F. The dominant issue was not that the protocol could not connect. It was that tool definitions were too vague for a model to use reliably.
GearPulse’s read: this is relevant because MCP is becoming the app store for agents, but agents do not browse tools like humans. They read names, descriptions, parameters and schemas. If those labels are lazy, the model’s judgment gets worse before the task even starts.
Spec compliance is not enough
This is the trap. A server can implement MCP and still be bad at communicating with an agent.
The Reddit summary for the mcpgrade scan says the most common failure was parameters without descriptions, with examples where one server had 132 of 134 reported errors from missing parameter descriptions and another had 110. It also says an archived, hand-documented Slack server scored better than some actively maintained servers. That is the kind of result that should make tool builders uncomfortable.
The lesson is not that one leaderboard is final truth. It is that agents are extremely sensitive to the semantic contract a tool exposes.
| What a human sees | What an agent sees |
|---|---|
| A product name and a familiar service | Tool names, descriptions and JSON schemas. |
| A settings page or docs site | Whatever the MCP server exposes in tools/list. |
| Trial and error across a UI | A one-shot or multi-step plan based on imperfect metadata. |
| ”This is obvious from context” | Ambiguity that may trigger the wrong tool or no tool. |
If an MCP server exposes a tool called run, a parameter called id and a vague description like “execute task,” the agent has to infer too much. Sometimes it will guess correctly. Sometimes it will burn context, ask the user unnecessary questions or take an action that looked valid but was semantically wrong.
The security angle is not theoretical
Recent MCP research makes the same point from a sharper direction. One arXiv paper on misleading tool descriptions argues that MCP tool descriptions are the primary semantic interface agents use to understand what a tool can do. The researchers found that mismatches between descriptions and implementation can create a security risk, especially because MCP servers often run locally with meaningful privileges.
That does not mean every bad description is malicious. Most are probably ordinary software sloppiness: rushed wrappers, auto-generated schemas, copied examples, missing parameter docs, overloaded tools and giant catalogs. But the effect can still be serious.
An agent does not have human common sense about your internal tool. It has a language model, a schema and whatever instructions the server exposes. Bad labels are not cosmetic. They are part of the control surface.
Big clouds are teaching the shape of mature MCP
Microsoft’s Azure MCP Server documentation and Google Cloud’s MCP server overview show where this is going. Both frame MCP as a structured way for AI agents and clients to interact with real cloud resources, with authentication, access control and supported tool lists around it.
That is the right direction. Cloud tools are powerful. They can list resources, query logs, inspect configuration and sometimes deploy or modify infrastructure. The more serious the action, the more important the tool contract becomes.
| Mature MCP behavior | Why it helps |
|---|---|
| Clear tool names | Reduces accidental selection. |
| Parameter descriptions | Helps the model fill inputs correctly. |
| Narrow toolsets | Keeps context smaller and intent clearer. |
| Auth and RBAC | Limits what the agent can do even when prompted badly. |
| Useful error messages | Lets the agent recover instead of silently failing. |
| Output schemas | Helps multi-step workflows stay grounded. |
This is where the ecosystem needs to grow up. The best MCP servers will not be the ones with the longest tool lists. They will be the ones that make the next correct action obvious.
What builders should take from this
If you are building an MCP server, do not treat the schema as boilerplate. Treat it like interface design.
Start with fewer tools. Name them like verbs a careful teammate would understand. Describe when to use them and when not to use them. Give every parameter a plain-English description. Return stable identifiers and compact state. Make errors actionable. Keep destructive operations behind explicit guardrails. Test with real agents, not just unit tests that prove the server responds.
For teams adopting third-party MCP servers, the buyer checklist should also change. “Does it connect?” is the first question, not the last one.
| Before enabling a server | Ask this |
|---|---|
| Tool catalog | Are there too many tools for the agent to choose from safely? |
| Descriptions | Could a newcomer understand each tool from metadata alone? |
| Permissions | What can the server read, write, delete or deploy? |
| Failure modes | Do errors help the agent correct itself? |
| Maintenance | Is the server actively tested against real client behavior? |
That may sound fussy, but it is the difference between an agent that feels competent and one that feels haunted by its own integrations.
Bottom line
MCP is useful because it gives AI agents a common way to reach real tools. That is also why sloppy MCP servers are a bigger problem than sloppy docs.
My take: the next wave of agent tooling will be judged less by how many integrations it advertises and more by how clearly those integrations speak to the model. Good labels, narrow tools and honest permissions are not polish. They are the interface.