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

No annotations are present, so the description carries the full burden of behavioral disclosure. It does not state whether the tool is read-only, what it returns, or how it handles inputs. The parameter schema suggests values are 'discarded', which is a behavioral trait the description completely fails to mention.

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 extremely short and free of fluff, but it is under-specified to the point of being unhelpful. It lacks a clear structure or any functional verb. This is more akin to an under-specification penalty than a praise of conciseness.

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 tool has 10 parameters, no annotations, and no output schema, yet the description is just an eight-word noun phrase. An agent cannot understand why a catalog of HTTP status codes would take parameters like city, feed, or JSON text. The description is completely inadequate for safely selecting and invoking this tool.

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?

All 10 parameters have descriptions in the schema, so schema description coverage is 100%, which sets a baseline of 3. The tool description itself adds no meaning beyond the schema. However, the schema parameter descriptions are individually clear, even though their connection to the tool's purpose is unexplained.

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 is a noun phrase, not a verb phrase, so it does not state what the tool actually does (e.g., 'returns' or 'lists'). It essentially restates the tool name with a small amount of detail ('common HTTP status codes'), which is close to a tautology. It does not differentiate from siblings like fetch-status, which might also relate to status codes.

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?

There is no guidance about when to use this tool versus any of its siblings. It does not mention alternative tools, conditions, or contexts. The description is purely a noun phrase with no actionable direction.

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