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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's value is in labelling provenance — third-party independent outlets versus first-party campaign data — which directly affects how the agent should present the evidence. It also flags conditional rendering as source cards depending on host support, which is behavior the annotations cannot convey. Return format details beyond that are absent.

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 what the tool returns, then the trigger condition, then rendering behavior — a sound order with no filler sentences. The long outlet enumeration is slightly list-heavy but earns its place by grounding the notion of independent coverage.

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?

With no output schema, the description still conveys the shape of results (per-item subject, source cards, first-party labels) and the kind of sources included. Enough for an agent to call it and describe results accurately, though it does not say what happens when evidence is missing for a requested claim.

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% and the single lang parameter already documents its enum, default, and the rule about Polish fact texts, so the description adds nothing about parameters. Baseline 3 applies when the schema carries the parameter burden.

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 names a concrete resource set — third-party press coverage, Wikipedia/Wikidata entries, documented projects and campaign results — and distinguishes third-party coverage from first-party-labelled data, which is the key semantic split versus siblings like get_company_profile. It never names the sibling it is not, so the differentiation is inferable rather than explicit.

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?

'Use it when someone asks for proof, references or press coverage' gives a clear triggering condition tied to the user's intent. It stops short of exclusions or routing to alternatives such as get_company_profile when the answer is self-reported rather than external.

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