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

Strong beyond-annotation disclosure: exact price and denomination ($0.05 USDC on Solana), data-handling guarantee (in-memory only, never stored), the paid-retry semantics, and the two grading rule sets applied (mcp-manifest-claims/v1, prompt-injection-rules/v1 in a separately labelled section). What it omits is payment/auth mechanics and any rate or latency expectations for a paid call; openWorldHint=true already covers the outbound URL fetch.

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?

Two sentences, front-loaded with the price and the deliverable, then the report contents, then privacy/retry terms — no filler. It is dense (multiple clauses chained with dashes and semicolons), which costs a little readability but nothing is redundant.

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 does the necessary work by describing the report's structure (per-tool verdicts, field-level diffs, re-grade, injection screen) as well as cost and data retention. Remaining gaps are how exactly one baseline source must be chosen and what the agent gets back on failure, both partly mitigated by the schema text.

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% and the schema itself already spells out the url/manifest mutual exclusion and the signed-vs-fallback baseline modes. The description only echoes that framing ('one submitted manifest against one customer-held baseline' and the retry re-sending baseline plus manifest) without adding syntax, format, or selection guidance the schema lacks. Baseline 3 is correct.

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 deliverable — a drift comparison of one submitted manifest against one customer-held baseline — with per-tool UNCHANGED/CHANGED/ADDED/REMOVED verdicts and field-level diffs. That is far more specific than the name alone. It stops short of a 5 because it never contrasts itself with the closely named siblings manifest_audit, manifest_criteria, or manifest_drift_precheck, so the agent must infer the boundary.

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?

The description implies the use case (you have a current manifest and a baseline and want a diff) and states the price up front, but gives no explicit when-to-use, when-not-to-use, or prerequisite (e.g. run manifest_drift_precheck first, or use manifest_audit for a single-manifest grade). With four manifest_* siblings in the list, the absence of routing is a material gap.

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