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

The annotation set is sparse (only readOnlyHint=false, etc.), but the description adds significant behavioral context: it submits to four specific calendars, stores a pending proof locally, returns a stamp ID, and explains confirmation timing. No contradictions with 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?

The description is four sentences, each serving a clear purpose: definition, implementation details, output, and timing. No filler or repetition.

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 only one parameter and no output schema, the description adequately covers the tool's behavior, return value (stamp ID), and timing. It could mention the pending proof status more explicitly, but it is largely complete.

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 schema already describes the hash parameter as 'SHA-256 hex digest (64 chars)'. The description restates this without adding new semantic details, so it meets the baseline for full schema coverage.

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 clearly states the action (creates a verifiable Bitcoin timestamp), specifies the input (SHA-256 hash), and names the protocol (OpenTimestamps). It distinguishes from sibling tools like inspect_timestamp and verify_timestamp by focusing on creation.

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 when to use this tool (to timestamp a hash) and notes the expected confirmation time. It does not explicitly mention when not to use it or suggest alternatives, but the context is clear.

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

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

Adds value beyond annotations by stating 'Purely local — no network calls, no data stored.' This clarifies side effects. Annotations already indicate readOnly, idempotent, non-destructive; description reinforces and provides extra context.

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?

Two sentences, front-loaded with main purpose. Every sentence provides useful information with no waste.

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?

Given a simple tool with one parameter, strong annotations, and no output schema, the description covers everything needed: what it returns (hex string), where it works (local), and usage examples. Complete for its complexity.

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?

Only one parameter (path) with schema coverage 100%. Schema description already says 'Absolute path to the file'. Description does not add extra meaning beyond that, so baseline 3 is appropriate.

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?

Clearly states the tool computes SHA-256 hash of a local file and returns a 64-character hex string. Distinguishes from siblings by mentioning usage before create_timestamp or for independent verification.

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?

Provides explicit use cases: to get a hash before create_timestamp or for file integrity verification. Does not explicitly state when not to use, but context is clear and no misleading guidance.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds value by stating no network calls and explaining the semantic meaning of calendar vs Bitcoin attestations, which helps the agent understand the tool's behavior.

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 two sentences, concise and front-loaded with the core action. Every sentence adds value without redundancy.

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?

Given no output schema, the description provides essential return details (size, attestations, confirmation condition). However, it omits potential error cases and a complete list of returned fields. Still, it is adequate for a simple read 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?

The description does not add any information beyond the schema's description of the 'id' parameter. Since schema coverage is 100%, the baseline of 3 is appropriate.

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 clearly states the tool reads a stored proof file from disk without network calls, and explains the return metadata. It distinguishes from siblings like create_timestamp or verify_timestamp by focusing on inspection.

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?

While the description implies usage for checking specific stamps locally, it does not explicitly state when to use this tool over alternatives such as verify_timestamp or list_pending. No when-not or alternative names are provided.

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

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

The description adds details beyond annotations: it lists the fields returned (status, retry count, next upgrade time) and explains filtering and pagination. Annotations already mark it as read-only and idempotent, and the description aligns. Minor omission: it doesn't mention timeout enum value in the filter list.

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 two sentences: first defines the output, second gives usage and filter capabilities. No redundant words, front-loaded purpose.

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?

Given no output schema, the description explains return fields (status, retry count, next upgrade time) and all filter parameters. It covers pagination and age filtering, sufficient for a listing tool with read-only annotations.

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?

Schema description coverage is 0%, so the description must compensate. It explains the status filter (but misses 'timeout' from enum), pagination via limit/offset, and older_than_hours. However, it does not explain the maximum limit or that offset defaults to 0. This is adequate but not comprehensive.

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 clearly states it lists stamp records with status, retry count, and next upgrade time, and mentions filtering capabilities. It distinguishes itself from sibling tools (which are create, verify, etc.) by being a query operation.

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 explicitly says 'Use this to monitor the state of all timestamped hashes,' which provides clear usage context. However, it does not mention when not to use it or alternatives among siblings.

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

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

Annotations already indicate it is not read-only (readOnlyHint=false). The description adds context: it computes SHA-256, submits to four public OTS calendars, and confirms file contents are never sent. It also mentions returning a stamp ID for tracking, which goes beyond 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?

