Skip to main content
Glama

witnesses

Re-verifies each signature on a record against its content hash as it is read, without trusting storage, and reports invalid entries instead of hiding them.

Instructions

[CHECK · internal] Who has borne witness to a record, each signature re-verified as it is read (storage is never trusted). Reports invalid entries rather than hiding them.

Input Schema

NameRequiredDescriptionDefault
content_hashYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.2/5.0
Behavior4/5

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

With no annotations, the description carries the behavioral burden and does so well: it discloses that each signature is re-verified on read, that stored data is never trusted, and that invalid entries are reported rather than suppressed. This is meaningful behavioral context beyond a bare read, though it omits whether it is read-only or what permission is required.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences that front-load the core purpose and then layer in the verification behavior. The '[CHECK · internal]' prefix is slightly cryptic but compact, and no sentence is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter read tool with no annotations and no output schema, the description covers the behavioral angle but leaves gaps: it never explains the content_hash input semantics or what a returned witness entry looks like. Adequate but not fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% for the single required parameter content_hash, so the description must compensate but does not. It only refers obliquely to 'a record,' adding no format, expected-value, or matching semantics for content_hash beyond the parameter name itself.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear resource (the witnesses who have attested to a record) and implies the query verb by asking 'Who has borne witness to a record.' It is distinguishable from siblings like attest_record (creates a witness) and verify (validates something), though the exact output shape is left implicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit when-to-use guidance and no alternatives are named, despite many nearby verification/attestation siblings (attest_record, verify, find_verifier, self_attest). The '[CHECK · internal]' tag hints at a context but does not explain when an agent should call this versus verify or find_verifier.

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