AGI Alpha

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

With no annotations, the description carries the full burden. It discloses that it returns calldata (not executing), requires an ENS subdomain, and imposes a bond. This is valuable behavioral context, though it could mention side effects more explicitly.

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 concise, front-loaded sentences with no redundancy. Every sentence adds value: purpose, prerequisites, and output.

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 two-parameter tool with full schema coverage, the description is complete. It covers the action, requirements, output format, and a key constraint (bond). No output schema exists, so the return calldata note is especially helpful.

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%, so the baseline is 3. The description references the ENS requirement and bond but doesn't add parameter-specific meaning beyond the schema's own descriptions. Thus it meets the baseline without exceeding 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 clearly states the tool prepares a transaction to apply for a job, with specific prerequisites (ENS subdomain) and outputs (approve + apply calldata). This distinguishes it from siblings like register_agent or approve_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?

It provides clear context on when to use: requires a specific ENS subdomain and a 5% bond. It doesn't explicitly exclude alternatives, but the prerequisites and transaction-preparation nature imply the intended workflow.

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 discloses prerequisites (ENS subdomain, bond) and the fact that it only 'prepares' a transaction, not executes it. However, it does not describe what happens after preparation, what the transaction contains, or any side effects. This is partial 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 three sentences long and every sentence carries substantive information: what the tool does, the identity requirement, and the bond requirement. There is no fluff or repetition, making it efficient and front-loaded.

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?

Without an output schema or annotations, the description should explain what the prepared transaction looks like or what the tool returns. It covers prerequisites well but omits the result/outcome of preparing the transaction and how the bond is posted. Given moderate complexity, it is adequate but has clear 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 input schema already covers 100% of the parameters with clear descriptions. The tool description adds context about prerequisites (ENS subdomain, bond) but does not explain parameter semantics further. Since the schema is complete, a 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 identifies the action: 'Prepare a transaction to approve/validate a job as a validator.' It names the specific resource (a job) and the role (validator), and the context of sibling tools (e.g., disapprove_job, dispute_job) helps distinguish this from other job-related actions. It does not explicitly contrast with siblings, so it falls short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives important conditions for use: requiring an ENS subdomain under club.agi.eth or alpha.club.agi.eth and posting a 15% bond. It implies the tool is for validators, but it does not explicitly state when to use this over alternatives like disapprove_job or finalize_job. No exclusions are provided, making the guidance useful but not comprehensive.

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

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

With no annotations, the description carries the full burden. It discloses the 'prepare a transaction' behavior (cancellation may not be immediate), the permission requirement ('Only the employer can cancel'), and the consequence ('Escrow is returned'). This gives meaningful behavioral insight, though it does not detail the transaction structure or next steps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three concise sentences, front-loaded with the primary action, followed by two essential qualifiers. Every sentence adds valuable information with 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 tool with one parameter and no output schema, the description covers purpose, restrictions, and side effects. However, 'Prepare a transaction' is slightly ambiguous and could benefit from mentioning what is returned or how to finalize the cancellation, but the overall context is sufficient.

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 full coverage for jobId with the description 'The job ID to cancel.' The tool description adds no extra parameter semantics beyond contextualizing the job as open/unassigned, which does not change the meaning of jobId. Thus, score is at baseline.

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

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

The description clearly states the tool's action: 'Prepare a transaction to cancel an open (unassigned) job.' It specifies the resource (job), the scope (open/unassigned), and the actor restriction (only employer can cancel), which distinguishes it from sibling tools like approve_job or disapprove_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 this tool: it is for canceling an open unassigned job and only the employer can do it. This implies it should not be used for assigned jobs or by non-employers, though it does not explicitly name alternative tools or scenarios.

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 transparency burden. The verb 'check' implies read-only behavior, and the description discloses the return information (registration status and payout percentage). However, it does not explicitly state that the operation has no side effects or require any permissions.

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 no 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 simple query tool with one parameter and no output schema, the description adequately explains what the tool checks and what it returns. No major 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 schema provides a description for the 'address' parameter with 100% coverage, so the baseline is 3. The tool description adds no additional parameter semantics beyond what the schema already states.

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 ('Check whether...') and a specific resource ('Alpha Agent Identity NFT registration'), plus the additional result (payout percentage). This distinguishes it from sibling tools like register_agent and get_agent_reputation.

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 use case (checking registration status) but does not explicitly say when to use this tool vs alternatives, nor any exclusions or prerequisites.

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?

