Glyt

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

No annotations are provided, so the description carries the full burden. It discloses that this is a polling operation (suggesting repeatability) and that the signed receipt appears 'once decided', which is a conditional behavior. However, it does not explain auth details beyond the id_token requirement, rate limits, or what happens if the request is not yet decided.

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 and front-loaded with the main purpose. Every clause adds value: the first sentence states the action, the second adds the prerequisite and return behavior. 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 simple polling tool with two parameters and no output schema, the description covers the core behavior: what it does, a key requirement, and what it returns. It lacks deeper caveats like failure modes or decisions on not-yet-decided requests, but these are minor given the tool's simplicity.

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 only mentions id_token (requiring the same one), but does not explain request_id at all. The parameter names are somewhat self-explanatory, but the description adds minimal semantic value for id_token and none for request_id.

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 polls one of the user's approval requests, which is a specific verb+resource combination. This distinguishes it from siblings like request_approval (creating) and get_receipt (retrieving a receipt separately). The mention of the signed receipt being included once decided further clarifies its role.

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 'Poll one of your approval requests' implies usage for checking the status of previously submitted requests. The requirement to use the 'same id_token' provides a prerequisite. However, it does not explicitly name alternatives or exclusions, so it stops short of a 5.

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 must carry the full burden. It implies a read-only discovery operation but does not explicitly disclose safety, side effects, return format, or limitations. The content list gives some idea of what is returned, but behavioral traits are largely unaddressed.

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, concise sentence that front-loads the purpose ('Glyt service discovery') and then lists the key items in a clear colon-separated format. There is no redundant or wasted language.

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 tool has no parameters, no output schema, and no annotations, so the description must provide sufficient context. It enumerates three content areas but does not specify the response format or how the 'how to verify' part is delivered. It also lacks guidance on when to prefer this tool over siblings, making it minimally adequate but incomplete.

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 is empty (0 parameters), so per rubric baseline is 4. There are no parameter details to explain; the description provides no parameter information and none is needed.

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 this is 'Glyt service discovery' and enumerates specific resources (issuer did:key, receipt schema version, offline verification instructions). It distinguishes itself from sibling action-focused tools by being an informational/discovery tool, though it lacks an explicit verb like 'retrieves' or 'returns'.

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: the phrase 'how to verify receipts offline' suggests this tool should be used when offline receipt verification is needed. However, it does not explicitly state when to use this tool versus siblings like verify_receipt or get_receipt, nor does it mention any exclusions.

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 the full burden. It transparently describes the signing process, the use of the user's own ed25519 key and id_token, and that Glyt writes as the user without holding secrets. It also details the exact JCS payload, which is a major disclosure. However, it omits side effects, return values, or error conditions, so it's not a 5.

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 front-loaded with the core purpose, but it is lengthy and dense with technical detail, including the full JCS payload specification. While every sentence contributes to understanding, it lacks brevity and structured formatting. It is appropriately sized for complexity but not concise.

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?

This is a complex mutation tool with no annotations and no output schema, so the description must explain the full context. It covers the signing procedure, the role, and the target_digest source, but it does not describe the return value, prerequisites (e.g., that a receipt must exist), or error states. The missing param explanations for receipt_id and reason also leave gaps.

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 67% (4 of 6 params described in schema). The description adds clarity for contestant_pubkey/sig (base64) and mentions the id_tokens, but it does not explain receipt_id or reason beyond context. The JCS specification helps understand the signing parameters but leaves gaps. The description partially compensates but is 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 the tool's function: as the SUBJECT of an approval, file a Bitcoin-anchored, self-signed objection into that receipt's contest channel. The verb 'file' and resource 'contest' are specific, and the subject scope is clear. It does not explicitly name sibling tools, so it doesn't fully qualify for a 5, but the purpose is unmistakable.

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 clear context: this tool is for the subject of an approval to file a contest. It implies when not to use it (if you are not the subject or have no receipt) but does not explicitly mention alternatives or exclusions. The role-based condition gives effective 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?

With no annotations, the description must disclose behavioral traits on its own. The verb 'Fetch' implies a read-only operation, but it does not mention error behavior, authentication requirements, or what happens if the receipt is not found. Minimal behavioral detail beyond the operational verb.

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, concise sentence that front-loads the action and resource. No filler or redundant wording; it earns its place without 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 the tool's low complexity (one param, no output schema, no annotations), the description is minimally viable: it states the action and target. However, it leaves gaps such as return format or possible error states, which would be valuable to know. It is adequate but not 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 input schema has one parameter (receipt_id) with 0% description coverage. The description's phrase 'by id' aligns with receipt_id but adds little semantic value beyond what the schema states—it does not clarify format, constraints, or relationship to the resource.

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 uses a specific verb 'Fetch' with a clear resource 'signed receipt envelope' and identifies how to target it ('by id'). This distinguishes it from sibling tools like check_approval or verify_receipt, which imply different actions.

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 is provided on when to use this tool vs. alternatives. The description simply states what the tool does without any contextual or exclusionary information about sibling 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?

With no annotations, the description carries the full burden. It reveals the id_token requirement, the asynchronous nature (returns a request view, poll with check_approval), and the crucial fact that nothing is approved without human decision. This adds meaningful behavioral context beyond the 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?

The description is three sentences long, with no redundant words. It front-loads the core purpose, then adds key context (auth, polling, human decision) in an efficient, well-ordered manner.

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 decent behavioral context, the description lacks explanation of the other parameters (action object, summary, stake_tier, callback_url) and the contents of the returned 'request view' are not described. With no output schema and low parameter coverage, the description is incomplete for full tool usage.

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% (only id_token has a description). The description also only explains id_token, leaving action, summary, stake_tier, and callback_url unexplained. The term 'specific action' vaguely relates to the action object but provides no structural or semantic detail.

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: asking the operator to approve a specific action. It distinguishes itself from siblings by naming check_approval as the follow-up polling tool, and the verb 'approve' is specific to this 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 description gives clear context on when to use the tool (to obtain a human decision) and directs the agent to poll with check_approval afterward. It does not explicitly exclude other tools, but the reference to check_approval provides practical 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?

With no annotations, the description carries the full burden. It discloses the return object and notes the offline authoritative check, which is useful context. However, it does not explicitly state side effects (e.g., non-mutating) or permission requirements, leaving some ambiguity.

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 concise sentences with no filler. The purpose is front-loaded, and the return structure is efficiently listed.

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 provides the return fields and key context (offline authoritative check) but lacks explanation of the optional parameters and decision/error semantics. Given no output schema and low annotation support, it is adequate but not 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?

Schema description coverage is only 25%. The description clarifies the roles of 'action' and 'receipt' but does not explain 'required_acr' or 'expected_agent_sub'. The return field 'acr' hints at required_acr but no explicit linkage is made, leaving key parameters underspecified.

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 function with a specific verb ('Verify') and resource ('a Glyt receipt against the exact action you are about to run'). It distinguishes from siblings like get_receipt and check_approval by emphasizing pre-action 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?

The description conveys when to use the tool ('about to run') and adds context about the authoritative offline check being separate from this convenience wrapper. It does not explicitly name alternatives or exclusions, but the use case is clear.

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