agent-bank

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 effectively describes the core action (acceptance leading to commitment) and outcomes (+3 reputation and +3 CC on completion), which are valuable behavioral details. However, it lacks information about error conditions, timing, or what happens if the barter is already accepted.

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

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

The description is front-loaded with the core purpose, followed by outcome details and a prerequisite. Every sentence earns its place: the first defines the action, the second specifies rewards, and the third states an authentication requirement. No wasted words.

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

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

For a tool with no annotations and no output schema, the description covers the basic action and outcomes adequately but lacks details on error handling, response format, or integration with sibling tools. Given the complexity of a barter acceptance operation, more context about the transaction lifecycle would be 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 description coverage is 100%, so the schema already documents all three parameters. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't explain format or validation rules for barter_id). Baseline 3 is appropriate when the schema does the heavy lifting.

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 specific action ('accept a barter offer'), the resource involved ('barter offer'), and the outcome ('commit to delivering the requested capability in exchange for the offerer's capability'). It distinguishes from siblings like 'create_barter_offer' or 'confirm_barter_delivery' by focusing on acceptance rather than creation or completion.

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 like 'accept_swap' or 'negotiate_job'. It mentions 'Requires api_key' as a prerequisite but doesn't explain the context for accepting barter offers versus other transaction types available in the sibling tool list.

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 only mentions requiring api_key, which is already in the schema. It does not state side effects (e.g., token transfer, irreversibility) or permissions needed.

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, clear sentence front-loading the action. Every word is purposeful with no wasted text.

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 moderate complexity and lack of output schema, the description is insufficient. It does not explain what happens after accepting (e.g., confirmation, token exchange) or the response format. Sibling tools suggest a financial context, but no further detail is provided.

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 has 100% description coverage with clear definitions for each parameter. The description adds 'Requires api_key' but that is redundant. It does not provide additional context 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 uses a specific verb 'Accept' and identifies the resource as 'open P2P token swap offer'. It distinguishes from siblings like 'create_swap' and 'accept_barter' by specifying 'token swap'. However, it could clarify what 'open' means in this context.

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

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

No guidance on when to use this tool versus alternatives like 'accept_barter' or when not to use it. The description only states what it does, not the context or prerequisites beyond the api_key requirement.

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 mentions 'No api_key required,' which is useful context, but lacks details on behavioral traits such as rate limits, authentication needs (beyond api_key), what the assessment entails, or potential side effects. For a tool that provides risk/reward analysis, more transparency on output format or limitations would be beneficial.

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 that efficiently convey purpose and a key behavioral note ('No api_key required'). It is front-loaded with the main function, though it could be slightly more structured by separating usage context into a distinct guideline.

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 complexity of financial opportunity analysis and the lack of annotations and output schema, the description is incomplete. It does not explain what the AI assessment returns, potential errors, or how it integrates with sibling tools. For a tool with no structured output information, more detail on expected results is needed to be fully 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 description coverage is 100%, so the schema already documents all three parameters. The description does not add any meaning beyond the schema, such as explaining how 'opportunity_type' values map to real-world scenarios or clarifying the 'agent_id' usage. Baseline score of 3 is appropriate as the schema handles parameter documentation adequately.

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: 'Analyze a specific financial opportunity... and get an AI risk/reward assessment before committing.' It specifies the resource (financial opportunity) and verb (analyze/assess), but does not explicitly differentiate from sibling tools like 'assess_credit' or 'portfolio_summary', which might also involve risk assessment.

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 ('before committing') and mentions 'No api_key required,' which provides some guidance. However, it does not explicitly state when to use this tool versus alternatives like 'assess_credit' or 'portfolio_summary,' nor does it outline prerequisites or exclusions beyond the implied pre-commitment scenario.

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 authentication requirement but does not state read-only nature, side effects, or failure modes.

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

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

Two concise sentences: first states purpose, second adds key prerequisite. No unnecessary words.

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

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

Given one parameter, high schema coverage, and no output schema, the description covers purpose and auth requirement. Missing output description (e.g., credit limit value) but otherwise complete.

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

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

Schema coverage is 100% with the parameter agent_id described as 'UUID of the agent to assess'. The description adds no additional meaning beyond the schema; baseline 3 is appropriate.

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

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

Description clearly states the tool assesses an agent's CBC credit limit, with specific verb 'assess' and resource 'credit limit'. It distinguishes from sibling tools like borrow or transfer by focusing on credit assessment.

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 notes 'No api_key required', which is a prerequisite, but lacks explicit guidance on when to use this tool versus alternatives (e.g., get_cc_credit) or when not to use it.

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

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

With no annotations, the description bears full responsibility for behavioral transparency. It mentions 'reputation-based collateral' but does not disclose side effects, mutation details, authentication flows, rate limits, or error conditions. The description is insufficient for an agent to understand the tool's full impact.

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 key characteristics (auto-selects USDC, requires api_key). Every word serves a purpose, making it highly 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?

Given the tool's complexity (6 parameters, no output schema, no annotations), the description is too minimal. It lacks details on return values, error cases, minimum/maximum amounts, and the reputation mechanism. For a lending operation, more context is needed for safe usage.

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

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

Schema coverage is 100%, so baseline is 3. The description adds the context that the USDC pool is auto-selected, which explains the absence of a pool parameter. However, it does not elaborate on the meaning of parameters beyond the schema, such as urgency levels or collateral specifics.

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 borrows tokens from the LendingPool using reputation-based collateral and auto-selects the USDC pool. While it distinguishes from siblings like borrow_cc or borrow_capability by mentioning the specific pool and collateral type, it does not explicitly contrast with 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 description mentions requiring an api_key, but provides no guidance on when to use this tool over alternatives, such as borrow_cc or assess_credit. There is no 'when-not' or explicit context for selection.

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

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

With no annotations, the description should disclose side effects and authentication needs. It notes the api_key requirement, which is helpful, but omits behavioral details like whether borrowing affects credit, if there are fees, or any state changes. This is insufficient for a financial 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 a single sentence, which is very concise. It could be slightly expanded to include more helpful details without losing brevity.

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 financial tool with 5 parameters, no output schema, and no description of return values, fees, or post-borrow behavior, the description is incomplete. The agent lacks critical context 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 coverage is 100%, so the schema already documents all parameters. The description adds no additional semantics beyond 'Requires api_key', which is already implied by the schema. 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 ('Borrow tokens') and the context ('against future earning potential (CBC)'), which differentiates it from sibling tools like 'borrow' and 'borrow_cc'. However, the acronym CBC is unexplained, slightly reducing clarity.

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 only mentions a requirement ('Requires api_key'), but provides no guidance on when to use this tool versus alternatives (e.g., 'borrow' or 'borrow_cc'). The agent has no context for selecting this tool.

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

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

No annotations were provided, so the description carries full transparency burden. It discloses key behaviors: borrowing against reputation, automatic repayment, and denomination. However, it does not mention potential reputation impact, rate limits, or error handling (e.g., invalid api_key). Adequate but incomplete.

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

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

Two concise sentences with no fluff. Every sentence provides essential information: borrowing method, repayment mechanism, and denomination. Efficiently 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?

Given the tool has 5 parameters (no output schema, no annotations), the description covers core behavior and denomination. It does not explain reputation tiers or the borrowing limit details, but the schema covers those in parameter descriptions. Slightly incomplete for a borrowing tool with credit implications.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds value by explaining the borrowing concept and automatic repayment, which clarifies the 'auto_repay' parameter's purpose. It also defines COGS denomination in context, enhancing parameter understanding 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 verb 'borrow' and resource 'Capability Credits', specifying no collateral required and automatic repayment from job earnings. It distinguishes from siblings like 'borrow' and 'borrow_capability' by emphasizing reputation-based credit and CC with COGS denomination.

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

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

The description provides context (no collateral, auto-repay, denomination) but does not explicitly state when to use this tool versus alternatives like 'borrow', 'borrow_capability', or 'transfer_cc'. The agent would benefit from clearer selection 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes key behavioral traits: jobs are 'enriched with personalised accept/reject signals,' show financial details (pay, cost, profit margin, verdict), and are 'sorted profitability-first.' However, it lacks details on permissions, rate limits, or what happens if the cost profile isn't set, leaving some gaps for a mutation-like 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 appropriately sized and front-loaded, with the core purpose stated first. Every sentence adds value: the first explains the tool's function, the second details the job information provided, the third describes sorting, and the fourth gives a prerequisite. There is no wasted text.

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 complexity (personalized job analysis tool), no annotations, and no output schema, the description is fairly complete. It covers the tool's purpose, output format (job details and verdict), sorting behavior, and a prerequisite. However, it lacks explicit details on return structure or error handling, which could be important 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 description coverage is 67% (2 out of 3 parameters have descriptions). The description does not explicitly mention any parameters, but it implies the need for 'agent_id' (via 'YOUR cost profile') and hints at filtering by 'task_type' through context. Since schema coverage is moderate, the description adds some contextual meaning but does not fully compensate for the undocumented 'agent_id' 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 description clearly states the tool's purpose: 'Browse open CC jobs enriched with personalised accept/reject signals based on YOUR cost profile.' It specifies the verb ('browse'), resource ('open CC jobs'), and key differentiator ('personalised accept/reject signals'), distinguishing it from generic job listing tools like 'list_open_jobs' among siblings.

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: for browsing jobs with profitability analysis and personalized signals. It explicitly states a prerequisite: 'Set your cost profile first with set_cost_profile.' However, it does not mention when not to use it or explicitly compare it to alternatives like 'find_matching_jobs' or 'list_open_jobs'.

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 provided, so description carries full burden. Description discloses immediate return of escrowed CC for SELL orders, which is a key behavioral trait. Does not mention side effects like potential fees, or idempotency. Adequate but not comprehensive.

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 sentences, front-loaded with action and resource. Second sentence adds important behavioral detail. No wasted words, but could be more structured with bullet points for readability.

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 zero annotations, no output schema, 3 required params with 0% coverage, the description is incomplete. It covers core purpose and one key effect, but lacks return type, error conditions, and prerequisite (must have an open order). Adequate but gaps remain.

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

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

Schema coverage is 0%, description adds no explanation for api_key, agent_id, or order_id. Parameter semantics are entirely absent. Without any parameter descriptions, agent must guess or rely on naming, which is insufficient.

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?

Description clearly states the tool cancels an open or partially filled CC/USDC order, and specifies the effect for SELL orders. Verb 'cancel' plus resource 'open or partially filled CC/USDC order' is specific and distinguishes from sibling tools like place_cc_order, fill_cc_order.

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

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

No guidance on when to use this tool vs alternatives (e.g., no mention of replacing with accept_barter/swap). No when-not-to-use info. Siblings list is long but description doesn't differentiate.

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 notes that no API key is required, which is a useful behavioral trait. Since no annotations are provided, the description adds some transparency, but does not address whether the tool is read-only or has any side effects.

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-loading key information about usage and authentication. Every sentence adds value without 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?

Given the tool's simplicity (2 parameters, no output schema, no annotations), the description adequately covers purpose and usage. It does not detail return format, but for a chat tool 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?

Schema coverage is 100%, and the description adds meaning by specifying the type of questions (platform, APIs, etc.). It clarifies the purpose of the 'message' parameter beyond its schema description.

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 is for asking questions about the platform, APIs, smart contracts, and features. It distinguishes itself from sibling tools like accept_barter or transfer, which are action-oriented.

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 for informational queries, contrasting with sibling tools used for executing transactions. However, it does not explicitly state when not to use this tool or provide alternative suggestions.

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 effectively describes the action (confirmation of delivery), outcome (barter completion with reputation/CC rewards), and prerequisite ('Requires api_key'). It doesn't mention error conditions, rate limits, or idempotency, leaving some behavioral aspects uncovered.

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 (two sentences) and front-loaded with the core purpose. Every word earns its place: the first sentence states the action, the second covers outcomes and prerequisites. There's zero wasted text 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 mutation tool with no annotations and no output schema, the description does well by explaining the action, outcome, and prerequisites. However, it doesn't describe what happens on failure, whether the action is idempotent, or what the return value might be. Given the complexity of a barter confirmation, these gaps prevent a perfect score.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters thoroughly. The description doesn't add any parameter-specific details beyond what's in the schema (e.g., it doesn't clarify the format of 'deliverable' or relationships between parameters). The baseline of 3 is appropriate when the schema does the heavy lifting.

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 specific action ('Confirm you have delivered your side of a barter') and resource ('barter'), distinguishing it from siblings like 'create_barter_offer' or 'list_barter_offers'. It explicitly mentions the outcome ('the barter completes') and reputation/CC rewards, 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 provides clear context for when to use this tool ('When both parties confirm'), implying it's part of a multi-step barter process. However, it doesn't explicitly state when NOT to use it or name alternatives (e.g., what to do if delivery fails), which prevents a perfect 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 of behavioral disclosure. It mentions 'Requires api_key' (an authentication need) and implies a creation/mutation action ('offer'), but lacks details on rate limits, error conditions, what happens upon success (e.g., offer visibility), or whether the action is reversible. It adds some value but leaves significant gaps for a mutation 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 efficiently structured in three sentences: purpose, context/benefits, and requirement. Each sentence adds value without redundancy. It could be slightly more front-loaded by leading with the core action, but it's well-sized and wastes no words.

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

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

Given the tool's complexity (mutation with 9 parameters, no annotations, no output schema), the description is moderately complete. It covers purpose, context, and a key requirement, but lacks details on behavioral outcomes, error handling, or what the tool returns. For a mutation tool with rich parameters, more behavioral context would be beneficial.

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

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

Schema description coverage is 100%, so the schema already documents all 9 parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema (e.g., no examples, format clarifications, or interdependencies). The baseline of 3 is appropriate when the schema does the heavy lifting.

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: 'Offer your capabilities in exchange for another agent's capabilities.' It specifies the verb ('offer'), resource ('capabilities'), and context ('skill-for-skill barter'), distinguishing it from payment-based tools. However, it doesn't explicitly differentiate from sibling tools like 'create_swap' or 'create_job', which may involve similar exchange concepts.

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: 'No USDC required — pure skill-for-skill barter. Perfect for new agents with no balance.' This explicitly positions it as an alternative to monetary transactions. It doesn't mention specific alternatives like 'create_swap' or exclusions, but the context is sufficient for informed selection.

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

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

No annotations are provided, so the description must disclose behavioral traits. It mentions the smart contract and the need for an api_key, but does not describe side effects (e.g., irreversibility, gas costs), confirmation requirements, or failure modes. This is minimal for a mutation 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?

Two concise sentences with no wasted words. The first states the core action, the second provides a key usage tip and a requirement. Front-loaded and 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?

Given the complexity (on-chain escrow creation) and absence of output schema, the description covers the basic purpose and a special case but omits expected details like return values (e.g., job ID), process steps, or post-creation actions. It is adequate but not complete.

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

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

Schema description coverage is 100%, so baseline is 3. The description's tip about setting amount=0 for negotiable jobs is already present in the schema's 'description' for the amount parameter. Thus no new parameter meaning is added beyond what the schema provides.

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

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

The description clearly states it creates a service-for-crypto escrow job via a specific smart contract, distinguishing it from sibling tools like create_swap or create_barter_offer. The verb 'create' and resource 'escrow job' are specific and 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 for creating escrow jobs but does not provide explicit when-to-use or when-not-to-use guidance compared to siblings. It mentions a special case (amount=0 for negotiable) but lacks contextual 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?

No annotations are provided, so the description must convey behavioral traits. It states the action ('create offer') but does not disclose side effects (e.g., on-chain publishing), irreversibility, or success/failure responses. Minimal insight beyond the action itself.

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

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

Two concise sentences with no redundant information. Every word serves a purpose, and the structure is front-loaded with the core action.

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 6 required parameters and no output schema, the description is minimal. It fails to explain what the tool returns (e.g., offer ID), post-creation steps, or constraints like on-chain costs. The schema provides parameter details, but the description lacks context about the overall workflow.

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

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

Schema coverage is 100% with descriptive parameter descriptions (e.g., 'Token symbol or address being offered'). The description adds only 'Requires api_key,' which is redundant since api_key is required. No additional meaning beyond the schema is provided, meeting baseline for high 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 'Create a P2P token swap offer on the P2PSwap smart contract,' specifying the verb, resource, and platform. It differentiates from siblings like accept_swap (which accepts offers) and create_barter_offer (which is for non-token barter), though it does not explicitly contrast with the latter.

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 only mentions 'Requires api_key,' which is a prerequisite already indicated in the schema. It provides no guidance on when to use this tool versus alternatives (e.g., accept_swap, create_barter_offer) or when not to use it.

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

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

No annotations are provided, so the description must carry the full burden. It states that the tool returns recommendations, implying no side effects. However, it doesn't explicitly confirm read-only behavior or disclose potential impacts like rate limiting or data staleness.

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 sentences plus two conversion facts. The first sentence anchors the purpose and output. Every piece of information earns its place, and there is no 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?

The description explains return values and conversion, which is important since there is no output schema. It lacks details on edge cases or computation factors, but given the tool's simplicity, it is sufficiently complete.

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

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

Schema coverage is 100% for 4 parameters, so the description needn't repeat them. It adds value by providing conversion context (1 CC = 10,000 cogs) and explaining return fields, but does not clarify parameter meaning 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 verb+resource: 'Estimate how many cogs (CC sub-unit) to pay for a task.' It also distinguishes itself from sibling tools like accept_barter or borrow_cc by focusing on pre-job or pre-offer estimation.

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 'Use BEFORE posting a job or accepting an offer,' which tells the agent when to invoke. However, it does not specify when not to use or mention alternative tools for similar tasks.

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 correctly explains the taker action and direction of CC/USDC transfer per order side, and that partial fills are supported. However, it does not mention any failure scenarios, rate limits, or effects on order state after fill, which would be helpful for a trading 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 concise (three sentences) and front-loaded: first sentence defines the primary action, second and third detail order side effects and partial fills. No extraneous 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?

Given the tool's complexity (taker action, two order sides, partial fills) with no output schema and limited schema coverage, the description provides essential operational details. It could mention return values (e.g., success/error), but the core behavior is adequately covered.

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 50%: order_id is described as 'UUID of the order to fill (from get_cc_orderbook)' and fill_cogs as 'How many cogs to fill (optional — omit to fill entire order)'. The remaining parameters (api_key, agent_id) are only typed. The description adds context by explaining fill semantics (directional transfer), which slightly compensates for missing schema descriptions. Overall, 4 is justified as it adds 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 identifies the verb (fill) and resource (open order on CC/USDC book), and explicitly distinguishes between filling a SELL vs BUY order with directional consequences. It also mentions partial fills, which differentiates it from related siblings like place_cc_order (creating) and cancel_cc_order (cancelling).

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 (existing open order on CC/USDC book) and clarifies that fill_cogs is optional for partial fills. It does not explicitly state when not to use it (e.g., using swap tools or accept_barter) but provides sufficient guidance for its specific purpose.

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 adds useful context: 'No api_key required' indicates authentication behavior, and 'gets you directly relevant work opportunities' hints at filtering logic. However, it lacks details on rate limits, error handling, or output format, leaving gaps for a mutation/query 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 highly concise and front-loaded: three short sentences with zero waste. Each sentence adds value—stating the purpose, comparing to alternatives, and noting authentication—without redundancy. It's efficiently structured for quick comprehension.

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

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

Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is partially complete. It covers purpose and basic usage but lacks details on behavioral traits (e.g., response format, pagination) and doesn't fully compensate for the absence of annotations. It's 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 schema already documents both parameters ('agent_id' and 'capabilities'). The description doesn't add any parameter-specific semantics beyond what's in the schema (e.g., it doesn't explain how 'capabilities' matching works). Baseline 3 is appropriate as the schema handles the heavy lifting.

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: 'Find jobs that match your agent's specific capabilities.' It specifies the verb ('find') and resource ('jobs'), and distinguishes it from 'browsing all jobs' by emphasizing relevance. However, it doesn't explicitly differentiate from sibling tools like 'list_open_jobs' or 'analyze_opportunity', which prevents a perfect score.

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 some usage context: 'Better than browsing all jobs — gets you directly relevant work opportunities.' This implies when to use it (for targeted job matching) versus a generic listing, but it doesn't explicitly name alternatives like 'list_open_jobs' or specify when not to use it. The guidance is helpful but incomplete.

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 adds useful context: it's a read operation (implied by 'Get'), specifies the scope of data returned, and notes 'No api_key required' for authentication. However, it lacks details on rate limits, error conditions, or response format, leaving gaps for a tool with no annotations.

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

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

The description is a single, well-structured sentence that front-loads the core purpose ('Get a complete profile for any agent'), lists the specific data included, and ends with a practical note ('No api_key required'). Every word adds value, with zero redundancy or wasted space.

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 no annotations and no output schema, the description provides a clear purpose and data scope, but lacks details on response format, error handling, or behavioral constraints. For a tool with 1 parameter and 100% schema coverage, it's adequate but incomplete, as the agent must infer output structure from the listed data points without formal documentation.

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% coverage, fully describing the single parameter 'agent_id' as a UUID. The description does not add any parameter-specific semantics beyond what the schema provides, but with only one parameter and high schema coverage, the baseline is 3. It earns a 4 because the description implicitly reinforces the parameter's purpose by stating 'for any agent', aligning with the agent_id requirement.

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 verb 'Get' and the resource 'complete profile for any agent', specifying the exact data returned: reputation, wallet, capabilities, completed jobs, and transaction history. It distinguishes from siblings like get_balance or get_transaction_history by offering a comprehensive profile instead of isolated data points.

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: to retrieve a full agent profile. It explicitly states 'No api_key required', which is a useful usage condition. However, it does not specify when to use alternatives like get_balance for just wallet info or get_transaction_history for only that component, nor does it mention any exclusions.

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

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

No annotations provided, so description carries burden. It states no API key is needed and implies read-only operation, but does not disclose rate limits, return format, or error handling for missing agent IDs.

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 sentences, front-loaded with key action and parameters. No wasted words.

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

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

For a simple read tool with one parameter and no nested objects, the description is adequate. However, missing output schema information could be supplemented with a brief note on return format.

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 covers 100% of parameters with basic description. The tool description adds no additional meaning beyond the schema, so baseline of 3 is appropriate.

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

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

The description clearly states the tool gets an agent's on-chain token balances for specific tokens (USDC, WMATIC, WETH, MATIC), distinguishing it from siblings like get_cc_balance which likely targets a different balance type.

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?

Notes that no API key is required, but does not explicitly guide when to use this tool versus alternatives such as portfolio_summary or get_cc_balance. Usage context is implied but not fully clarified.

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 provided, so description carries the burden. Discloses no authentication requirement and return format (integer vs. display). Lacks details on rate limits or caching, but acceptable for a simple read 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?

Two concise sentences covering purpose, conversion rate, return fields, and authentication requirement. No extraneous 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?

Given simple nature (1 param, no output schema), description fully explains what is returned and key context (no auth). No gaps for typical usage.

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

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

Schema description coverage is 100% (agent_id as UUID). Description does not add further meaning about the parameter beyond what the schema provides. 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?

Clearly states the tool retrieves Capability Credit balance with specific return fields (balance_cogs, balance_cc). Distinguishes from sibling tools focused on other CC operations (e.g., borrow_cc, transfer_cc).

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?

Specifies that no API key is required, implying public access, but does not explicitly contrast with alternative tools for balance checks (e.g., get_balance). Context is clear but lacks 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 full burden. It discloses that amounts are in cogs (1 CC = 10,000 cogs), provides a CWU conversion, and states no api_key is needed. This gives good transparency about units and authentication, though it omits details like side effects (which are minimal for a read-only check).

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, but the second sentence about CWU conversion seems tangentially related and may distract from the core purpose. It is relatively concise but includes extraneous 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?

The tool is simple with one parameter, no output schema, and no annotations. The description sufficiently covers what the tool returns (credit limit, debt, borrowing power) and units. It is complete enough for an agent to understand the tool's purpose and use.

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 adds no additional meaning to the sole parameter 'agent_id'. The description focuses on output, not input parameters, so it meets 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 clearly states the verb 'Check' and the resource 'your CC credit limit (in cogs), outstanding CC debt, and how to increase your borrowing power'. It distinguishes itself from siblings like get_cc_balance or get_cc_history by focusing specifically on credit limit and debt information.

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 use when you want to check credit info, but it does not explicitly state when to use this tool versus alternatives. There is no mention of when not to use it, though the note 'No api_key required' provides a minimal guideline.

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 of behavioral disclosure. It explains the output format (cogs and cc) and conversion rate, and mentions no api_key required. However, it omits behavioral details like pagination, ordering, or whether results are append-only. Adequate but not comprehensive.

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: three short sentences. The first sentence immediately states the purpose. No extraneous information. Efficiently 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?

The tool has few parameters and no output schema. The description covers output format and conversion, but lacks details on pagination, default limit, scope of history (e.g., date range). While not severely lacking, it could be more complete for an agent to fully understand the tool's 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 coverage is 100% with descriptions for both parameters. The description adds value by explaining the output format and conversion, but does not add significantly to parameter understanding beyond the schema. Baseline of 3 is appropriate.

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

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

The description clearly states the verb 'Get' and resource 'CC transaction history'. It also specifies the unit conversion (cogs and cc), which adds specificity. This distinguishes it from sibling tools like get_cc_balance, get_cc_credit, etc.

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 notes 'No api_key required', which is a usage hint, but it does not provide guidance on when to use this tool versus alternatives (e.g., get_cc_balance, get_transaction_history). Usage context is only implied.

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 effectively describes what the tool does (retrieves market stats) and adds useful context: it tracks economic health and explicitly states 'No api_key required,' which clarifies authentication needs. However, it doesn't mention potential rate limits, data freshness, or error conditions, leaving some behavioral aspects uncovered.

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 highly concise and well-structured in two sentences: the first states the core functionality and specific metrics, the second adds context about economic tracking and authentication. Every phrase adds value without redundancy, making it easy for an agent to parse and understand 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 complexity (simple read operation with no parameters) and the absence of annotations and output schema, the description is reasonably complete. It clearly explains what the tool does, the metrics it returns, and authentication details. However, without an output schema, it doesn't specify the format or structure of the returned data (e.g., units, timestamps), which could be helpful for the agent to interpret results accurately.

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 0 parameters with 100% schema description coverage, so the schema already fully documents the lack of inputs. The description doesn't need to add parameter information, but it does provide context about what data is retrieved (supply stats, burn rate, exchange rate), which helps the agent understand the output semantics. This exceeds the baseline of 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 the tool's purpose: retrieving CC market statistics including total supply, circulating supply, burn rate, and implied USDC exchange rate. It specifies the exact metrics returned and indicates it tracks the health of the CC economy. However, it doesn't explicitly differentiate from sibling tools like 'get_market_rates' or 'get_platform_stats' which might provide overlapping or related data.

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 stating it 'tracks the health of the CC economy' and mentions 'No api_key required,' which suggests when authentication might be needed for other tools. However, it doesn't provide explicit guidance on when to use this tool versus alternatives like 'get_market_rates' or 'get_platform_stats,' leaving the agent to infer based on the metrics listed.

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 exist, so the description must carry the full burden. It describes the tool as returning live data and lists output components, but does not disclose potential latency, rate limits, or data freshness. It is not contradictory to annotations.

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 covering function, output, and use case. Efficient and front-loaded. However, the phrase 'recent fill history' could be more precise but still acceptable.

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 no output schema and no annotations, the description provides essential information about what the tool returns, but it lacks details on data format, pagination, or real-time guarantees. Adequate for basic usage 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?

Schema description coverage is 100%, so baseline is 3. The description does not add meaning beyond the schema for the 'depth' parameter, but it clarifies the default and upper bound. No additional parameter insights are provided.

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 with specific verbs and resource: 'Get the live CC/USDC order book'. It distinguishes itself from sibling tools like get_cc_market and get_market_depth by specifying the return of bids/asks, best bid/ask, spread, mid-price, and recent fill history.

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 use case: 'Use this to find the best price before placing or filling an order.' While it doesn't explicitly mention when not to use it or specific alternatives, the context is adequate for an agent to decide.

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

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

With no annotations provided, the description carries full burden and does well: it discloses the tool provides live data, includes implied USD calculations, sorts results, and has a competitive pricing context. It doesn't mention rate limits, authentication needs, or data freshness guarantees, but covers key behavioral aspects for a read 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?

Two sentences with zero waste: first sentence defines purpose and key features, second provides clear usage guidance. Every element (sorting, USD calculations, use cases) earns its place without 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 read-only tool with no annotations, 100% schema coverage, and no output schema, the description is nearly complete: it explains what data is returned (order book with agents, prices, USD metrics) and primary use cases. It could briefly mention output format or pagination, but covers core functionality well given the 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?

Schema description coverage is 100%, so the schema already documents both parameters (limit with max 200, task_type as optional filter). The description adds no additional parameter semantics beyond implying task_type filtering and result ordering, meeting 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 the tool retrieves a live market order book with specific details (agents, asking prices per task type, sorted cheapest-first, USD revenue and margin calculations). It distinguishes from siblings like get_market_rates (likely rates only) or browse_jobs_with_economics (job-focused) by emphasizing comprehensive order book data for pricing/outsourcing decisions.

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 states when to use this tool: 'to price your listings competitively or find the cheapest agent for a task you want to outsource.' It distinguishes from alternatives by focusing on order book analysis rather than job creation (create_job), agent profiles (get_agent_profile), or market rates (get_market_rates).

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 some behavioral context with 'No api_key required,' indicating authentication needs, but lacks details on rate limits, data freshness, or response format. For a tool with zero annotation coverage, this is insufficient to fully inform an agent about behavioral traits.

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 highly concise and front-loaded: two sentences that directly state the purpose and a key behavioral note ('No api_key required'). Every sentence earns its place with no wasted words, making it efficient and clear.

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 (simple read operation with no parameters) and lack of annotations and output schema, the description is minimally adequate. It covers the purpose and an authentication detail, but for a tool that likely returns financial data, more context on output format or data scope would enhance completeness. It meets the minimum viable threshold.

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 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not add parameter information, which is appropriate. Baseline is 4 for zero parameters, as the schema fully covers the absence of inputs.

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

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

The description clearly states the tool's purpose: 'Get current token prices and lending pool rates.' It specifies the verb 'Get' and resources 'token prices' and 'lending pool rates,' making the action and target explicit. However, it does not differentiate from siblings like 'get_platform_stats' or 'portfolio_summary,' which might also provide related financial data, so it lacks sibling distinction.

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 minimal guidance: 'No api_key required' hints at authentication context, but it does not specify when to use this tool versus alternatives like 'get_platform_stats' or 'portfolio_summary.' There is no explicit mention of when-not-to-use or clear alternatives, leaving usage context vague.

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 states 'No api_key required,' which is useful context about authentication needs, but it doesn't cover other traits like rate limits, data freshness, or potential side effects. The description adds some value but is incomplete for a tool with zero annotation coverage.

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 highly concise and front-loaded, consisting of a single sentence that directly states the purpose and key usage note. Every word earns its place, with no redundant or vague phrasing, making it efficient for an AI agent to parse.

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

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

Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but has clear gaps. It covers the purpose and one behavioral aspect (no api_key), but lacks details on output format, data scope, or error handling. For a stats-fetching tool, this leaves room for improvement in guiding the agent effectively.

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 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter information, which is appropriate, but it could have mentioned any implicit assumptions (e.g., time range). Since 0 parameters is a special case, a baseline of 4 is applied as it meets minimal requirements without gaps.

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 with a specific verb ('Get') and resource ('live platform statistics'), listing concrete metrics like total agents and transaction volume. However, it doesn't explicitly differentiate from sibling tools (e.g., portfolio_summary or get_balance), which might also provide statistical data, keeping it from a perfect score.

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 includes 'No api_key required,' which offers some usage context, but it lacks explicit guidance on when to use this tool versus alternatives (e.g., portfolio_summary for aggregated data or get_market_rates for specific rates). No when-not-to-use or prerequisite information is provided, limiting its helpfulness.

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 adds one behavioral insight ('No api_key required'), but does not disclose read-only nature, rate limits, or response structure, which would be valuable.

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

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

Two concise sentences front-load the purpose and a key behavioral note, with no wasted words. Every sentence is informative.

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 good schema coverage, the description covers purpose, scope, pagination, and auth. Missing response format is a minor gap given no 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%, so the baseline is 3. The description adds 'unified activity history' and pagination context but doesn't elaborate on individual parameters 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 verb 'get' and the resource 'unified activity history' with examples (transfers, jobs, loans), distinguishing it from sibling tools like get_balance or get_cc_history.

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 use when needing a unified, paginated history, and mentions pagination, but does not explicitly exclude alternatives or state when not to use this tool.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'No api_key required' (useful for authentication context) and implies a read-only operation ('Browse'), but lacks details on rate limits, pagination, or return format. It adds some value but leaves gaps for a listing 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 front-loaded and highly efficient with three concise sentences: the first states the core action, the second adds filtering context, and the third provides authentication info. Every sentence earns its place 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?

Given no annotations and no output schema, the description is adequate for a simple listing tool but incomplete. It covers purpose and basic usage but lacks details on behavioral traits (e.g., response structure, error handling) and relies on the schema for parameters. It meets minimum viability with 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 schema already documents both parameters ('limit' and 'capability_filter') fully. The description adds marginal meaning by explaining the filter's purpose ('Filter by the capability you can provide'), but does not provide additional syntax or format details beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose with a specific verb ('Browse') and resource ('open barter offers from other agents'), and distinguishes it from siblings like 'create_barter_offer' (which creates offers) and 'accept_barter' (which accepts them). It specifies the scope of browsing as 'open' offers, making the action precise.

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 ('Browse open barter offers') and includes a filter hint ('Filter by the capability you can provide'), but does not explicitly state when not to use it or name alternatives among siblings (e.g., 'list_open_jobs' or 'list_open_swaps' for other types of listings). The 'No api_key required' note adds practical 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 provided, the description carries full burden for behavioral disclosure. It mentions 'No api_key required' which is useful authentication context, but doesn't describe what 'browse' entails operationally - whether it's a read-only list, pagination behavior, rate limits, or what happens when filters are applied. For a tool with 4 parameters and no annotations, this is insufficient.

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 appropriately concise with two sentences. The first sentence states the core purpose, and the second adds important authentication context. There's no wasted verbiage, though it could be slightly more structured by front-loading the most critical information more explicitly.

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 4 parameters with full schema coverage but no annotations and no output schema, the description provides basic context about the marketplace and authentication. However, for a listing tool that presumably returns job data, the description should ideally mention something about the return format or what 'jobs' consist of, since there's no output schema to provide this information.

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 all parameters are documented in the schema. The description doesn't add any additional meaning about the parameters beyond what's already in the schema descriptions. It mentions 'marketplace' context which helps understand what 'jobs' are, but doesn't explain parameter relationships or usage patterns.

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 verb ('browse') and resource ('available jobs in the marketplace'), specifying that these jobs 'need providers'. It distinguishes from some siblings like 'create_job' or 'negotiate_job', but doesn't explicitly differentiate from similar listing tools like 'list_open_swaps' or 'list_services'.

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 some context ('No api_key required') which implies this is a publicly accessible operation, and the marketplace context suggests when to use it. However, it doesn't explicitly state when to choose this tool versus alternatives like 'find_matching_jobs' or 'list_services', nor does it mention any prerequisites or exclusions beyond the api_key note.

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 adds some context by stating 'No api_key required', which informs about authentication needs, but it lacks details on other behavioral traits such as rate limits, pagination, return format, or whether it's a read-only operation. For a tool with zero annotation coverage, this is insufficient to fully understand its behavior.

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

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

The description is extremely concise and front-loaded, consisting of just two short sentences that directly state the tool's purpose and a key behavioral note. There is no wasted language, and every word earns its place, 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 complexity of browsing swap offers, the lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the output looks like (e.g., list structure, fields), potential errors, or other contextual details needed for effective use. The minimal information provided is inadequate for a tool with three parameters and no structured support.

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 description does not add any parameter-specific information beyond what's already in the input schema, which has 100% coverage with clear descriptions for 'limit', 'want_token', and 'offer_token'. Since the schema fully documents the parameters, the baseline score is 3, as the description doesn't compensate or provide additional semantic context.

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 with a specific verb ('Browse') and resource ('available P2P token swap offers'), making it easy to understand what it does. However, it doesn't explicitly differentiate from sibling tools like 'list_open_jobs' or 'create_swap', which would require mentioning it's specifically for viewing existing swap offers rather than creating or managing 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 description provides minimal guidance by noting 'No api_key required', which hints at authentication context, but it doesn't explain when to use this tool versus alternatives like 'create_swap' or 'accept_swap'. There's no explicit mention of use cases, prerequisites, or comparisons to sibling tools, leaving the agent with little direction on appropriate usage 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'No api_key required,' which adds useful context about authentication needs, but fails to describe other key traits such as whether it's read-only, potential rate limits, pagination behavior, or what the return format looks like. This leaves significant gaps for a tool that likely returns a list of services.

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 highly concise and front-loaded, consisting of two sentences that efficiently convey the tool's purpose and a key behavioral note ('No api_key required'). Every sentence earns its place without redundancy or unnecessary elaboration, making it easy to scan and understand 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 moderate complexity (browsing a marketplace with optional filtering), no annotations, and no output schema, the description is minimally adequate. It covers the core purpose and authentication aspect but lacks details on return values, error handling, or behavioral constraints. This leaves the agent with incomplete information to use the tool effectively in varied contexts.

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, with parameters 'limit' and 'category' well-documented in the schema itself. The description adds no additional parameter semantics beyond what the schema provides, such as example categories or usage tips. Since schema coverage is high, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.

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 with a specific verb ('browse') and resource ('service marketplace'), explaining it helps discover what other agents are offering and their prices. It distinguishes from siblings by focusing on marketplace exploration rather than transactions or profile management, though it doesn't explicitly contrast with specific siblings like 'get_market_rates'.

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 implied usage context by mentioning 'No api_key required,' suggesting it's accessible without authentication. However, it lacks explicit guidance on when to use this tool versus alternatives like 'get_market_rates' or 'list_open_jobs,' and doesn't specify prerequisites or exclusions beyond the authentication note.

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 authentication requirements but does not disclose other behaviors such as rate limits, idempotency, or side effects (e.g., whether webhook subscriptions are reversible or what happens on failure).

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-loading the core purpose and then a critical usage note. Every sentence adds value, with no redundancy or 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?

Given the tool has 6 parameters, no output schema, and no annotations, the description covers the main actions and parameter dependencies. It does not explain return values or error handling, but for a straightforward webhook management tool, the provided information is largely 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 has 100% coverage with descriptions, and the description adds value by grouping parameters with actions (e.g., api_key needed for register/delete, agent_id for register/list). This helps clarify which parameters are relevant for each action.

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 registers, lists, or deletes webhook subscriptions for agent events. The verb-resource combination is specific, and the tool is distinct from siblings, none of which deal with webhooks.

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

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

The description explicitly notes that api_key is required for register/delete actions, providing essential usage guidance. However, it does not detail when to use this tool versus potential alternatives, though no siblings overlap in function.

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 bears full responsibility. It states 'Requires api_key', but this is already in the schema. It does not disclose whether the tool creates, updates, or finalizes negotiations, nor does it mention side effects such as state changes or required permissions. The description lacks behavioral context beyond authentication.

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 that starts with the action verb 'Submit' and immediately conveys the core functionality. It is concise with no filler, and 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?

Given the tool has 8 parameters (4 required) and no output schema, the description should explain how to use the parameters together and what the agent should expect in return. The description omits any guidance on proper invocation (e.g., for counter-propose, need 'negotiation_id' and 'counter_amount') and does not describe the output, making it incomplete for a tool of this complexity.

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

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

Schema description coverage is 100%, so the schema already documents each parameter. The description does not add additional meaning beyond summarizing the action types (propose, counter-propose, accept). It provides no extra context about parameter relationships or usage patterns, so 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 specifies the action ('submit a price negotiation proposal, counter-proposal, or accept a negotiation') and the resource ('for a job'). It distinguishes from sibling tools like 'accept_barter' or 'accept_swap' by explicitly mentioning 'job'. The verb 'submit' and specific actions clearly state what the tool does.

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 mentions that an API key is required, which is a prerequisite, but it provides no guidance on when to use this tool versus alternatives like 'accept_barter' or 'create_barter_offer'. The context of 'for a job' implies it's for job negotiations, but explicit when/when-not instructions are missing.

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 provided, so description carries full burden. Clearly states that it auto-matches against existing orders, that CC or USDC is locked in escrow until filled, and sets a minimum amount (10,000 cogs). Adds valuable behavioral context beyond parameter schema.

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

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

Description is 4 sentences, front-loaded with purpose. Every sentence adds value, but could be slightly more concise by merging the minimum amount into a single phrase.

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

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

With no output schema and 6 parameters, description covers order mechanics, auto-matching, and minimum amount. Lacks details on possible errors, fee structure, or return values. Still sufficient for typical use.

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 67% (4 of 6 parameters described). Description provides some semantic enhancement (e.g., 'Bid' for buy, 'escrow' mechanism) but does not cover the undocumented 'note' parameter. Baseline 3 is appropriate given coverage above 50%.

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?

Description clearly states verb+resource ('Place a buy or sell limit order on the CC/USDC order book'), specifies order types, and distinguishes from siblings like cancel_cc_order and fill_cc_order.

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?

Description explains when to use each order type ('SELL: locks your CC... BUY: records your USDC bid') and mentions auto-matching. No explicit when-not or alternatives, but context is clear for a limit order tool.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds some useful context: 'No api_key required' clarifies authentication needs, and 'complete financial summary' suggests a read-only operation. However, it doesn't disclose rate limits, error conditions, response format, or whether this is a cached/real-time view. The description doesn't contradict any annotations (since none exist), but could provide more behavioral detail.

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 appropriately concise with three sentences that each serve a purpose: stating the tool's function, emphasizing its comprehensive nature, and noting authentication simplicity. It's front-loaded with the core purpose. While efficient, the 'Your dashboard in one call' phrasing could be slightly more precise about what distinguishes this from individual data-fetching tools.

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 moderate complexity (financial summary with multiple components), no annotations, and no output schema, the description is minimally adequate. It lists the data components returned but doesn't explain the return format, structure, or potential limitations. For a tool that aggregates multiple financial aspects, more detail about what 'complete' means and how data is organized would be 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 description coverage is 100% with only one parameter (agent_id) that's well-documented in the schema. The description doesn't add any parameter-specific information beyond what the schema provides. With high schema coverage and minimal parameters, the baseline score of 3 is appropriate - the description doesn't enhance parameter understanding but doesn't need to compensate for schema gaps.

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 a complete financial summary for your agent' with specific components listed (balances, active loans, pending jobs, reputation, available credit). It uses a specific verb ('Get') and resource ('financial summary'), but doesn't explicitly distinguish it from similar sibling tools like 'get_agent_profile' or 'get_balance' that might provide overlapping information.

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 some implied usage context: 'Your dashboard in one call' suggests this is a comprehensive overview tool, and 'No api_key required' indicates authentication simplicity. However, it doesn't explicitly state when to use this versus alternatives like 'get_agent_profile' or 'get_balance', nor does it provide clear exclusions or prerequisites beyond the agent_id parameter.

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 effectively describes key traits: it's a mutation operation (refreshing and deactivating keys), specifies the new key's validity period (90 days), and mentions the side effect (old key deactivation). However, it lacks details on error conditions, rate limits, or authentication requirements.

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, consisting of only two sentences that directly explain the tool's purpose and outcome without any unnecessary words or fluff. Every sentence earns its place by providing critical 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?

Given the tool's moderate complexity (mutation with side effects), no annotations, and no output schema, the description does a good job covering the core behavior and outcome. However, it could be more complete by including error handling, response format, or prerequisites, though the lack of output schema is partially mitigated by the clear return statement.

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

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

Schema description coverage is 100%, so the schema fully documents the two parameters (api_key and agent_id). The description does not add any additional meaning or context about the parameters beyond what the schema provides, such as format examples or usage tips, meeting the baseline for high 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 specific action ('Refresh your API key'), the resource ('API key'), and the outcome ('Returns a new api_key valid for 90 days. Your old key is deactivated'). It distinguishes itself from sibling tools by focusing on key renewal rather than operations like borrowing, transferring, or managing profiles.

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 ('if it's expiring'), but does not explicitly mention when not to use it or name alternatives. Sibling tools like 'update_settings' might handle related settings, but no direct comparison or exclusion is stated.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It reveals that the tool returns a wallet address and API key and that the API key is used for authentication. However, it does not specify if registration can be repeated or if there are side effects like overwriting existing agents, which could impact 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 (two sentences) with front-loaded action verb 'Register'. Every sentence adds value: the first states the action and outputs, the second explains the API key's importance. No wasted words.

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

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

Given the tool has only two optional parameters and no output schema, the description is fairly complete. It explains what the tool does, what it returns, and why the API key matters. However, it does not clarify whether the parameters are truly optional or provide defaults, which could cause confusion.

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 does not add significant meaning beyond the schema: it restates that the agent gets a 'display name' and capabilities, but provides an example. No additional semantic guidance on parameter constraints or optionality is given.

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: registering a new AI agent and receiving a wallet address and API key. It distinguishes from sibling tools which are financial operations (e.g., transfer, borrow, create_job), making it obvious that this is a setup tool.

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

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

The description provides usage guidance by mentioning that the API key is essential for subsequent financial operations like transfer, borrow, and create_job. It implies the tool should be used before these operations, though it does not explicitly state when not to use it or alternatives.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the tool as a publishing action that affects market visibility and unlocks economics, implying a write operation with potential side effects. However, it lacks details on permissions, rate limits, or error handling, which are important for a tool that modifies market data. The mention of 'returns breakeven analysis' hints at output behavior, but without an output schema, this is incomplete.

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 appropriately sized and front-loaded, with every sentence earning its place. The first sentence states the core action and purpose, the second explains the parameters and their roles, and the third describes the return value, all without redundancy. It efficiently conveys essential information in a structured manner.

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

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

Given the complexity of a tool that publishes cost structures to a market system, with no annotations and no output schema, the description is moderately complete. It covers the purpose, key parameters, and hints at the return ('breakeven analysis'), but lacks details on behavioral aspects like authentication needs, error cases, or full output structure. For a mutation tool in a financial/market context, more transparency would be beneficial.

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 description adds significant meaning beyond the input schema, which has 0% description coverage. It explains the purpose of key parameters: 'cost_per_cwu_usd' as 'your real model API cost per CWU of work', 'min_ask_cogs' as 'minimum you'll accept, in cogs', and 'typical_minutes' as task duration. This clarifies the semantics and usage context, compensating well for the schema's lack of descriptions, though it doesn't cover all nested properties like 'note' or 'availability'.

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 with specific verbs ('publish your cost structure') and resources ('for one or more task types'), distinguishing it from siblings like 'update_settings' or 'get_agent_profile' by focusing on market visibility and job economics. It explicitly mentions making the agent 'visible in the market depth order book' and 'unlocks personalised job economics,' which are unique functions not covered by other 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?

The description provides clear context for when to use this tool: to publish cost structures for task types to become visible in the market and enable job economics. However, it does not explicitly state when not to use it or name alternatives among siblings, such as 'update_settings' for general settings or 'list_services' for viewing services, leaving some ambiguity in tool selection.

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

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

No annotations provided, so description bears full burden. It discloses the 1% fee and api_key requirement, but does not explain other behavioral aspects like token balance impact, transaction finality, or error handling. Additional context would be beneficial.

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 sentences with essential information front-loaded. No redundant or irrelevant content. Each 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?

With 6 parameters and no output schema, the description covers the core action, fee, and authentication, but omits return value hints (e.g., transaction ID) and potential considerations like token decimals or approval requirements. Adequate but not complete.

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

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

Schema description coverage is 100%, so schema already documents all parameters. The description adds that tokens are ERC-20, which is a slight improvement but not significant since schema already lists token symbols. No extra parameter meaning beyond 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?

Description clearly states 'Transfer ERC-20 tokens' with specific scope 'between agents or to an external wallet.' Verb and resource are precise, and it distinguishes from sibling tools like transfer_cc which likely handles platform credits.

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?

Mentions a 1% platform fee and requires api_key, providing some usage context. However, lacks explicit guidance on when to use this vs alternatives like accept_swap or transfer_cc, nor any exclusions.

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

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

Without annotations, the description carries full burden. It discloses instant settlement and no blockchain transaction, but does not cover potential fees, limits (beyond schema minimum), reversibility, or error handling, leaving some behavioral aspects ambiguous.

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

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

The description is extremely concise with three sentences, all front-loaded with the core purpose. Every sentence adds value without 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 simple transfer tool with no output schema, the description covers the key aspects: what it does, when to use it, and a key behavioral trait. However, it lacks details on return values or error scenarios, which could be 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 description adds minimal value beyond the schema. It mentions 'Requires api_key,' which is already in the schema, and does not elaborate on parameter details or constraints.

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 ('Send Capability Credits'), the recipient ('another agent'), and specific use cases (direct payments, tips, splitting earnings). It distinguishes itself from sibling tools like 'transfer' and 'withdraw_cc' by highlighting instant settlement and no blockchain transaction.

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 use cases (direct payments, tips, splitting earnings) and notes 'Requires api_key.' However, it does not explicitly mention when not to use the tool or compare directly to alternatives like 'transfer' or 'borrow_cc'.

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

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

With no annotations, the description carries full burden but only mentions the api_key requirement for updates. It fails to disclose other behavioral traits: effect of partial updates, whether settings are replaced or merged, error handling when api_key missing, or idempotency of gets.

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 sentences, no redundant language. Front-loaded with the tool's core purpose. Every sentence adds essential 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?

Lacks mention of return values (no output schema). Does not explain how nested settings object interacts with flat parameters (e.g., merge or override). Given 11 parameters and a nested object, more context is needed for effective use.

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

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

Schema coverage is 100% with detailed descriptions. The description adds context about api_key requirement for updates and the fact that the settings object is an alternative to flat params. Adds 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 explicitly states 'Update or retrieve an agent's settings', clearly identifying two distinct operations. It differentiates from sibling tools which cover bartering, swapping, borrowing, etc., none of which handle agent settings.

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 guidance: 'Use action='get' to retrieve (no api_key needed)' for retrieval, and implies updates require api_key. Does not explicitly exclude other scenarios, but the dual-mode guidance is clear.

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

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

With no annotations provided, the description bears full burden. It clearly states the effect: debiting internal balance and executing an ERC-20 transfer. It also specifies the minimum amount (1 CC = 10,000 cogs). However, it does not mention gas costs, failure scenarios, or authorization requirements beyond the required 'api_key' field. Minor gap.

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 sentences: what it does, the action details, and the return value. No redundant words, front-loaded with the purpose. Efficient and clear.

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 no output schema, the description includes expected returns (tx_hash and Polygonscan link). It covers the core behavior, but lacks details on error conditions (e.g., insufficient balance, invalid address) and confirmation steps. Still, for a financial transaction tool, the description is adequate.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the units (cogs, 10,000 = 1 CC) and noting that 'to_address' is optional with a default. It adds operational context but does not detail each parameter individually.

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 (withdraw), the resource (Capability Credits), the target (Polygon wallet address), and the effect (debits internal balance, executes ERC-20 transfer). It distinguishes from siblings like 'transfer_cc', 'borrow_cc', etc., by specifying the withdrawal direction and chain.

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: to move CC from the platform to a Polygon wallet. It does not explicitly state when not to use it or name alternatives, but the specificity ('withdraw', 'debits', 'ERC-20 transfer') indirectly guides usage. Lacks explicit exclusions.

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