Discloses that the tool only prepares calldata rather than executing the transaction, and that two transactions must be sent in order. It also discloses the exact JSON structure requirement and the dependence on upload_to_ipfs. Since no annotations are present, this description carries the full burden and does so effectively.

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 lengthy but well-structured with clear STEP markers and a necessary JSON template. It front-loads the purpose and every element serves a functional role, though the length prevents a perfect score.

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 complex tool with no output schema, the description is remarkably complete. It covers the full workflow: IPFS upload, parameter usage, transaction ordering, and return value, providing all necessary context for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds meaningful context by explaining that jobSpecURI comes from upload_to_ipfs, and by tying payout and durationDays to the job spec fields. This improves understanding beyond the schema's individual parameter descriptions.

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: preparing a transaction to create a new job on AGI Alpha, returning calldata for two transactions. It distinguishes itself from sibling tools by explicitly detailing the creation workflow and the need for prior IPFS upload.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit step-by-step instructions: first upload the job spec to IPFS, then call this tool with jobSpecURI, and finally send the approve transaction before createJob. It does not explicitly name alternatives, but the workflow clearly differentiates it from sibling job management tools.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It does add useful context by stating 'Prepare a transaction' (indicating this is not an immediate submission) and mentioning the 15% validator bond prerequisite. However, it does not disclose what the return value is, whether the transaction needs to be signed/broadcast separately, or any failure conditions that might arise if the bond is not met.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that front-loads the purpose and then provides prerequisites. Every word contributes meaning; there is no fluff or repetition. It is highly efficient.

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 is competent for a 2-parameter tool but missing key details given the lack of an output schema. It fails to explain what the prepared transaction looks like or how it should be used afterwards, which is critical for a 'prepare' action. It also does not mention whether the bond is deducted exactly at preparation time or after submission. Overall, it is adequate but has clear gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The schema already describes both jobId and ensSubdomain clearly. The description adds context about the ENS subdomain being required for validator identity and the bond, but it does not provide parameter-specific details beyond what the schema already contains.

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: 'Prepare a transaction to disapprove a job as a validator.' This is a specific verb and resource, and it distinguishes itself from the sibling 'approve_job' tool by explicitly stating the opposite action. The role of validator adds context that makes 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 usage context by specifying prerequisites ('Requires club.agi.eth ENS subdomain and a 15% validator bond'), but it does not explicitly say when to use this tool versus alternatives like dispute_job or approve_job. It provides conditions for use but no exclusions or guidance on choosing between 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?

With no annotations, the description carries the transparency burden. It reveals that the action is to 'prepare a transaction,' implying a preparatory step rather than a final execution, and states the role/time restriction. However, it does not describe side effects, return values, or what happens after preparation, leaving key behavioral details undisclosed.

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 includes only essential constraint information. No redundant or fluff content is present.

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 a simple interface (one parameter, no output schema), and the description covers the core purpose and key constraint. However, the phrase 'prepare a transaction' is ambiguous—it does not clarify whether the dispute is executed immediately or requires a subsequent step, leaving some incomplete 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 input schema fully documents the single parameter 'jobId' with a clear description ('The job ID to dispute'). The tool description adds no further parameter meaning, so the baseline score of 3 applies due to 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 clearly states the action ('Prepare a transaction to dispute a job') and the specific resource (a job). It distinguishes itself from sibling tools like 'approve_job' and 'cancel_job' by the unique action '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 description provides explicit usage constraints: 'Only the employer can dispute during the review period.' This tells the agent when the tool is appropriate (employer role, review period) and implicitly when it is not. However, it does not explicitly name alternative tools, so it misses the top score.

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 discloses key behavioral effects: 'Employer gets refunded, agent bond is slashed.' It also hints at a non-executing action by saying 'Prepare a transaction,' but does not elaborate on the transaction flow or return format. This is a reasonable level of transparency for a tool with these consequences.

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 contains no filler. Each sentence contributes necessary information: what the tool does, when to use it, and what happens as a result. This is concise and well-structured.

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

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

