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 a prerequisite (ECASH_PRIVATE_KEY) and the condition that the job must be open. However, it does not describe the effects of acceptance, potential failure modes, or return value, leaving gaps.

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 short sentences with no redundant information. The key prerequisite is front-loaded, and every word contributes to understanding the tool's purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple with one parameter and no output schema, but the lack of annotations and minimal behavioral detail leave gaps about what happens on success or failure, and how this fits into the broader job workflow. It is adequate but not rich.

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 provides 100% coverage with a clear description of the single parameter 'jobId'. The description adds no additional parameter semantics, so 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 uses a specific verb ('Accept'), identifies the resource ('job'), and clarifies the actor role ('as a worker'). This clearly distinguishes it from sibling tools like ecash_create_job, ecash_get_job, and ecash_submit_work.

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 the tool is for workers to accept open jobs, but does not explicitly state when to use it versus alternatives or mention any prerequisites beyond the ECASH_PRIVATE_KEY. No exclusions or workflow context are provided.

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

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

With no annotations provided, the description carries the full burden of disclosing behavioral traits. It adds useful context like 'on Base mainnet' and 'any address', but it does not explicitly state that this is a read-only operation or describe any potential side effects, errors, or rate limits. The word 'check' implies non-mutating behavior, but no explicit safety or behavioral guarantees are made.

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 effectively communicates the tool's purpose without unnecessary words or restating the tool name. It is front-loaded with the verb and resource, making it easy 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?

For a simple read-only tool with one fully documented parameter and no output schema, the description is reasonably complete. It states the action, the asset (ECASH), the address scope, and the network. It does not explicitly mention the return format, but this is likely implied for a balance check. Given the tool's simplicity, this is a minor gap rather than a critical omission.

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 fully documents the single 'address' parameter (100% coverage), so the baseline is 3. The description adds meaning beyond the schema by specifying 'any address' and restricting to 'Base mainnet', which clarifies the network context and scope—information not present in the schema's description. This extra context helps the agent understand the valid input range.

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: 'Check the ECASH token balance for any address on Base mainnet.' The verb 'check' and the specific resource 'ECASH token balance' make the purpose unambiguous. The unique focus on balance distinguishes it from sibling tools like ecash_send or ecash_get_agent_info.

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 no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or direct them to other tools for related operations. The implied use case (checking a balance) exists, but no explicit context or contrasting directions are given.

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 clearly reports the financial outcome ('98% goes to worker, 2% is burned') and the authorization requirement, which are key side effects and constraints. This goes well beyond a simple 'confirms job' and provides essential transparency for an irreversible monetary action.

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-loaded with the core action, and every clause adds value: the payment split, the burn, and the authorization constraint. No redundant or filler content.

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 simplicity (one required parameter, no output schema, no nested objects), the description is fully sufficient. It explains the purpose, the key behavioral outcomes, and the access restriction. An agent has everything needed to invoke 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 only parameter, jobId, is fully described in the schema ('The ID of the job to confirm'). The tool description does not add additional parameter-level meaning, but with 100% schema coverage, the schema already provides sufficient semantics. The baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Confirm job completion'), the resource ('job'), and the downstream effect ('release payment to worker'). It distinguishes this tool from siblings like ecash_submit_work and ecash_accept_job by specifying the payment split and the authorization constraint, making its unique 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 implies when to use this tool (after job completion, only by the job poster) and states a hard prerequisite/constraint: 'Only the job poster can confirm.' It does not explicitly list alternative tools or state when not to use it, but the context is clear enough for an agent to select it appropriately.

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 behavioral burden. It discloses that a private key and sufficient ECASH balance are required, which is useful operational context. However, it does not mention side effects such as funds being deducted, immediate posting, or what is returned, leaving some behavioral uncertainty.

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 short sentences: the first states the action and resource, the second covers requirements. Every word earns its place and the purpose is front-loaded with zero 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 simplicity and full schema coverage, the description is mostly adequate. However, there is no output schema and the description does not mention the return value (e.g., job ID), so the agent may not know what to expect after creation, leaving a minor completeness 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 input schema has 100% description coverage for all three parameters, so the description does not need to add parameter details. It adds no parameter-specific information, but the high schema coverage justifies the baseline score 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 uses the specific verb 'Create' and identifies the resource as 'a new job in the ECASH marketplace,' clearly distinguishing it from sibling tools like ecash_accept_job or ecash_submit_work that perform different marketplace 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?

