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

Annotations already declare readOnlyHint=false, idempotentHint=true and destructiveHint=false; the description goes well beyond them by disclosing that submissions are queued for review rather than published, that business contact details and public evidence are persisted, and that affiliation/dashboard access are not granted as side effects. It also flags a data-scope prohibition (patient data unsupported), which no annotation conveys.

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?

Five short sentences, front-loaded with the purpose and then progressing through prerequisites, data handling, negative guarantees, and the prerequisite-data source. No sentence restates the tool title or the schema, and each one adds a distinct constraint.

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 16-parameter, nested-object mutation tool with an output schema, the description covers preconditions, side effects, data scope, and referrals to get_entity_profile. The one real gap is that it never explains how request_type conditions the payload (e.g., price_update needing price_items vs profile_correction needing proposed_changes), which an agent must infer from the schema.

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 100%, so the schema carries the per-field burden and a baseline 3 applies. The description adds only indirect cues — 'business contact details and public evidence' maps loosely to submitter_* and source_urls, and the get_entity_profile pointer hints where entity_slug/entity_page_id come from — but it says nothing about the nested price_items structure or which fields each request_type expects.

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 first sentence names a specific verb ('Submit') and resource ('pending listing or price correction'), plus the destination ('for Loa review'). Every sibling tool is a read-only lookup (search_*, get_*, compare_*, explain_*), so this is unmistakably the only write/submission path, and the description makes that distinction explicit by stating it 'does not publish changes.'

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 concrete preconditions ('Requires sign-in, not a claimed listing') and hard exclusions ('Patient data is unsupported', 'does not verify affiliation, or grant dashboard access'). It also routes the agent to the sibling that supplies prerequisite data — 'Website correction and claim links come from get_entity_profile' — which is exactly the when/where guidance an agent needs.

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