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

The description supplies real behavioral context (API key needed, report is immutable and valid 30 minutes, no external submission or charge), but it directly conflicts with the annotations: it frames the work as 'Read-only provider checks' where nothing is submitted while annotations declare readOnlyHint=false and destructiveHint=true, and idempotentHint=false is never mentioned. An agent reading only the prose would conclude this call is harmless and repeatable, which the annotations do not support.

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?

Four short sentences with the prerequisite front-loaded and no filler; the compressed phrases 'exact public payloads, blockers and remedies' are terse but still parseable. Slightly telegraphic, but every clause carries information.

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?

There is no output schema and no explanation of the parameters, so for a tool with a nested required object the description should explain what connection_refs entries are and how report contents map to blockers. It hints at report contents but leaves the caller unable to construct a correct invocation from prose alone.

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 0% across three required parameters, including a nested connection_refs object with github/registry/smithery keys that the description never explains. Only vague echoes exist ('selected destinations' for directory_slugs, 'provider checks' for connections), leaving server_id and the ref structure completely undocumented.

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 concrete action and artifact: provider checks that produce an immutable 30-minute report of payloads, blockers and remedies, which matches the tool name run_preflight. It does not name or distinguish itself from the close siblings get_preflight (retrieve a report) or check_launch_coverage, so the run-vs-fetch distinction must be inferred from the title.

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?

Usage is only implied: 'Requires API key' is a prerequisite and 'Unsupported/paused destinations cannot be bought' implies preflight precedes a purchase, but the description never says when to call this rather than get_preflight, check_launch_coverage or check_repository. No exclusions or alternative routing are stated.

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