For a single-parameter tool with no output schema and no annotations, the description covers the purpose, the trigger condition, and the consequences. It does not explain the full transaction process or return values, but given the simplicity of the tool, this is sufficiently complete for an agent to decide whether to call it.

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 covers 100% of the parameter (jobId) with its own description. The tool description adds context about 'overdue assigned job' but does not provide additional semantics beyond what the schema states. Thus, the description adds minimal value over 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 purpose: to prepare a transaction for expiring an overdue assigned job. It includes the specific verb 'expire' and the resource, but does not explicitly differentiate from sibling tools like cancel_job or finalize_job. The distinct action and context make the purpose clear enough.

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 an explicit usage condition: 'Anyone can call if the job duration has elapsed.' This clearly indicates when to use the tool. It does not mention when not to use it or alternatives, but the condition is specific and actionable, so the guidelines are adequate.

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 states the basic operation but does not disclose potential failure modes, whether authentication is required, or any side effects. It does not even mention that it is a read-only 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, focused sentence that immediately states the action and object. No filler 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?

The tool is a simple fetch with well-defined parameters, and the description covers the core operation and return value. However, it lacks any context about error handling, preconditions, or how it relates to other job-related tools, leaving the overall picture incomplete for an agent.

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% (both jobId and type are described in the schema). The description adds little beyond the schema, only paraphrasing the 'spec'/'completion' enum. That falls in line with the baseline 3 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 clearly states a specific verb ('Fetch and return') and resource ('IPFS metadata'), specifying the job spec or completion. This distinguishes it from siblings like get_job, which likely returns job details rather than IPFS metadata.

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 explicit guidance on when to use this tool vs alternatives such as get_job or list_jobs. The description gives no context about scenarios where IPFS metadata is needed or when other tools should be preferred.

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 who can call (anyone), when (after challenge period), and the financial effect ('Distributes payout to agent (80%), validators (8%), and protocol'). This is meaningful behavioral information, though it could mention irreversibility or transaction specifics.

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 supplemented with necessary timing and payout details. Every sentence adds value, with no filler 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?

For a one-parameter tool with no output schema, the description covers the purpose, timing, permissions, and distribution effect. It lacks details about the return value or transaction mechanics, but these are minor gaps for such a simple 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 provides 100% coverage for the single parameter jobId, including its own description. The tool description does not add new parameter-specific details beyond what the schema already states. Thus 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 clearly states the action: 'Prepare a transaction to finalize an approved job.' This is a specific verb+resource combination and distinguishes from siblings like approve_job or dispute_job. It also provides additional context on timing and payout distribution, 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 gives an explicit when-to-use condition: 'Anyone can call after the challenge period (1 day post-approval).' This implies not to use it before the challenge period. It does not explicitly name alternative tools, but the timing and permission context are clear enough for an agent to decide 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 provided, the description carries the full burden. It indicates a read-only, on-chain lookup, but does not disclose details such as return format, behavior for unknown addresses, error conditions, or any associated costs. The simplicity of the operation keeps this at an average level.

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 conveys the core purpose without redundancy. It is front-loaded with the verb and resource, making it easy to parse quickly.

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

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

Given the tool's low complexity (one parameter, no output schema, no annotations), the description covers the essential purpose but omits details about the return value or possible edge cases. It is adequate but not comprehensive; a brief note on what the score looks like 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?

