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

There are no annotations, so the description carries the full burden of behavioral disclosure. The phrase 'Title discarded after the call' suggests no state is preserved, but the description does not explain whether the tool performs a live lookup, what it returns, or how it handles failures. This is too little context for a tool with no annotation support.

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 short and front-loaded with its core purpose. However, the second sentence, 'Title discarded after the call,' does not earn its place; it is vague and potentially misleading given the absence of a 'title' parameter. The compactness is good, but the added clause reduces clarity.

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?

This is a ten-parameter tool with no annotations and no output schema, yet the description identifies neither the operative parameter nor the return value. The description and schema are also in tension: the tool claims to check Wikipedia titles but provides no way to supply one. This is far below what an agent needs to invoke the tool correctly.

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?

The schema lists ten string parameters, none of which is named 'title' or clearly mapped to a Wikipedia title. The descriptions in the schema mention unrelated concepts like city, feed, JSON, and host, and the tool description does not clarify which parameter should be passed. An agent cannot determine the correct input, making the parameter semantics effectively unusable.

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 uses a clear verb and resource: 'Check whether a Wikipedia title exists.' This distinguishes it from sibling URL, JSON, and validation tools. However, the sentence about the title being discarded adds confusion, and the schema contains no 'title' parameter, which weakens the clarity of what is actually being checked.

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 implies the tool should be used when an agent needs to verify whether a Wikipedia title exists, which is a reasonable use case. There is no explicit guidance about when to prefer an alternative or when not to use this tool, so the usage context remains only implicit.

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