attest-mcp-remote

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

With no annotations, the description fully discloses behavioral traits: the service binds the fingerprint to a timestamp, signs with HMAC, and normalizes metadata which become immutable after issuance. It explicitly states metadata are self-declared and do not prove authorship. It also clarifies the server never receives files, addressing potential misuse.

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 efficiently structured, starting with the core action and then layering details: authentication, metadata behavior, hash computation instructions, and fallback options. Every sentence contributes essential context without redundancy, making it concise yet comprehensive.

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 and eight parameters, the description addresses all key aspects: purpose, prerequisites, input preparation, security constraints, and alternative workflows. It leaves no significant gaps for an AI agent to misinterpret, ensuring thorough guidance for correct 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?

Schema coverage is 100%, providing a baseline of 3. The description adds value by explaining which parameters are 'bound by the signature' (immutable) versus 'descriptive only'. For the 'sha256' parameter, it provides concrete computation commands and a warning against sending files. This enriches the schema, moving it above baseline.

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 'Attest a work' with a clear verb and resource. It specifies binding a SHA-256 fingerprint to a timestamp and signing it. This distinguishes it from sibling tools like 'authorize' (authentication) or 'create_certificate_pdf' (output generation), making the purpose 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?

The description explicitly states the requirement for a credential (device flow via 'authorize' or API key). It instructs users to compute the SHA-256 locally and NEVER send file bytes, with specific shell commands. It also provides fallback options (website, Telegram bot) when hash computation is not possible, offering clear guidance on when and how to use the tool.

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?

With no annotations, the description fully discloses behavior: returns a user-opened browser link with anti-bot check, limits of 20 attestations and 24h, and the two-step flow.

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 convey purpose, limits, user action, exceptional cases, and next step; no unnecessary 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 zero-parameter tool with no output schema, the description covers the authorization flow, user interaction, limits, and relationship to siblings. Minor gap: no details on error handling or timeout.

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?

No parameters exist, so baseline is 4. The description adds value by explaining the tool's purpose and flow beyond the parameterless schema.

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 starts device-flow authorization for attestation, specifies limits (up to 20 attestations, 24h), and distinguishes from siblings by mentioning the alternative complete_authorization and exceptions for API key or verification tools.

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 when to use (to authorize attestations), when not (if API key header present, for verification tools), and directs to call complete_authorization after user approval.

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?

With no annotations, the description carries full burden. It discloses that the proof is created at attestation time and transitions from pending to confirmed within hours, offering useful behavioral context without contradictions.

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 purpose, followed by timing context. 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?

The description covers purpose and maturation timing, but does not describe the return format or possible statuses. Given the simple one-parameter tool and absence of output schema, this is a minor gap.

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 coverage is 100% and the schema already provides a detailed parameter description including hash computation instructions and privacy warnings. The tool description adds no new parameter semantics beyond what the schema provides.

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 'checks whether a work's SHA-256 fingerprint has an OpenTimestamps proof anchored in Bitcoin'. It specifies the resource (fingerprint) and action (check anchor), distinguishing it from siblings like attest_hash (which creates proofs).

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 the tool (to verify anchor status) and provides context about maturation time, but does not explicitly list exclusions or direct users to alternative tools.

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?

No annotations are provided, so the description carries full burden. It discloses that the tool polls the service briefly and may need multiple calls if approval hasn't occurred. This is good behavioral context, though it could mention retry limits or timeout 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 long and contains no filler. Every word adds value, clearly explaining purpose and retry behavior.

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?

Despite no annotations or output schema, the description fully explains the tool's role and behavior for its simplicity (no parameters). It tells an agent when to call, what it does, and how to handle non-approval.

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 has zero parameters with 100% coverage, so baseline score is 4. The description adds no parameter information, which is acceptable since there are no parameters to describe.

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 completes device-flow authorization after user approval in the browser. It specifies the action (complete authorization), resource (device-flow authorization), and distinguishes it from sibling 'authorize' which likely initiates the flow.

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 provides context that this tool should be used after browser approval and that if approval hasn't happened, the tool can be called again. It does not explicitly state when not to use it or mention alternatives, but the polling instruction gives clear usage 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?

