POPCORN MCP

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds that the data is live and that no payment is required, but it does not describe return format or pagination 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 definition is two short sentences with no wasted words. The primary purpose is front-loaded before the cost note.

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 no-parameter read-only catalog tool with strong annotations, the description communicates enough to call it correctly. It does not describe the shape of the returned catalog/offer/verification-key data, which is a minor gap because no output schema exists.

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 zero parameters, so there are no parameter semantics to explain; a baseline of 4 is appropriate. The description does not need to compensate for missing parameter documentation.

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 names a specific verb ("Read") and specific resources ("live catalog, offer, and published verification keys"). It is clear what the tool retrieves, though it does not explicitly differentiate itself from sibling tools such as popcorn_verify or popcorn_sample.

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?

Usage is implied by the resource being read, but there is no explicit guidance on when to use this tool versus the many sibling tools. The "Free; no payment" note adds cost context but not selection criteria.

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 declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description earns credit for disclosing the privacy-relevant fact that submitted text reaches the server and that the call is free with no onward request — real value beyond the annotations — but it says nothing about the hash algorithm, output format, or size 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?

Three compact clauses, zero waste, with the core action and the privacy warning front-loaded before the cost note.

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 should have said what comes back (algorithm, digest encoding), and it doesn't. It also leaves the two-parameter structure unexplained, though it does cover the most agent-critical risk — sending private data to a remote server — well.

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 0% and neither parameter is documented anywhere. The description's words 'text' and 'bytes' loosely hint at payload_text vs payload_base64url, but it never explains which to supply, whether they are mutually exclusive, or that both are optional (required count 0).

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?

States a specific verb and resource: 'Hash public bytes on this remote server.' The purpose is unambiguous and distinct from the sibling tools (catalog, sample, time, verify, witness), though it never names or contrasts them explicitly.

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?

Gives a clear when-not rule: 'hash private work locally instead,' which tells the agent the key selection condition — only public data belongs here. No sibling is named as an alternative path, and the mutual exclusivity of the two payload parameters is left unaddressed.

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 declare read-only, closed-world, idempotent, non-destructive behavior. The description adds valuable context: it explicitly states no inputs/wallet/payment/outbound request, clarifies it uses historical evidence, and warns that bundled sample keys do not establish issuer identity. That caveat is crucial for interpreting the result.

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?

Four concise sentences, with the primary action front-loaded. 'Historical evidence, not a fresh clock' is slightly cryptic but otherwise the text is efficient and well-structured.

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 no-parameter tool with no output schema, the description should explain what the tool returns or what a 'TAIN 2.0 receipt' and 'changed-digest control' mean. It does not, leaving the agent unable to predict the output or understand the verification scope.

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?

Tool takes zero parameters, so the schema and description are not burdened with parameter semantics; baseline 4 applies. The description correctly notes there are no inputs.

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?

It states a specific action ('Check') and a specific target ('public October 14 TAIN 2.0 receipt and a changed-digest control'), but 'TAIN 2.0' is undefined and there is no differentiation from the sibling verify tools, leaving the agent unsure why this sample tool exists alongside popcorn_verify.

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?

No guidance on when to use this tool versus popcorn_verify or popcorn_verify_v2. The absence of exclusions or alternatives means the agent must guess based on the name alone.

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 declare destructiveHint=true and openWorldHint=true, and the description materially explains why: a $0.001 USDC charge on Base, owner approval plus approve_payment:true, a caller-signed signature, no server wallet, and no automatic retry. That is real behavioral context beyond the annotations. It stops short of describing what happens on a failed/expired payment or what the receipt contains.

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?

Five short sentences, front-loaded with the core action and cost, then the payment preconditions, then the deadline caveat. The telegraphic fragments ('No automatic retry.', 'No server wallet or private key.') are terse but each carries a distinct constraint.

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 and a payment-gated flow, the description should convey what 'evidence'/'receipt' actually looks like and how the 402 challenge resolves, but it stays abstract. It is adequate for cost and approval mechanics yet incomplete on return shape and the freshness_ms parameter.

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 only 33%, so the description must compensate, and it does explain approve_payment and payment_signature (owner approval, caller-signed, no private key). But freshness_ms — the default-30s, max-60s freshness window — is never mentioned in the description or the schema, leaving a meaningful gap.

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 opens with a specific verb and resource ('Request signed current-time evidence'), which tells an agent exactly what the tool produces. It does not explicitly name the sibling tools it complements or contrasts with (e.g. popcorn_verify), so differentiation from siblings is only implied by the final sentence.

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?

