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

Annotations already declare readOnly, idempotent and non-destructive, but the description adds substantive context: the manifest is public, no authentication is required, and the agent is directed to report the returned signature status rather than assume verification. The 'changes no state' clause overlaps readOnlyHint, but the auth and reporting guidance is genuine value-add.

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 tight sentences with the payload front-loaded in the first sentence. The only minor waste is 'it changes no state', which restates the readOnlyHint annotation already in the structured data.

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 carries the return-value burden, and it does so by enumerating the manifest's sections and flagging signature status as the field to surface. Combined with annotations covering the safety profile, an agent has what it needs to call and interpret the tool.

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?

Zero parameters, so there is nothing for the description to disambiguate; the baseline for a no-arg tool applies. No parameter-related gap remains.

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?

Specific verb ('Read') plus a named resource ('public versioned Origin Manifest') and an explicit enumeration of contents (purpose/authorship scope, amendment rule, signature status, cultural-framework disclosure). An agent can distinguish this from siblings like inspect_cassie_lineage or get_public_story_record without opening either schema.

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 indicates what the tool is for but never states when to reach for it versus alternatives, nor any prerequisites or exclusions. No sibling is named, so routing among the many get_/inspect_ tools is left to inference.

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