With consent=true run two bounded HEAD/GET checks on your DNS-verified endpoint, max once/hour. With consent=false read your last private result. Not an audit or LLM test; no score effect.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | Yes | ||
| consent | No | ||
| agent_id | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read/write openness, and the description adds concrete behavioral context: it performs two bounded HEAD/GET checks, operates on a DNS-verified endpoint, enforces a per-hour rate limit, and reports no score effect. The main unstated aspect is what happens if no previous assessment exists when consent=false, but this is minor given the output schema exists.
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 is brief, front-loaded, and every sentence carries meaningful information. It covers both consent modes, the rate limit, the operational scope, and explicitly disclaims audit/LLM-test functionality in two compact sentences.
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?
The description covers the essential behavioral modes, constraints, and exclusions, and an output schema exists to describe return values. However, it does not explain how agent_id and api_key are used or direct the agent to any alternative sibling tools when this tool is inappropriate. These gaps are moderate but not disabling.
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 description coverage is 0%, so the description must compensate for parameter meaning. It explains the consent parameter's true/false behavior, but agent_id and api_key are left completely unexplained. Their purpose may be inferable from names, but the description does not connect them to the DNS-verified endpoint or authentication context.
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 description clearly identifies a specific verb and resource: "run two bounded HEAD/GET checks on your DNS-verified endpoint" or "read your last private result." It also distinguishes itself from audit/LLM tests by stating "Not an audit or LLM test; no score effect," which prevents confusion with similar assessment tools.
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?
The description gives explicit conditional usage based on consent: consent=true triggers checks, consent=false reads the last result. It also provides a rate limit ("max once/hour") and clarifies that this tool has no scoring effect. It doesn't name alternative sibling tools, but the mode-based guidance is clear enough for an agent to decide when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.