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

Annotations already declare readOnlyHint=true, destructiveHint=false, so the safety profile is covered. The description adds important behavioral context beyond annotations: the prices are examples for a one-page black-and-white standard letter within Germany, and the real price depends on additional factors. This sets correct expectations about the nature of the returned data.

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 well-structured: it states the purpose, gives trigger keywords, then provides the caveat and the alternative tool. The only redundancy is the full bilingual repetition (German and English versions of the same content), which is acceptable for accessibility but slightly reduces conciseness. Every sentence earns its place in terms of content.

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 simple read-only pricing tool with no business parameters, the description is complete. It explains what data is returned (tier thresholds and example prices), the exact assumptions (one-page B&W standard domestic letter), and routes to the relevant sibling tool for real quotes. The absence of an output schema is mitigated by a clear textual description of the return concept.

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 has only one optional 'reasoning' parameter with no description, but it is a generic meta-parameter rather than a business input. The description effectively covers the tool's domain semantics by explaining what data is returned, so no additional parameter guidance is necessary. The lack of a business parameter list is compensated by the description's clarity about scope.

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 specific verb ('Returns FrankKi's volume tiers') and resource, clearly stating what the tool provides: bulk discount tiers with the monthly quantity thresholds and example per-letter prices. It also distinguishes itself from shipping_quote by explicitly stating the tool gives example prices only, not real quotes.

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?

It explicitly tells the agent when to use the tool: 'Use this when someone asks about bulk discounts, volume pricing or enterprise pricing.' It also indicates when not to use it by directing real price calculations to shipping_quote, making the decision boundary unambiguous.

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