No annotations are provided, so the description carries full burden. It discloses that the PDF is cryptographically signed, Bitcoin-anchored via OpenTimestamps, archived server-side, and returns permanent links. It also explains how the PDF is accessed (downloadable from URL, never inlined). This adds meaningful behavioral context beyond the structured schema.

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 with zero waste. The first sentence states the core action and key features (signing, anchoring, archiving). The second sentence clarifies the return behavior (permanent links, downloadable PDF). Every word adds value.

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 single parameter, no output schema, and no annotations, the description fully covers the tool's purpose, how to obtain the output, and important security/privacy details (do not send files, compute hash locally). It also mentions the return format (links) and access method (downloadable URL).

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 'sha256' parameter thoroughly (format, computation methods, warnings). The description adds value by linking the hash to the session context ('attested in this session with attest_hash'), explaining why this specific hash is needed, and reinforcing the privacy aspect (never send file bytes).

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 generates and archives a certificate PDF for a fingerprint attested in the session via 'attest_hash'. It specifies the cryptographic signing, Bitcoin anchoring, and server-side archiving, distinguishing it from sibling tools like 'lookup_certificate' or 'verify_attestation'.

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 after 'attest_hash' by mentioning 'attested in this session'. It does not explicitly state when not to use or list alternatives, but provides clear context for when the tool applies.

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?

With no annotations, the description provides important behavioral info: the trust model (only reachable by fingerprint knower), and a constraint (never send file bytes). It does not discuss rate limits or side effects, but as a read-only lookup, this is sufficient.

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 extremely concise: three sentences and a trust model note. It front-loads the purpose, then adds practical guidance, with no unnecessary 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 is complete (input, output type, trust model). It does not detail the exact output structure, but that is acceptable given the tool's simplicity and the availability of the links.

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 covers the SHA-256 parameter well (100% coverage). The description adds value by reinforcing the privacy/security aspect and instructing not to upload files, which goes beyond the schema's technical description.

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 looks up whether a SHA-256 fingerprint has an attestation certificate and provides specific links. It distinguishes itself from siblings like 'attest_hash' (which creates) and 'verify_attestation' (which verifies) by focusing on retrieval of existing certificates.

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 when to use (to check for a certificate) and includes guidance on computing the hash and not sending files. It lacks explicit advice on when not to use or direct comparisons to sibling tools, 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?

No annotations are provided, and the description only lists possible return values. It does not disclose behavioral traits such as whether the tool is read-only, requires authentication, or has rate limits. The agent lacks understanding of side effects or safety.

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 a single, well-structured sentence that front-loads the purpose and lists components and values efficiently. Every part 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 and no annotations, the description should explain the return format (e.g., whether it returns a single string or per-component object). It only lists components and values, leaving ambiguity about how the information is structured.

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 tool has no parameters, so baseline is 4. The description adds meaning by specifying the return values (ok, degraded, down, n/d) and components, which is helpful for interpreting results.

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's purpose: reporting health of attestation service components. It lists specific components (worker, archive, signer, anchor) and possible values, distinguishing it from sibling tools which perform other operations.

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 for checking service health but does not explicitly state when to use this tool versus alternatives, nor does it mention circumstances where it should not be used. No exclusions or context 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 discloses behavioral traits: it only checks the signature, requires exact metadata, and warns against sending file bytes. Without annotations, this adequately covers the tool's safety and idempotency, though it could mention if the tool has side effects or rate limits.

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 and front-loaded with the main purpose. It uses two paragraphs efficiently, but the second paragraph could be slightly tighter. Overall, it earns its length without being verbose.

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?

Despite clear purpose and parameter details, the description lacks information about return values or output behavior. Since there is no output schema, the agent would benefit from knowing what the tool returns (e.g., boolean success). This gap mildly reduces 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?

Schema coverage is 100% with detailed parameter descriptions. The description adds contextual value by explaining the requirement for exact metadata matching and the format of the attestation string, complementing the schema. The added meaning lifts it above the baseline of 3.

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 verifies the HMAC signature of an attestation, specifying what it confirms (authenticity and integrity of the attestation string and metadata) and what it does not (file matching). It distinguishes itself from other tools by focusing solely on signature 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?

Guidance is provided on when to use this tool (for HMAC verification) and when additional steps are needed (local file hash checking). It also emphasizes exact metadata matching. However, it does not explicitly compare to sibling tools like 'attest_hash' or 'create_certificate_pdf', which could clarify alternatives.

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