Redeal

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

With no annotations, the description carries the burden of behavioral disclosure. It clearly states that nobody, including redeal, can see the input until all parties commit, and that the deal opens for reveals after the last commitment. This goes beyond a simple 'commits input' statement and explains the sealed-mode 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, front-loaded with the primary purpose, and includes essential protocol detail without any filler. Every sentence earns its place.

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 explains the key workflow (sealing, multi-party commitment, reveal trigger) and is sufficiently complete for a commitment action. It does not cover edge cases like idempotency or error conditions, but the schema already documents the idempotency key. Given the absence of an output schema, this is adequate.

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%, so the schema already documents every parameter thoroughly. The description adds no additional parameter-level meaning beyond what the schema provides. A score of 3 is the baseline when schema is complete and covers all parameters.

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 says "Commit your sealed input as a hash (sealed mode)", which is a specific verb+resource combination. It clearly distinguishes from sibling tools like reveal_input and compute_commitment_tool by focusing on the act of committing the prepared 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 explains the commitment protocol context (all parties must commit before anyone can see inputs, and reveals open after last commit). It implies the tool is used after computing a commitment and before revealing, though it doesn't explicitly name alternatives or state when not to use it.

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 provided, the description carries the full burden. It fully discloses the exact algorithm (sha256(JCS(input) ++ salt_bytes)), the output prefix 'sha256:', and implies no side effects via 'Convenience only.' This is strong transparency, though it could be even more explicit about not persisting anything.

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?

A single, precise sentence conveys the purpose, algorithm, and optionality without any filler. The formula is compact and highly informative, making it easy for an agent to parse.

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 specifies the exact computation and output format, making the tool's behavior fully defined. It does not explain JCS, but for a pure helper in a cryptographic protocol context, the missing nuance is not critical. Overall, the description is adequate for a no-output-schema compute 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 input schema already provides 100% coverage of both parameters, including salt's hex format and the requirement to keep it secret. The description adds no additional parameter-specific meaning, so the baseline score 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 identifies a specific verb ('Compute') and a clear resource (commitment string) with the exact formula. By framing it as 'Convenience only,' it distinguishes itself from sibling tools that likely store or manage commitments, making the tool's role 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 states 'Convenience only — the rule is public and you can compute it yourself,' which clearly indicates this is an optional helper rather than a required workflow step. While it doesn't explicitly name alternatives like commit_input, the convenience framing and algorithmic detail implicitly guide when to use this 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 provided, the description carries the behavioral burden and does add useful context: it returns a deal id and per-party tokens, and it explains the sealed-mode commit/reveal flow and automatic certification. However, it omits other behavioral traits like error/expiry outcomes, idempotency behavior, or the public persistence of party labels.

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 compact and front-loaded: it states the core action, the caller's role, the return value, and the key sealed-mode flow in four short sentences. Every sentence contributes meaningful, non-redundant 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 13-parameter mutation tool with no output schema and no annotations, the description covers the core outcome and sealed-mode behavior but leaves gaps around open mode, deadling consequences, and post-creation steps. It is adequate for orientation but not fully complete for a tool of this 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?

Schema description coverage is 100%, so the schema already explains every parameter. The description adds minimal parameter-related meaning beyond tying party_labels to "party 0" and token distribution, which the schema also mentions. This meets the baseline but does not elevate it.

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 the specific verb+resource: "Create a fairness deal." It also establishes the caller's role as "party 0 (initiator)" and clarifies the tool's outputs (deal id and invite tokens), clearly distinguishing it from siblings like get_deal, commit_input, or create_key.

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?

There is no explicit guidance about when to use this tool versus alternatives. While "initiator" and "give each counterparty their own token" imply a workflow, the description never states prerequisites, sequencing with commit_input/reveal_input, or exclusions such as when open mode would be preferable.

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 critical behavioral traits: "No signup, no email" (auth expectations) and "The key is shown once; store it" (one-time display, irreversible if lost). This is highly informative for an agent.

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, front-loaded with the main purpose, and every sentence carries meaningful information. No redundant phrases or filler.

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 is complete: it explains purpose, the critical one-time display behavior, and how to use the result. No 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?

The tool has zero parameters, so schema coverage is trivially 100%. The description adds value by explaining how the output (the key) should be used, though it doesn't need to explain parameter semantics since none exist.

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 begins with "Get a free redeal API key," which is a specific verb and resource, clearly distinguishing this tool from siblings like create_deal and get_certificate. It also states this is the entire onboarding, removing ambiguity about 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 description explicitly notes "Use it as api_key in create_deal," providing clear context for when to use this tool. While it doesn't explicitly exclude alternative tools, the unique purpose of key generation makes the usage context 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?

With no annotations, the description carries the full burden. It indicates a read-only operation via 'Fetch' and discloses the return contents (labelled signature, transparency-log inclusion proof). It also implies a behavioral requirement (deal must be CERTIFIED). It lacks explicit statements about side effects or rate limits, but for a getter this is generally adequate.

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, front-loaded with the core purpose and includes key details about the response format without unnecessary filler. Every sentence serves a purpose, making it 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?

