An AI host is the application that runs MCP servers for a person, such as Claude, ChatGPT, VS Code or Gemini CLI, and each host adds its own rules to the MCP specification. The Model Context Protocol has one specification and many hosts, and the hosts’ rules do not agree with each other. While reviewing the tools that test MCP servers, our founder, Amir Pournasserian, collected the rules as they stood on 1 October 2026. The full rulebook, host by host with sources, is on his site. This note is what we took from it for client work.
What rules does each host add?
| Host | Examples of rules it adds | Source |
|---|---|---|
| MCP specification | Tool names of 1 to 128 characters; a valid input schema; input errors returned as results, not failures | Specification: tools |
| Claude connector directory | Names of 64 characters or fewer; every tool has a title plus a read-only or destructive hint; read and write split into separate tools; no prompt-injection patterns; reasonably sized responses | Review criteria |
| Claude apps and Claude Code | About 150,000 characters per tool result in the apps; 25,000 tokens by default in Claude Code | Connector docs, Claude Code docs |
| ChatGPT and Codex plugins (formerly apps) | Read-only, destructive and open-world hints set explicitly on every tool, and hints that do not match what the tool does are a common cause of rejection; non-promotional descriptions; minimal inputs | Plugin guidelines, review requirements |
| Codex | A 10-second startup timeout and a 60-second tool timeout by default | Codex MCP docs |
| VS Code with Copilot | At most 128 tools enabled per chat request | VS Code docs |
| Windsurf | 100 tools in total | Windsurf MCP docs |
| Kiro | Names of at most 64 characters including the server prefix, letters, digits and underscores only, starting with a letter | Kiro docs |
| Gemini CLI | Names over 63 characters are truncated; some schema keywords are stripped | Gemini CLI docs |
Where do the hosts conflict?
Name length. The specification allows 128 characters. The Claude directory and Kiro stop at 64, and Kiro counts the server prefix. Gemini CLI does not reject a longer name; it truncates at 63, which is worse, because the server never finds out.
Characters. The specification permits hyphens and dots in names. Kiro permits neither. A name that is valid everywhere else fails there.
Annotations. The read-only, destructive and open-world hints are optional in the specification. Claude’s directory requires a title and a read-only or destructive hint on every tool. ChatGPT requires all three, set explicitly on every tool, and names hints that do not match a tool’s behaviour as a common reason for rejection.
Budgets. Hosts cap different things: VS Code counts tools per chat request, Windsurf counts tools in total, Codex counts seconds, Claude counts the size of a result. A server built for one of these can exceed another without changing a line.
What a machine can check, and what it cannot
Roughly half of the rules can be checked statically from the tool list: name length and characters, the presence of annotations and titles, a valid input schema, the tool count. About a quarter need live calls: that every tool succeeds with valid input, that errors come back as results rather than generic failures, that responses stay within a host’s size limit, that the server starts within Codex’s ten seconds.
Most of what reviewers actually reject needs judgment: whether a description matches what the tool does, whether a read-only hint is honest, whether a description is promotional, whether anything in it reads as an injection. That is work for a language model with a rubric, with a person behind the verdict.
The rules also move. The host documentation was each read once on one day, and a validator that hard-codes them will rot. The research argues they have to be carried as versioned data, each rule with its source and the date it was read.
Descriptions are where servers fail
The rule that matters most is the one no regular expression can check. A study titled “Model Context Protocol (MCP) Tool Descriptions Are Smelly! Towards Improving AI Agent Efficiency with Augmented MCP Tool Descriptions” found at least one defect in 97.1% of the 856 tool descriptions it examined, and poor descriptions reduce the chance that an agent selects the right tool. The most developed yardstick is Glama’s Tool Definition Quality Score, which grades six dimensions of a definition and is already run continuously across a registry of more than fifteen thousand servers, so maintainers are being graded whether they know it or not.
What validates against the rules today?
The validators that exist are closed, paid or partial: Alpic Beacon, Manufact’s publishing checks and MCPJam’s hosted readiness runs. Nothing open covers the IDE and command-line hosts.
How this changes the way we build
- We design tool names to the strictest rule, 64 characters with no hyphens or dots, so one server passes everywhere.
- Every tool gets a title and all three hints from the first commit, with the hints checked against what the tool actually does.
- Read and write are separate tools, always.
- Result sizes are budgeted against Claude Code’s default, the smallest of the published limits.
- Descriptions are written and reviewed as product copy for a model, then scored before submission.
- The host rules we check against are kept as dated data in the project, not as code.
What this looks like on a real engagement is described at MCP servers and AI integrations.