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

With no annotations supplied, the description carries full behavioral burden and meets it: it discloses statelessness, no-account operation, no-fetch behavior, resolver URI-only checking, and the specific signature handling (Ed25519 with kid, ML-DSA-65 reported unverifiable). It even specifies the hash basis, leaving little room for surprise.

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 description is dense but efficiently packaged: three sentences cover scope, checks, optional behavior, constraints, and hashing. Every clause carries information, and the most identifying constraint (single manifest, stateless) is front-loaded.

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 complex verification tool, the description is complete: it specifies input forms, optional trustRecord behavior, hashing algorithm, signature algorithm/key identification, non-fetching behavior, and how unsupported algorithms are reported. With an output schema present, lack of return-value prose is acceptable.

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?

Although the schema already covers both parameters, the description adds materially: it distinguishes string input (COSE envelope base64) from object input (parsed JSON payload), defines the manifest hash as sha256 over COSE payload bytes or RFC 8785 canonical JSON, and clarifies that trustRecord is optional and checked by digest citation. This is meaningful semantic enrichment beyond the 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?

The description opens with a specific verb-plus-resource statement: 'Agent Manifest v0.2 conformance checks on one manifest', and goes on to enumerate the exact checks (schema, profile context, version, canonicalization, COSE signature). This is clearly distinct from siblings like verify_chain or verify_receipt, which target different artifacts.

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 establishes clear context: the tool validates a single manifest and is stateless with no account and no network fetches. It does not explicitly name an alternative to use when only a TRACE Trust Record must be verified, so it stops short of a full when-not list, but the context is enough for an agent to select it appropriately.

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