Anchor Artifact (Bitcoin-anchored integrity proof)

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

Discloses side effects beyond annotations: file is never uploaded (hashed locally), hash is registered on a blockchain-checkpointed audit chain, and a JWS receipt is returned. This adds privacy and verification details that complement the openWorldHint=true and idempotentHint=false annotations.

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?

Three well-structured sentences: purpose, mechanism, and use cases. Every sentence provides necessary information with no repetition or filler.

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?

Covers the anchoring workflow, output (JWS receipt), and offline verification, which is substantial given no output schema. Lacks error conditions or receipt contents, but this is acceptable when a sibling tool (check_artifact) may handle verification.

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?

With 0% schema coverage, the description explains most parameters: path (hashed locally, not uploaded), sha256 (precomputed), kind (defaults to document), and label (short reference, no PII). It fails to mention `subject` and does not explicitly state mutual exclusivity of path/sha256, leaving a partial gap.

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 clear action: 'Prove an artifact existed exactly as-is at this moment' — a specific verb and resource. It also distinguishes itself from siblings like check_artifact (verification) and get_audit_proof (retrieval) by focusing on the anchoring/creation act.

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?

Explicitly lists use cases (contracts, invoices, prescriptions, etc.) and gives the path/sha256 alternative. However, it does not contrast with sibling tools or state when not to use it, so no exclusions are mentioned.

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