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

Beyond the readOnlyHint annotation, the description discloses critical behavior: the tool is paid ($0.01 USDC on Base per call), uses x402, cannot pay on the user's behalf, and returns the exact HTTP URL and payment requirements. This is exactly the kind of payment requirement context annotations do not capture, so the description earns full credit.

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 three dense sentences with no wasted filler. It front-loads the most critical fact (payment required), then states the search purpose, then gives the payment workflow. The 'PAID' in the title is repeated in the first sentence, but the extra detail ('$0.01 USDC on Base per call via x402') justifies the repetition.

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?

Given 17 parameters, no output schema, and low schema coverage, the description is not complete enough. It explains the payment flow but does not describe parameter formats, accepted values, response shape, pagination, or how to construct a valid query after payment. An agent would still need to infer most of the tool's operational details.

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% for 17 parameters, so the description must compensate. It names a few filter concepts (CPV, NUTS, deadline, buyer type, value), which maps loosely to cpv, nuts, deadline_after/deadline_before, buyer_type, and min_value, but leaves the majority of parameters—q, kind, sort, limit, since, until, fields, offset, procedure, legal_basis—unexplained. This is insufficient for a high-complexity parameter set.

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 names a specific verb and resource: 'Full-text and structured search over German public procurement notices.' It also lists search dimensions (CPV, NUTS, deadline, buyer type, value), which clearly distinguishes this from get_tender, sample_tenders, and tender_stats. However, the payment caveat muddles whether the tool returns search results directly or only a payment URL, so it is not a perfect 5.

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 clearly instructs when not to use this remote endpoint: it 'cannot pay on your behalf,' so the agent should 'use the local MCP server ... or an x402 HTTP client to get data.' This is explicit and actionable. It does not discuss sibling tools or when search_tenders is preferable to get_tender, but the payment alternative is well covered.

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