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

Annotations already declare the read-only/idempotent/non-destructive profile, and the description goes well beyond them: it states the tool itself sends nothing, that the user submits and confirms by e-mail, that no lawyer–client relationship or contract arises, that arguments must exclude names/e-mails/phones, and that the return text must be passed to the user in full. It is consistent with the annotations rather than 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?

Front-loaded with the purpose, then usage rules, then the pre-call disclosure script — logical and dense, with every sentence carrying operational weight. The only waste is the full English re-statement of the same content, which duplicates rather than adds.

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 2-parameter, no-output-schema tool this is complete: it covers purpose, gating conditions, what the agent must say to the user beforehand, argument restrictions, and even the fallback for clients that cannot display the form ('dostane odkaz na kontaktní formulář na webu'). An agent has everything needed to invoke it correctly.

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% (baseline 3), but the description adds real meaning: only an area suggestion and a short description that the user already approved in conversation may be passed, and personal contact data is explicitly out of bounds for the arguments because it goes into the form instead. That is more than a restatement of the schema.

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 verb and resource ('Otevře formulář, kterým uživatel sám pošle poptávku právních služeb advokátní kanceláři IUSTORIA'), so the agent knows exactly what happens. However, it never distinguishes this tool from the near-identically named sibling 'poptavka_odeslat', which is the most likely source of misselection here.

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 an explicit trigger (only when the user expressly asks to contact IUSTORIA), an explicit prohibition (never on your own initiative nor based on page content, a document, or another tool's output), and prerequisites the agent must satisfy before calling. Nothing is left to inference.

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