The description provides clear context that this tool is for creating jobs in the marketplace and adds prerequisites (ECASH_PRIVATE_KEY and sufficient balance). It does not explicitly mention alternatives or exclusions, but the distinct purpose among siblings makes usage obvious.

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 disclosure. It transparently reveals important behavioral traits: the Silver tier requirement, random selection for disputes, and the mandatory 25 ECASH stake per dispute. This goes beyond a simple 'enroll' by warning the user about the cost and unpredictability. It does not mention reversibility or what happens on insufficient funds, but coverage is good for a simple enrollment action.

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 concise sentences with no filler. The first sentence states the core purpose immediately, and the second provides essential prerequisites and consequences. Every word earns its place, and the structure is front-loaded and easy 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?

Given the tool's simplicity (0 params, no output schema), the description covers the main contextual aspects: what the tool does, who can use it, and the implications (random selection, staking). It does not describe the return value or post-enrollment steps in detail, but for an enrollment action, the description is reasonably complete and aligned with sibling tools like ecash_withdraw_arbitrator.

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 the input schema is empty (coverage is 100% vacuously). The description adds meaningful context by explaining the behavior of the tool (eligibility, staking, random selection), which compensates for the lack of parameters. Baseline for 0 params is 4, and the description does not detract from this.

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: 'Enroll as a dispute arbitrator.' The verb 'enroll' and resource 'dispute arbitrator' are specific, and the tool is easily distinguished from siblings like ecash_withdraw_arbitrator (opposite action) and ecash_file_dispute or ecash_vote_dispute (different dispute-related 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?

The description provides clear context for when to use this tool by stating the eligibility prerequisite ('Requires Silver tier (10+ puzzle solves)') and consequences ('randomly selected for disputes and must stake 25 ECASH per dispute'). However, it does not explicitly mention when not to use it or reference alternatives such as ecash_withdraw_arbitrator for unenrolling.

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 burden. It usefully discloses a 5% cost and that two AI arbitrators will vote, which are key behavioral outcomes. However, it omits other important behavioral details such as escrow impact, reversibility, eligibility, or what happens after filing.

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 short, information-dense sentences deliver the essential facts with no filler. Every word contributes meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with one parameter and no output schema, the description covers cost and process but lacks any indication of return values, side effects on escrow, or guidance on when a dispute is appropriate. This leaves meaningful gaps for a financial transaction 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 schema covers the only parameter (jobId) with a clear description, so the baseline is 3. The description adds no additional param semantics beyond that.

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 + resource: 'File a dispute on a marketplace job.' This clearly distinguishes it from sibling tools like ecash_vote_dispute (voting) and ecash_get_dispute (reading), as it initiates the dispute process.

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 implies when to use it (when a marketplace job needs disputing) and adds context about cost and arbitrators, but it does not explicitly contrast with alternatives such as ecash_get_dispute or ecash_vote_dispute, or state any preconditions like job status.

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 fully disclose behavioral traits. The verb 'Find' implies a read-only operation, but the description does not state any side effects, access requirements, result ordering, or behavior when no filters are applied. This leaves the agent guessing about important execution semantics.

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 short sentences, front-loaded with the core purpose. Every word earns its place—no fluff, no repetition. It efficiently conveys the main function and the primary use case.

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 relatively simple search tool with no output schema and no annotations, the description covers the essential purpose and a valid use case. However, it omits details like what the response contains, whether results are paginated (despite the 'limit' parameter), and how 'registered' is defined. This is acceptable for a minimal viable description but not comprehensive.

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 provides 100% coverage with descriptions for all three parameters, so the baseline is 3. The description adds some alignment by naming 'skill' and 'minimum tier', but does not add deeper semantics beyond what the schema already specifies. The 'limit' parameter is not mentioned, but its purpose is clear from 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 opens with a specific verb ('Find') and a clear resource ('registered agents') scoped by 'skill and minimum tier'. This clearly distinguishes it from sibling tools like ecash_get_agent or ecash_get_agent_info, which likely retrieve individual agents rather than search across them.

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 second sentence 'Useful for discovering agents that can complete specific tasks' provides clear context for when to use this tool. It does not explicitly mention alternatives or when not to use it, but the stated use case is unambiguous and differentiates from the other ecash 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 the full burden of behavioral disclosure. It only states 'Get the profile,' which implies a read operation, but does not explicitly confirm read-only behavior, error handling, permissions, or return format. This is insufficient for a tool with no annotation safety signals.

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 short, front-loaded sentence: 'Get the profile of a specific agent by their address.' No words are wasted, and it immediately conveys the action and target.

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 output schema or annotations, and the description provides only the basic action without explaining what a 'profile' contains, possible error cases, or how it differs from the similarly named sibling 'ecash_get_agent_info.' Given this ambiguity, the description is not complete enough for confident invocation in all situations.

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 fully describes the single parameter 'address' with the description 'The agent address to look up,' giving 100% coverage. The tool description repeats 'by their address' without adding any extra meaning beyond the schema, so a baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'Get the profile of a specific agent by their address.' It uses a specific verb and resource, but does not differentiate from the similarly named sibling tool 'ecash_get_agent_info', so it lacks sibling differentiation.

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 no guidance on when to use this tool versus alternatives, such as 'ecash_get_agent_info' or 'ecash_find_agents'. It simply explains what the tool does, leaving the agent to guess which lookup tool is appropriate.

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 transparency burden. The word 'View' clearly implies a read-only operation, which is a useful behavioral trait. However, it does not mention error conditions, required permissions, or whether the address must be registered, 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?

The description is a single, dense sentence that immediately states the action and key content. There is no filler or redundant information; every word contributes meaning.

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 lists the primary output topics (mining tier, arbitration stats, job history) but does not explain the output format or error behavior. With no output schema, a bit more detail would improve completeness, but for a simple one-parameter lookup it is reasonably 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?

The only parameter 'address' is fully described in the schema as 'The agent address to look up', so the schema already provides complete semantics. The description adds no additional details about the expected format or valid values, so 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 it views an agent's full profile and enumerates the contents (mining tier, arbitration stats, job history). The verb 'View' is specific and the resource is well-defined. It doesn't explicitly distinguish from the sibling ecash_get_agent, but the detail implies a broader scope than a basic agent lookup.

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 versus alternatives like ecash_get_agent or ecash_find_agents. The description only states what the tool does, not the context for choosing it over similar 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?

The description carries the full burden since no annotations are provided. The word 'View' signals a read-only operation, and the listed fields give some context, but it does not disclose error handling, authorization requirements, or whether the response includes only the named fields or the entire dispute object.

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 begins with the action verb and delivers the essential information without redundant words or repetition of the tool name. 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?

For a simple read tool with a single parameter and no output schema, the description provides adequate context by enumerating key return fields. However, the use of 'including' leaves ambiguity about additional fields, and it does not clarify if the tool requires the dispute to exist or if it works for any job ID.

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 description covers the jobId parameter fully ('The ID of the disputed job'), so the baseline applies. The tool description adds no extra meaning about the parameter beyond what the schema already states, providing no additional semantic value.

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 the specific verb 'View' and names the resource 'details of a dispute', explicitly listing the contained information (arbitrators, votes, outcome). This clearly differentiates it from sibling dispute action tools like ecash_file_dispute and ecash_vote_dispute, 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 implies this tool is used to inspect dispute details, but it provides no explicit guidance on when to use it versus alternatives, nor does it mention exclusions or prerequisites. The intended use case must be inferred from the tool name and context.

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 only says 'Get details' and does not mention error handling (e.g., job not found), return format, or whether the operation is read-only. This is minimal information beyond the tool name, leaving the agent with little insight into what happens on invocation.

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 with the key information front-loaded. Every word is relevant; there is no redundant or filler content.

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 get-by-ID tool, the description is adequate for basic invocation, but with no output schema, the agent is left guessing what 'details' are included. The description does not describe the return structure or any edge cases, making it minimally viable rather than comprehensive.

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 fully covers the single parameter with a description ('The ID of the job to retrieve'), and the description echoes 'by ID' without adding new semantic detail. Schema coverage is 100%, so the description does not need to compensate, giving a 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 a specific action ('Get details') on a specific resource ('job') with a qualifier ('by ID'). It distinguishes itself from sibling tools like ecash_create_job, ecash_accept_job, and ecash_submit_work, which perform different actions on jobs.

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 usage context is implied: use this tool whenever you need details of a job by its ID. However, there is no explicit guidance about when to choose this over alternatives, nor any exclusions or preconditions. It is the only job-detail getter among siblings, so the absence is not harmful, but no explicit guidance is provided.

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

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

No annotations are provided, so the description carries the burden. It discloses what is returned (puzzle poem, batch, era, reward), but does not explicitly state that this is a read-only operation or discuss any side effects, authentication, or rate limits. The 'Get' verb implies safety, but additional behavioral context is missing.

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, focused sentence that states the action, the target resource, and the return payload. No unnecessary words or 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?

As a parameterless read operation, the description is quite complete: it tells what the tool does and what it returns. It does not mention edge cases like the absence of an active puzzle, but for a simple getter this is acceptable.

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 no properties, and the description does not need to explain parameter semantics. With zero parameters, the baseline is 4, and the description adequately covers the tool's interface.

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 the verb 'Get' and identifies the resource as 'the current active puzzle for mining ECASH,' clearly distinguishing it from sibling tools like ecash_get_job and ecash_mining_status. It also specifies the return contents, which reinforces the purpose.

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 this tool is for retrieving the mining puzzle, but it does not explicitly state when to use it versus alternatives like ecash_get_job or ecash_mining_status. There are no exclusions or comparisons, so it relies on implied usage.

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 mentions the return list and fields but does not disclose behaviors like pagination, sorting, or the fact that it is a read-only operation. The absence of side effects is implied by 'browse' but not explicitly stated.

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 and front-loaded, with no unnecessary words. It delivers the purpose and return details in two sentences.

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 browsing tool with one optional parameter and no output schema, the description adequately covers the purpose and return fields. However, it lacks details like ordering and pagination, but these are not critical for a basic list operation.

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 100% coverage for the single 'limit' parameter, so the description adds no additional meaning beyond the schema. The description does not elaborate on how limit affects the returned list.

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 ('Browse') and resource ('open jobs in the ECASH marketplace'), and it differentiates itself from sibling tools like ecash_get_job which likely targets a specific job. It also specifies the return content (descriptions, amounts, deadlines).

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 a use case for finding available jobs but does not provide explicit guidance on when to use this tool over alternatives such as ecash_get_job or ecash_find_agents. There are no exclusions or alternative tool mentions.

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?

This is a read-only 'Get' operation, but the description doesn't explicitly state that it has no side effects or require no permissions. With no annotations available, the description carries the full burden of behavioral disclosure; while the verb implies a safe read, it could be more explicit about being non-mutating and about data freshness.

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 sentence that front-loads the action and resource, followed by a comma-separated list of the statistics included. No filler or redundant phrasing.

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?

As a zero-parameter, no-output-schema read tool, the description covers all necessary information: what the tool does and what it returns. The enumerated list provides sufficient detail for an agent to decide if this tool matches the user's intent.

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 takes zero parameters, so the schema is complete and the description doesn't need to elaborate on parameter semantics. The baseline for zero-parameter tools is 4.

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 'Get' with a clear resource 'ECASH mining statistics' and enumerates concrete data points (solved puzzles, batch, era, next reward, supply), distinguishing it from sibling tools like balance checks or puzzle retrieval.

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 for when to use the tool—whenever current mining statistics are needed. It doesn't explicitly name alternatives or exclusion cases, but the scope is well-defined and distinct from 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?

No annotations are provided, so the description must carry the behavioral disclosure burden. It discloses the precondition (expired, no work) but doesn't describe the effects of the reclaim, such as whether it's reversible or what happens if called on a non-expired job. This is a significant gap for a financial operation.

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 sentence that is direct and information-dense, with no wasted words. It conveys the core purpose and condition efficiently.

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 one well-described parameter and no output schema. The description tells the purpose and condition but omits return value or error behavior, which is important for a financial operation. Given the simple interface, the description is adequate but not fully 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 fully describes the only parameter (jobId), and the description aligns with the schema's own description. There is no additional semantic meaning provided beyond what the schema already gives, so a baseline score 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?

Clearly states the action (reclaim), the resource (ECASH), and the condition (expired job with no work submitted). This distinguishes it from siblings like ecash_accept_job or ecash_submit_work, 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 specifies the exact context for use: an expired job where no work was submitted. While it doesn't explicitly name alternatives, the condition is a clear trigger for when to invoke this tool. It could benefit from stating when NOT to use it, but the context is sufficient.

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 of behavioral disclosure. It only mentions a prerequisite ('Requires at least 1 puzzle solve') but does not disclose side effects, such as whether the profile is overwritten, whether it is permanent, or if any fees are involved. For a registration/mutation tool, this is insufficient 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 and every word earns its place. It states the purpose and a key prerequisite without any fluff or repetition, making it highly efficient and easy 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 tool is a simple registration action, so the description covers the core purpose and a critical requirement. However, it omits behavioral details like return values, idempotency, and potential errors, which would be helpful for an agent deciding whether and how to invoke it. The description is adequate but has clear gaps given no annotations or output schema.

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 provides 100% coverage of all three parameters (name, description, services) with clear descriptions. The tool description adds no additional parameter-level detail beyond what the schema already provides, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action: 'Register your agent profile on-chain.' This uses a specific verb ('register') and distinguishes it from sibling tools like ecash_enroll_arbitrator. The added prerequisite ('Requires at least 1 puzzle solve') further scopes the tool's purpose.

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 this tool is for registering an agent profile, which is a distinct use case from siblings. However, it does not explicitly state when not to use it or mention alternative tools. The prerequisite about puzzle solves provides some usage context, but no explicit 'when to use' vs. 'when not to' is given.

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 transparency burden. It discloses an important requirement (ECASH_PRIVATE_KEY env var), which is useful behavioral context. However, it doesn't describe what happens on success/failure, whether the transaction is irreversible, or any other runtime behavior. This is minimal but not misleading.

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 action and followed by the key prerequisite. Every sentence earns its place with no redundancy or 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 simple schema and no output schema, the description covers the core purpose and a critical setup requirement. However, for a mutation tool (sending tokens), it lacks information about return values, error handling, or network/transaction confirmation, leaving the agent with some uncertainty about the tool's full behavior.

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 'to' and 'amount' are described in the schema. The tool description adds no parameter-specific semantics beyond what the schema already provides, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool sends ECASH tokens to another address, with a specific verb ('Send') and resource ('ECASH tokens') and scope ('to another address'). It inherently distinguishes itself from read-only sibling tools like ecash_check_balance or ecash_get_job.

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 for when to use the tool (sending tokens) and an explicit prerequisite (ECASH_PRIVATE_KEY environment variable must be set). It doesn't explicitly name alternatives, but given the sibling list, it's the only send tool, so ambiguity is low. No exclusions or when-not-to-use guidance is provided.

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

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

No annotations are provided, so the description carries full burden. It adds a non-obvious auth requirement ('Requires ECASH_PRIVATE_KEY'), which is valuable. However, it does not disclose whether submission is final, reversible, or what side effects occur (e.g., payment release), leaving gaps in behavioral 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 short sentences, front-loaded with the action verb and object. Every word earns its place, with no redundant phrases or irrelevant details.

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 two-parameter tool with no output schema, the description covers the action, the prerequisite (accepted job), and the auth requirement. It lacks explicit information about the response or post-submission behavior, but given the tool's simplicity, this is sufficient for an agent to invoke it 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?

Schema description coverage is 100% for both parameters ('jobId' and 'result'), so the schema already documents them. The description adds no additional parameter meaning, matching the baseline for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Submit') and clearly identifies the resource ('completed work for a job you accepted'). It distinguishes itself from sibling tools like ecash_accept_job, ecash_confirm_job, and ecash_create_job by focusing on the post-acceptance submission action.

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 'for a job you accepted' provides clear context that this tool is used after acceptance and completion of a job. It does not explicitly name alternatives or exclusions, but the workflow context is sufficiently clear for an agent to select this tool at the right step.

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 explains the vote semantics but does not disclose whether the vote is final, reversible, or what side effects occur (e.g., payout processing). This is a notable gap, but the core behavior is not hidden.

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 action and the vote mapping. Every word earns its place; no fluff or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter tool with no output schema, the description is nearly complete. It explains the action, actor, and vote values, but omits details about what happens after voting or prerequisites beyond being assigned. Given low complexity, this is quite 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?

The input schema already provides complete descriptions for both parameters (vote and jobId), including the meaning of vote values. The description reinforces these values but adds no new information beyond the schema. With 100% schema coverage, the baseline score 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 ('Vote on a dispute'), identifies the actor ('assigned arbitrator'), and specifies the exact vote values (1 for Hirer Wins, 2 for Worker Wins). This distinguishes it from sibling tools like ecash_file_dispute and ecash_get_dispute.

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 'as an assigned arbitrator' provides clear context for when to use the tool. It does not explicitly mention when not to use it or name alternative tools, but the context is unambiguous enough for an agent to select it appropriately.

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 effects. It states 'You won't be selected for new disputes,' but fails to mention whether existing disputes are affected or if the action is reversible. This is a notable omission for a state-changing tool.

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 short sentences, front-loaded, with no unnecessary words. It effectively communicates the core action and a key consequence.

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 no-parameter tool, the description covers the primary purpose. However, it omits potential implications for existing disputes, which would be useful for the agent's decision-making. Somewhat incomplete given its 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?

The tool has zero parameters, so the description need not add parameter semantics. Per the rubric, the baseline score for no params is 4.

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 disables arbitrator status with 'Stop being an arbitrator.' It differentiates from the sibling tool ecash_enroll_arbitrator by indicating the opposite action.

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 implicitly conveys when to use it (when the agent no longer wants to arbitrate) but doesn't explicitly mention alternatives or exclusions. The presence of the sibling enroll tool provides context.

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