The description is concise (three sentences) and front-loaded with the main purpose. Every sentence provides value: the one-step nature, the hash algorithm, calendar count, privacy guarantee, and output. No wasted words.

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 tool with one parameter and no output schema, the description covers the process (hash, submission, privacy) and the return value (stamp ID). It is complete enough for the agent to understand what happens and what to expect.

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 schema coverage at 100%, the single 'path' parameter is fully described in the schema (absolute path). The description adds no additional meaning beyond 'file to stamp'. Baseline 3 is appropriate since schema does the heavy lifting.

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 clearly states it hashes a local file and stamps it on Bitcoin in one step. It specifies the action (SHA-256 hash, submission to OTS calendars) and the resource (file). This distinguishes it from siblings like hash_file (which only hashes) and create_timestamp (which stamps a hash).

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 usage as a convenience tool when you want to hash and stamp in one step. It notes that file contents are not sent externally, which is a safety guideline. However, it does not explicitly state when not to use this tool or mention alternatives (e.g., using hash_file then create_timestamp separately).

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

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

Annotations already indicate idempotency, but the description adds valuable context: the automatic retry scheduling and the recording of bitcoin_block upon confirmation. It confirms non-destructiveness and safe repetition. Could mention that it may trigger network requests.

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?

Two sentences, each earning its place: first explains the core action, second covers safety and retry behavior. Front-loaded with the key action. No wasted words.

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 tool with one parameter and no output schema, the description sufficiently covers purpose, safety, and outcome. Combined with sibling list and annotations, the agent has good context. Could mention response format or side effects (e.g., network calls) for completeness.

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 only parameter 'id' has schema coverage of 100% with a clear description ('UUID from the stamp record'). The tool description does not add additional meaning beyond the schema, so baseline 3 is appropriate.

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?

Description clearly states the tool's action: 'Attempts to upgrade a pending OpenTimestamps proof'. The verb 'upgrade' combined with the resource 'timestamp' is specific and distinguishes it from siblings like 'create_timestamp' and 'verify_timestamp'.

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 explains the tool's behavior (upgrade if confirmed, retry if not) and notes it is safe to call repeatedly, but does not explicitly state when to use it over alternatives like 'verify_timestamp' or 'inspect_timestamp'. No exclusions or when-not-to-use guidance is provided.

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

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false. Description adds value by disclosing the external API dependency (Esplora), the specific proof constraint (hash existed before a block height), and important limitations (not affirming authorship or validity). This provides behavioral context beyond 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?

Two sentences, no redundancy. Core action is front-loaded, and each sentence adds distinct value: the first explains the mechanism, the second clarifies limitations. Ideal conciseness.

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 tool (one parameter, no output schema), the description covers purpose, method, and constraints. It could mention the return type or expected response (e.g., success/failure or proof details), but the description is sufficiently complete for an AI to decide whether to invoke it.

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?

Schema description coverage is 100% (the 'id' parameter is described as 'UUID from the stamp record'). The description does not add further parameter-level details. Baseline 3 is appropriate as the schema already documents the parameter adequately.

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?

Description uses specific verb 'Verifies' and clearly identifies the resource ('timestamp proof against the Bitcoin blockchain via an Esplora API'). It distinguishes from siblings by stating what it does not affirm (authorship, content truth, legal validity), making its scope unambiguous.

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?

Implicitly states usage: for cryptographic proof of existence at a point in time. No explicit when-not-to-use or alternative tools mentioned, but the sibling list provides context. Could be improved by directly comparing with related tools like 'inspect_timestamp' or 'stamp_file'.

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

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

Annotations declare readOnlyHint=false (tool may cause changes) and idempotentHint=false. The description adds that the window remains open for real-time progress, attempts upgrades, and enforces a minimum interval. This matches and extends annotation information. No contradiction.

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 consists of four sentences, each serving a distinct purpose: defining the action, stating use case, explaining behavior, and adding a constraint. It is concise with no redundant or extraneous information.

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 tool with one parameter and no output schema, the description covers purpose, behavior, usage context, and rate-limiting constraint. Annotations are also provided. The description is sufficient for an agent to understand and invoke the tool correctly.

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 only parameter is interval_minutes, which the schema already describes with default and minimum values. The description does not add additional semantic information beyond what is in the schema. Since schema description coverage is 100%, baseline of 3 applies.

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 clearly states the tool opens a terminal window to monitor pending stamps and attempt due upgrades. It uses specific verbs ('monitors', 'attempts') and resource ('pending stamps', 'due upgrades'). It distinguishes from siblings like list_pending (which only lists) and upgrade_timestamp (which upgrades a single timestamp).

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 says it's 'useful for long-running monitoring sessions after stamping' and mentions the minimum interval to avoid hammering OTS calendars. It implies when to use (after stamping) but does not explicitly list alternatives or when not to use. The context of siblings provides some guidance, but direct exclusion is missing.

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