The schema already provides a full description of the single 'address' parameter (Ethereum address with a regex pattern). The tool description adds no additional meaning beyond what the schema states, 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 clearly states the tool checks an on-chain reputation score for an agent address, using a specific verb and resource. It distinguishes from the sibling tool check_agent_identity by focusing on reputation rather than identity, though it doesn't explicitly call out the difference.

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 intended use case is implied: when you need an agent's on-chain reputation score. However, it provides no explicit guidance on when to use this tool versus check_agent_identity or other alternatives, nor does it mention prerequisites or exclusions.

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

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

With no annotations, the description carries the full burden. It discloses the content of the response (employer, agent, payout, status, etc.) which is useful. However, it does not mention error handling (e.g., 404 for unknown ID), authentication requirements, or confirm that this is a read-only operation. It provides adequate but not rich behavioral context.

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, front-loaded sentence with no filler. It states the verb, resource, and key return fields efficiently, earning every word.

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 lookup tool with one parameter and no output schema, the description adequately covers input (jobId) and output (the listed fields). It does not explain return formatting or error cases, but these are less critical for a read-only get operation. Overall, it is sufficiently complete for an agent to use 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 coverage is 100%: the only parameter, jobId, has a clear description ('The job ID to look up'). The tool description adds no additional meaning beyond restating 'by its ID', so it does not exceed the baseline for fully covered 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 uses a specific verb ('Get') and resource ('job') with clear scoping ('by its ID'), and enumerates the exact information returned (employer, agent, payout, status, etc.). This distinguishes it from sibling tools like list_jobs (which lists multiple jobs) and fetch_job_metadata (which likely fetches only metadata).

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 when to use the tool: when you have a specific job ID and need detailed information about that job. However, it does not explicitly name alternative tools (e.g., list_jobs for browsing) or state when not to use it, so it falls short of a full 5.

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

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

No annotations are provided, so the description carries the full burden. The verb 'get' implies a read-only operation, and the description lists the kind of data returned, but it does not explicitly disclose that there are no side effects, no authentication requirements, or other behavioral traits. For a simple getter, this is adequate but not rich.

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 sentence, front-loaded with the main action ('Get AGI Alpha protocol information'), followed by concise specifics. Every word adds value, and there is no unnecessary detail.

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 0-parameter getter with no output schema, the description explains the return content at a high level (contract addresses, parameters, token details, links). It lacks details about the exact structure or formatting, but it is sufficient for an agent to understand what this tool provides.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so there is no parameter description to add. Per the rubric, a baseline of 4 applies for tools with 0 params, and the description correctly does not invent any parameter documentation.

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

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

The description clearly states the tool's purpose: 'Get AGI Alpha protocol information' with specifics like contract addresses, parameters, token details, and links. This uses a specific verb and resource, and it is distinct from all sibling tools, which focus on jobs, reputation, or IPFS.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context: this is the tool for retrieving protocol-level information. It does not explicitly mention when not to use it or name alternatives, but none of the sibling tools compete with this functionality, so the usage context is unambiguous.

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 that the tool returns current status and specific fields, and the verb 'List' implies a read-only operation. However, it does not mention potential pagination, large result size, or any other behavioral caveats that might affect an agent's expectations.

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 clear, front-loaded sentences with no fluff. It efficiently states what the tool does and what it returns, earning every word.

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 list tool with no parameters and no output schema, the description is fairly complete. It enumerates the returned fields (job IDs, employers, agents, payouts, status, vote counts), which helps the agent understand the output. However, it could be more complete by noting any rate limits or whether the list is paginated, though this is not critical for the tool's simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the schema provides complete coverage by default. The description does not need to explain any parameters, and the baseline of 4 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 that the tool lists all jobs on the AGI Alpha job board with their current status, which is a specific verb+resource+scope. It distinguishes itself from sibling tools like get_job by explicitly stating 'all jobs' rather than a single 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 implies the tool is used when you need an overview of all jobs, but it does not explicitly mention when to avoid this tool or name alternatives like get_job for specific job details. There is clear context but no exclusions.

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

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

