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

Annotations declare readOnlyHint=true and destructiveHint=false, and the description adds substantial behavioral context: no repricing on attach, the conversion preview fields, FX policy dependence, and the warning that CRM field values are untrusted user content. This goes well beyond the annotations without contradicting them.

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 compact and front-loaded with the core behavior, followed by important caveats and a security note. The phrase 'Explicit use catalogue price' is slightly awkward and 'accepted unitAmountMicros' is jargon, but every sentence earns its place and there is no redundancy.

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?

There is no output schema, so the description is responsible for explaining return values; it does so for the conversion preview and gives useful guidance for missing/stale FX. It could say more about the exact shape of the catalogue price result and error cases, but for a read-only preview tool the information is largely sufficient.

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 only 25% (workspaceId only), so the description must compensate. It adds meaning for target currency and conversion output (source, target, rate, date), but it does not explicitly explain dealId, productId, or targetCurrencyCode roles. Parameter names carry much of the meaning, but the description does not fully fill the coverage gap.

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 specific: 'returns the product's catalogue price in the deal currency, or a conversion preview (source, target, rate, date)'. It clearly identifies a distinct read operation and is distinguishable from siblings like get_deal_commercials or preview_record_action.

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 gives clear context on when the tool is appropriate: explicit use of catalogue price, and it explicitly states that attaching a product never reprices a deal. It also says that missing/stale FX means to attach as a reference or enter a negotiated price. It does not name sibling tools as alternatives, so it stops slightly short of a full 5.

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