provenance

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

No annotations are present, so the description carries the full behavioral burden. It explicitly declares 'Read-only', states that 'historical testimony is preserved', reveals a warning behavior for insufficient support, and discloses a semantic limitation of source labels. This is unusually transparent.

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 compact sentences with the action verb front-loaded. Each sentence adds a distinct piece of information: what the tool inspects, its non-destructive behavior, and an important interpretation caveat. No 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?

For a simple one-parameter read-only tool with no output schema, the description covers purpose, safety, warning behavior, and a key interpretation pitfall. It is slightly incomplete only in not describing the exact return shape or what 'stable identifiers' refers to, but these are minor for selection and invocation.

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?

The input schema provides only name and type with 0% description coverage. The description does not directly define memory_id, but the tool context makes clear that it identifies the memory whose recorded sources are being inspected. This adds enough framing to avoid misuse, though format or identifier source is not specified.

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 specific verb, 'Inspect', and a specific resource: 'recorded sources and the independent-corroboration gate'. This is concrete and tool-specific, and the 'Read-only' qualifier distinguishes it from mutation-oriented siblings like corroborate and promote.

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 this tool is for checking a memory's recorded sources or corroboration status, but it never explicitly says when to use it instead of siblings like audit_log or corroborate. The caveat about stable identifiers is interpretational guidance after the fact, not tool-selection guidance.

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