With no annotations, the description carries the full burden. It discloses cost (free, just gas), naming convention, and benefit (unlocks 60% payout). However, 'Prepare a free transaction' is ambiguous about whether it actually mints or only builds a transaction for signing, a key nuance not fully clarified.

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, front-loaded with the core action, then details. Every sentence adds useful information without redundancy or fluff.

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 one-parameter tool, the description covers purpose, cost, and alternative. However, it omits what the tool returns (e.g., a transaction object to sign) and behavior if the label is already registered, leaving a notable gap given the lack of 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?

Schema coverage is 100%, and the description's example mirrors the schema description, adding no new semantic meaning. The baseline of 3 applies because the schema already documents the label format.

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: preparing a free transaction to mint an Alpha Agent Identity NFT, registering a label on Ethereum. It also distinguishes from check_agent_identity by explicitly mentioning the check tool, making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly instructs users to check if already registered with check_agent_identity, offering a clear alternative. It also implies this tool is for the initial registration step, providing usage 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?

No annotations are provided, so the description must disclose behavioral traits. It mentions the role requirement ('as the assigned agent') but leaves critical details vague: does 'prepare' mean it builds a transaction without sending? What are the side effects? Does it require authentication? Is it reversible? These gaps are significant for safe and correct usage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with two sentences, front-loaded with the action verb. There is no fluff, but the phrase 'prepare a transaction' is slightly ambiguous given the tool's name. Still, it is appropriately sized and easy to scan.

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

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

Despite low complexity (2 simple params, no output schema), the description leaves major contextual gaps: what is the return value? Does it actually submit the transaction or just prepare it? What happens after calling it? Without annotations or an output schema, this ambiguity makes it hard for an agent to confidently use the tool or understand consequences.

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 both parameters, so the schema already fully explains jobId and completionURI. The description reiterates the IPFS requirement but adds no new semantics for jobId or the transaction preparation process, providing only marginal value 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 purpose: 'Prepare a transaction to submit job completion as the assigned agent.' The verb 'prepare' and resource 'job completion' are specific, and the mention of 'assigned agent' adds context. It partially distinguishes from siblings like finalize_job, though the distinction between 'prepare' and 'submit' could be sharper.

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 a clear prerequisite: 'Requires a completion URI pointing to IPFS metadata with deliverables.' This implies usage after deliverables are prepared. However, it does not explicitly mention when not to use this tool or reference alternative sibling tools like finalize_job or approve_job, leaving the decision to the agent without guidance.

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

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

With no annotations, the description carries the burden. It clearly states the tool returns an ipfs:// URI and requires a Pinata JWT. It also discloses the metadata schema requirements in detail. However, it does not mention potential costs, rate limits, or failure behavior (e.g., HTTP errors or invalid JWT), which would add further 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 long, but every sentence earns its place. The opening line is a punchy summary, followed by clear 'JOB SPEC FORMAT' and 'COMPLETION FORMAT' sections. The structure is logical and scannable, with each JSON example serving a concrete need. This is appropriate for a tool with complex input requirements.

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 (nested objects, two distinct use cases) and the absence of an output schema, the description is complete. It covers purpose, usage ordering, authentication, return value, and provides exhaustive format templates. An agent has everything needed to call the tool correctly for both create_job and request_job_completion workflows.

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?

Although the input schema already covers both parameters, the description goes far beyond by providing complete JSON examples for both job spec and completion metadata. The schema only gives brief hints; the description explains exact required fields, arrays, and formatting, adding substantial semantic value for the 'metadata' parameter.

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 first sentence clearly states the tool's function: 'Upload JSON metadata to IPFS via Pinata and return the ipfs:// URI.' This uses a specific verb, resource, and expected output, and immediately distinguishes it from sibling job-management 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?

Explicit usage guidance is provided: 'Use this BEFORE calling create_job (upload the job spec) or request_job_completion (upload the completion proof).' It also specifies the prerequisite (Pinata JWT) with a link to obtain one, which fully helps an agent decide when to invoke this tool.

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