Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations provide readOnlyHint=true and openWorldHint=true, lowering the bar, and the description aligns with them ('one read-only tool call over POST JSON-RPC', 'Protocol inspection only — no auth-bypass, no payment'). It adds genuine context beyond the annotations: the scope of advisory security signals (plain-HTTP, redirects, header disclosure, credentials expiry) and the explicit stance that 'it catches mechanical failures, it does not guarantee a pass.' No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description runs roughly 400 words, far beyond what a single-parameter tool needs. Substantial space goes to context an agent doesn't need to invoke the tool correctly: the SASAME corporate background, 'MCP Factory is internal machinery,' the census statistic ('~80% of public MCP servers return no real content'), and 'Free.' The key differentiator (verify_mcp_ready) and return-value statement are buried mid-way rather than front-loaded. Valuable information, but poorly compressed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter tool with no output schema, the description is thorough: it states the return payload (grade, per-criterion pass/evidence breakdown, single biggest gap), defines the graded criteria, lists advisory security and capability signals, and bounds what it does not grade. The only omission is a precise return structure, but no output schema exists and the described returns are sufficient for an agent to know what it will get.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% — the lone `url` parameter is already described as 'The MCP server endpoint URL (https) to audit — ideally your own.' The description reinforces this by adding the https constraint and 'best run against your own server,' but doesn't add material new semantics beyond what the schema already states. Baseline 3 is correct since the schema carries the load.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence states a specific verb, resource, and scope: 'Grade one MCP server A-D against the Agent-Tool Discoverability Standard.' It further enumerates the exact protocol operations (server/discover with legacy initialize fallback, tools/list, one read-only tool call) and differentiates from verify_mcp_ready, which returns the same audit as a signed certificate. The purpose is unambiguous and clearly set apart from siblings despite surrounding marketing drag.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage direction is explicit and actionable: 'run it before you submit' (directory pre-flight for mechanical reject reasons), 'Best run against YOUR OWN server,' and a named alternative — verify_mcp_ready — for when a signed certificate is wanted. It also states what the tool does NOT cover (privacy-policy, identity/business verification, OAuth callbacks, prohibited-category rules) and that a pass is not guaranteed. When/when-not guidance is fully spelled out.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.