Since there is no output schema, the description compensates by naming the certificate's components (signature, inclusion proof). It also states the required deal state and ties to verify_certificate. It could mention error handling or authorization nuances, but the provided context is largely sufficient for a simple fetch with documented params.

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 both deal_id and credential fully described in the input schema. The description adds no extra parameter semantics, so the baseline of 3 applies as the schema already carries the weight.

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 ('Fetch'), the resource ('signed fairness certificate'), and the condition ('finished deal (state CERTIFIED)'). It distinguishes from siblings by specifically naming the certificate and pointing to verify_certificate for the next step, making it unique among the getter 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?

It explicitly scopes usage to deals in CERTIFIED state, providing a clear prerequisite. It also hints at the workflow by suggesting verify_certificate for verification, which is an implicit alternative. However, it does not state when not to use the tool or mention other tools like get_deal for non-certified deals.

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 behavioral burden. It explicitly discloses that inputs of other parties are never exposed, which is a key privacy guarantee, and notes that certificate_id appears only once issued. It also signals a read-only operation via 'Read', though it does not detail error behaviors 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 two sentences with no filler. It front-loads the action ('Read a deal's public state') and packs essential details about the contents and privacy behavior. Every phrase 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?

There is no output schema, so the description appropriately lists the return fields (state, parties, deadlines, result, certificate_id). It also mentions the privacy guarantee. It does not cover error scenarios, but for a simple read operation with two documented parameters, this is sufficiently 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 already provides 100% coverage of both parameters (deal_id and credential), so the description does not need to compensate. It adds minimal extra meaning about the parameters themselves, but it does clarify what the deal_id represents through the context of public state. 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?

The description uses a specific verb 'Read' with a clear resource: 'a deal's public state'. It enumerates the exact contents (protocol state, parties, deadlines, result, certificate_id) and differentiates from siblings like get_certificate or verify_certificate by focusing on the full public state rather than a specific artifact.

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 clearly implies the tool is for reading public deal state, but it does not explicitly state when to use it versus alternatives such as get_certificate or verify_certificate. No exclusionary guidance is provided, leaving the usage context inferred rather than stated.

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 the full burden. It discloses the state transition (REVEALING → done), the source of randomness (public League of Entropy beacon), the public verifiability of the drand round, and idempotency. This goes well beyond a minimal statement and gives the agent a solid mental model of side effects and 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?

Three sentences, each earning its place: purpose/mechanism, timing/state, and idempotency. No fluff, no repetition, and the most important action verb starts the description.

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 complexity (external beacon, cryptographic draw, certificate issuance, state machine), the description covers all key aspects: precondition (all reveals), process, state effect, and retry safety. While there is no output schema, the description mentions the certificate and public checkability, which is sufficient for an agent to understand the result.

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%—both deal_id and credential already have clear descriptions. The tool description adds context about the deal lifecycle (after last reveal) but does not add new parameter-specific semantics. Baseline of 3 is appropriate because the schema is sufficient.

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+resource combination: 'Finish a random.v1 deal' followed by the mechanism (fetch drand round, compute draw, issue certificate). This clearly distinguishes it from siblings like get_certificate (which likely retrieves an existing certificate) and reveal_input (which submits reveals).

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?

Explicit usage timing is provided: 'Call this after the last reveal_input; the deal rests in REVEALING until you do.' It also notes idempotency ('safe to retry'), which directly informs when and how often the tool may be invoked. This is clear contextual guidance without needing to name alternatives.

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 provided, the description carries the full burden of behavioral disclosure. It discloses that the tool returns the full JSON including outcome, works only for public deals, and returns NOT_FOUND for parties-only or unknown IDs. It does not mention potential side effects (though it's a read operation) or error handling beyond NOT_FOUND, but for a simple fetch tool this is adequate transparency.

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, front-loads the core action and result, and then provides an alternative. Every sentence adds value: the first states what it does and the key caveat, the second directs users to alternative tools. 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?

Given the low complexity (one parameter, no output schema), the description fully covers the necessary information: what it returns, the expected cases, and alternatives. It is complete enough for an agent to select and invoke the tool correctly without needing additional context.

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 has 100% coverage of the single parameter cert_id, including its format and a note about free verification. The description does not add additional parameter semantics beyond that, but it does reinforce that the ID is used to fetch the certificate. With high schema coverage, 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 action (fetch), the resource (a certificate's full JSON including outcome), and the scope (by id, for public deals). It distinguishes itself from sibling tools like verify_certificate (which re-verifies computation) and get_certificate (presumably a different retrieval variant). The statement about parties-only deals and unknown IDs adds specificity.

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 tells when to use this tool (fetching public deal certificates) and when not to (for re-verification, use verify_certificate or the CLI re-runner). It also notes the limitation for parties-only deals, which is essential guidance for correct tool selection.

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 the full burden. It explains what the tool lists (algorithms, input contracts, test vectors) and notes the test vectors are served inline and are the same fixtures the engine test suite runs. This gives useful behavioral context. A small gap is not explicitly stating it is read-only, but that is implied by '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 one sentence that front-loads the purpose ('List redeal's algorithms') and then provides specific details in a parenthetical list. Every piece of information is useful; there is no redundancy or wasted words. The usage guidance is appended naturally.

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 fully explains what is returned: the algorithms with their input contracts and test vectors. It also gives a usage hint. There is no missing information needed for an agent to understand and use this 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 tool has zero parameters and schema coverage is 100%. The description does not need to add parameter information, and the baseline for zero-parameter tools is 4. The description does not detract from parameter understanding.

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 explicitly states it lists redeal's algorithms and enumerates them by name (split.v1, random.v1, shapley.v1, auction.v1) along with a brief explanation of each. This clearly distinguishes the tool from sibling tools like create_deal or commit_input.

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 ends with explicit guidance 'Read this before creating a deal', indicating the tool should be used early in the workflow. While it doesn't list when not to use it or alternatives, the context is clear enough for an agent to understand its role.

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 provided, the description carries full burden. It discloses that input validation occurs ('must hash to your earlier commitment'), that the action triggers automatic computation and certificate issuance if last party, and that the certificate is fetched separately. However, it omits side effects (e.g., does reveal lock the input?), error behavior (hash mismatch?), and whether the tool is read-only or mutating. The idempotency_key parameter is not referenced in the description.

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 that front-load the action, add a constraint, and provide follow-up guidance. Every sentence earns its place—no wasted words. Perfectly sized for quick comprehension.

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 the basic flow (commit → reveal → certificate) and references a sibling tool for the next step. However, it does not describe the return value of the tool itself, error conditions, or what happens if the party is not the last to reveal. Given the absence of an output schema, more detail on the response would improve 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 description coverage is 100%, so baseline is 3. The tool description does not add parameter-level information beyond what the schema already provides (the algorithm-specific input formats are documented in the schema's input property description). The description only adds general behavioral context, not per-parameter semantics.

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 action: 'Reveal your committed input.' It distinguishes itself from sibling tools like commit_input (which commits) and get_certificate (which fetches the resulting certificate) by describing the trigger: 'When the last party reveals, the deal computes and the fairness certificate is issued automatically.' The verb 'Reveal' plus resource 'committed input' is specific and differentiated.

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 for when to use the tool: after commitment (input must hash to earlier commitment) and before fetching the certificate. It explicitly points to a sibling tool ('fetch it with get_certificate') for the follow-up action. However, it does not explicitly state when NOT to use the tool or list alternatives; the flow is implied rather than enumerated.

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 explicitly states 'Read-only: nothing is stored or changed,' which is critical behavioral info and aligns with the read-only nature of validation. It also reveals the irreversible binding behavior of commit, indirectly clarifying this tool does not bind.

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 paragraph of 4 sentences that efficiently conveys purpose, usage, consequences, and safety. Every sentence earns its place—no redundancy or filler. Front-loaded with the core action ('validate your algorithm input against the deal's contract').

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 has 3 parameters with 100% schema coverage, no output schema, and no annotations, the description fully compensates. It explains what the tool does, why it's critical (prevents irreversible contract violations), the correct sequence with sibling tools, and the read-only nature. No significant gaps remain.

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%, so baseline is 3. The description adds value beyond the schema by explaining the validation purpose and giving a concrete example of valid input format (e.g., split.v1 valuations summing to 1000). However, it does not elaborate on the other two parameters (deal_id and invite_token) 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 validates algorithm input against the deal's contract before commitment. It uses specific verb ('validate') and resource ('algorithm input against deal's contract') and distinguishes itself from siblings like commit_input and compute_commitment_tool by emphasizing the pre-commit validation step.

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 tells when to use this tool ('before you commit') and provides a strict sequence: 'validate first, then compute_commitment_tool, then commit_input.' It also warns against skipping validation by explaining the irreversible consequence of committing a contract-violating input (deal will VOID).

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?

Without annotations, the description carries the full burden. It discloses the specific checks performed (signature with current/legacy key, transparency-log inclusion) and the free/no-credential nature. It stops short of describing the output format or error behavior, but the 'reported per check' hint is useful.

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 packs in valuable details (checks, key types, free/no-credential guarantee). Every word earns its place.

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 verification tool with one parameter and no output schema, the description covers the essential context: what is verified, how, and under what conditions. It could be more complete by explicitly describing the response structure of the per-check report, but 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?

The schema already provides full coverage for the single parameter (cert_id) with a description that includes 'Verification is free and always will be.' The tool description repeats this information without adding new parameter-level meaning, so no significant value is added beyond the 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 the tool's function: 'Verify a redeal certificate by id' with specific details on the verification process (signature check + transparency-log inclusion check). This distinguishes it from sibling tools like get_certificate or validate_input.

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 on when to use the tool: it is free, requires no credentials, and can always be used. However, it does not explicitly mention alternatives or when not to use it, leaving some room for inference.

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