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

Annotations already declare this is a read-only, idempotent, closed-world calculation, so the safety bar is met. The description goes further by disclosing the internal model: the free-allocation phase-out factor from Directive Article 10a(1a), crediting carbon price already paid in origin, and pricing the same basket every year so the trajectory is visible. That is genuine behavioral context beyond the annotations.

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 structure is front-loaded with the example questions that both explain scope and aid retrieval, followed by the concrete regulatory mechanics. The question list is somewhat repetitive with the following sentences, but each element earns its place as a semantic trigger. No filler or marketing language.

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 calculation tool with no output schema, the description never indicates what the response looks like (total cost, per-line breakdown, certificate count, year-by-year trajectory). The input side is thoroughly covered, but the return shape is left entirely to inference, which is a real gap for a tool whose whole purpose is producing a number.

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 coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema: it anchors the 'year' parameter to the 2026-2034 phase-in window, enumerates the applicable sectors, and reinforces the origin carbon-price offset. The rationale for the certificate price (the server will not invent a market price) is carried in the schema, so this is reinforcement rather than novel detail.

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 states a specific computation ('Computes the CBAM certificate cost of importing goods into the EU'), names the governing regulation and the exact input domain (all six Annex I sectors, 2026-2034 phase-in). It is unmistakable against the unrelated siblings eu_ai_act_classify and uae_corporate_tax. An agent knows exactly what resource this produces before opening the schema.

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 opening question list is an explicit set of when-to-use triggers ('what will CBAM cost me', 'do I have to pay CBAM on this shipment'), and 'Use this rather than estimating' names the alternative approach and the reason (the phase-in factor changes yearly and is often wrong). It lacks an explicit exclusion or named sibling alternative, but the routing intent is clear and unambiguous.

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