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

Goes well beyond the readOnly/idempotent/openWorld annotations by disclosing that the tool validates structure only, does not fetch sources, does not confirm authority identity or verify facts/current law, and supplies no generated or validated PDF. It also sets an important interpretive rule ('empty evidence is unresolved, never no risk') and cautions that publisher_kind authority_reported is a reported classification, never an independently verified label. That is exactly the caveat context an agent needs before presenting research to a user.

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 labeled sections (Purpose / When to use / Returns / Parameter guidance / Limitations / Chaining) make it scannable and front-loaded, but it is long and repeats the return payload — 'Returns: Atlas AI UI, a JSON evidence register...' appears in the opening and again near the end almost verbatim. That duplication is dead weight in an otherwise well-organized block.

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?

Rich enough for a complex, open-world presentation tool: it covers output artifacts, validation scope, non-verification caveats, evidence-count limits and chaining. Because an output schema exists, the repeated return-value prose is redundant rather than necessary, and the optional geospatial parameters (coordinates, radius_meters, country_code, address) are never explained.

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 11% and the schema is a 9-parameter nested object, so the description must compensate, and it largely does: up to 30 findings, up to 20 public HTTPS sources with dates, applicability, limitations and gaps, and the hard rule that every finding must reference a supplied unique source ID. It also spells out the site_ref pass-through requirement. Gaps remain for question, address, coordinates, radius_meters and country_code, which are undocumented in both description and 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?

States a specific verb and resource ('present cited site research') and immediately enumerates what is produced: Atlas AI UI, a JSON evidence register, and a self-contained printable HTML pack. That distinguishes it from sibling tools like prepare_site_research and inspect_research_source, which gather or inspect evidence rather than render it. The opening 'Purpose:' line is somewhat self-referential, but the Returns clause removes the ambiguity.

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?

Gives an explicit trigger ('after conversation research, or to show unavailable search and gaps') and a chaining rule (pass site_ref unchanged into another Atlasly tool to reuse the canonical site). What's missing is a direct contrast with the closest sibling, prepare_site_research, so an agent must infer which stage of the workflow this belongs to.

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