It establishes context — free 402 challenge by default, paid fresh receipt when needed, verify before a deadline decision — which implies when to call it. However, it never states when NOT to use it or names popcorn_verify/popcorn_catalog as the explicit alternatives, leaving the routing decision to inference.

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 declare readOnly, idempotent, and closed-world, yet the description adds substantive trust-model caveats: digest-only handling of witness payloads, no outbound request or payment, and that caller keys do not establish issuer identity and a signature grants no authority. These go beyond the annotations, though 'Digest-only for witness payloads' is terse and leaves the actual constraint ambiguous.

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?

Four compact sentences with no filler, and the core action is front-loaded. It is dense to the point of being cryptic in places, but every sentence carries distinct 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 tool with four required nested-object parameters, no output schema, and no parameter documentation, the description covers the operation and trust model but omits parameter formats and says nothing about the result shape (a verified/not-verified outcome, error handling). An agent could call it but would be guessing on argument construction.

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% across four required parameters, three of which are untyped nested objects (jwks, response, verification). The description only loosely gestures at 'JWKS' and 'expected values' and says nothing about what belongs in 'response' or the 'verification' object, so it does not compensate for the coverage gap.

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?

States a specific verb and resource ('Verify a time or witness receipt') and names the inputs (caller-trusted JWKS, expected values). It does not differentiate from the sibling popcorn_verify_v2, which is the obvious ambiguity for an agent picking a tool.

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 phrase 'using caller-trusted JWKS and expected values' implies the context (caller-side verification against known keys) and 'No outbound request or payment' rules out a class of alternatives. However, there is no explicit when-to-use/when-not guidance and no reference to popcorn_verify_v2, popcorn_time, or popcorn_witness.

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 declare read-only, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds meaningful disclosure beyond that: the caller-supplied jwks is silently replaced with published keys including predecessors, the service is free, and it explicitly disclaims granting authority, establishing current time, or verifying on-chain settlement. That last sentence is unusually useful scope-limiting information.

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 that are front-loaded with the operative action and follow with key-replacement semantics and scope disclaimers. No filler, though the final disclaimer clause is somewhat compressed into a list that requires parsing.

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 verification tool with a deeply nested recursive schema and no output schema, the description gives the essential trust model (issuer keys replace caller keys, predecessors included) but leaves the response shape and most parameter contracts unexplained. It is enough to understand intent, not enough to call correctly without reading the raw schema closely.

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% across 7 parameters, so the description must carry the load. It explains the most counterintuitive one (jwks is overwritten, not trusted) and hints at the digest requirement, but says nothing about expected_nonce, expected_node_id, the recursive previous_receipt chain used for predecessor key verification, or what max_clock_accuracy_radius_ms controls.

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?

States a specific verb and resource: verify TAIN 2.0 evidence against keys from the fixed POPCORN issuer URL. That is concrete and scoped. It stops short of distinguishing itself from the sibling popcorn_verify (presumably the v1 path), so an agent must infer the difference from the version suffix alone.

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?

'Send a digest, never private work' is a real usage constraint, and the closing clause defines what the tool does not do. But there is no explicit routing guidance against the other six siblings, notably popcorn_verify, and no stated preconditions for choosing this over the v1 variant.

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?

Despite annotations already flagging destructive/openWorld, the description adds substantial context: exact price and network (Base), the free 402 challenge default, the owner-approval + approve_payment + signed signature prerequisites, no automatic retry, key-hygiene guidance, and an explicit caveat that evidence does not prove execution. That is richer behavioral disclosure than the annotations alone.

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?

Front-loaded with the core action and the cost/approval constraint, and every sentence carries information (price, approval, key safety, no retry, semantic limit). The compressed, clause-stacked style borders on telegraphic but wastes little.

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 costly, destructive, 5-parameter tool with no output schema, the description covers cost, prerequisites, retry behavior, and semantic scope. Gaps remain around the purpose of previous_attestation_digest and what a receipt actually contains, but the essentials for correct invocation are present.

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 only 20%, so the description must carry the load; it does explain digest, nonce, approve_payment, and payment_signature roles reasonably. But previous_attestation_digest is undocumented in both schema and description, and the 43-character base64url constraints are left to the pattern only.

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?

States a specific verb and resource — 'Witness a SHA-256 digest and fresh caller nonce at a time' — which is clearly distinct from hashing or verifying. It doesn't explicitly name how it differs from siblings like popcorn_hash or popcorn_verify, but the action is concrete enough to route on.

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?

Explains the payment flow (defaults to a free unpaid 402 challenge, then $0.001 USDC per receipt requiring approve_payment and a signed payment_signature) and warns 'No automatic retry'. However, it never states when an agent should choose this over popcorn_verify or popcorn_hash, and the free-vs-paid decision path is only implied.

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