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

The description contradicts the annotation readOnlyHint: true by stating that a #tag that does not exist yet would be created. Creation is a write operation, directly conflicting with the read-only hint. The description also fails to explain other side effects or the fact that previewing is non-destructive, but the contradiction is the dominant issue. This is a serious inconsistency that could mislead agents into expecting no modifications when the tool actually creates tags.

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 two sentences, front-loaded with the core purpose ('Shows how a natural-language phrase would be recorded by quick_add, without saving anything'). Every sentence earns its place: the first defines the action and safety property, the second specifies input capabilities and the tag-creation caveat. No filler or 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?

For a single-parameter preview tool with an output schema, the description covers the main behavior and input format. However, it omits details about what the preview returns (though output schema exists), and more importantly, it presents a conflicting side effect (tag creation) that is not reconciled with the readOnlyHint. This undermines completeness and could lead to incorrect agent assumptions. The description is adequate but not fully reliable due to the contradiction.

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 already documents the sole parameter 'text' with an example, giving 100% coverage. The description adds value by explaining what the text can contain (amounts, dates, account names, #tags, currencies) and language support (English and Russian). This goes beyond the schema's generic example and helps the agent construct appropriate inputs, so a score above the baseline is warranted.

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 clearly states the tool's purpose: it previews how a natural-language phrase would be recorded by quick_add, without saving. It distinguishes itself from quick_add (which likely saves) and other preview tools by explicitly mentioning 'without saving anything'. The verb 'shows' and resource 'transaction phrase' are specific, and the mention of quick_add differentiates it from siblings.

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 when to use this tool: when you want to see how a phrase would be interpreted before actually running quick_add. It names quick_add directly, making the alternative explicit. However, it does not state when not to use it or mention other preview tools (preview_interest, preview_notifications), so it lacks explicit exclusions. The guidance is clear but not exhaustive.

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