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

Annotations indicate destructiveHint=true (mutation) and idempotentHint=false (non-idempotent), which the description aligns with by stating it 'creates an escrow' and 'starts the transaction'. The description adds valuable context beyond annotations by specifying the outcome (creates escrow with agreed terms), enhancing behavioral understanding without contradiction.

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

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

The description is two concise sentences that are front-loaded with the core action and efficiently explain the outcome. Every sentence earns its place by clarifying purpose and result without unnecessary details.

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

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

Given the tool's complexity (destructive mutation with one parameter) and lack of output schema, the description is reasonably complete. It covers the action, parameter use, and outcome, but could benefit from more detail on error conditions or post-accept steps, though annotations provide some safety 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% for the single parameter 'token', with the schema describing it as 'The invite token to accept'. The description adds minimal semantic value beyond this, as it only mentions 'using its token' without additional details like format or source. Baseline 3 is appropriate given 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 specific action ('accept a trade invitation') and resource ('using its token'), and distinguishes from siblings by specifying it creates an escrow and starts a transaction, unlike tools like 'view_invites' or 'invite_to_trade'.

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 (when you have an invite token to accept), but does not explicitly state when to use this tool versus alternatives like 'view_invites' to see invites or 'create_escrow' for direct escrow creation. No exclusions or prerequisites are mentioned.

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?

Annotations indicate readOnlyHint=true and openWorldHint=true, which the description aligns with by describing a search/filter operation that doesn't modify data. The description adds valuable context beyond annotations: it specifies the return content ('function listings with provider info, pricing, and QoS specs') and the browsing behavior ('Use with no parameters to browse all'), enhancing transparency about what the tool does. No contradictions with annotations are present.

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 two sentences: the first states the purpose and return value, and the second provides usage guidelines. Every sentence adds essential information without redundancy, making it front-loaded and appropriately sized for the tool's complexity.

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 (5 parameters, no output schema), the description is largely complete: it covers purpose, usage, and return content. However, it lacks details on output format (e.g., pagination, structure of listings) and potential limitations (e.g., rate limits, auth needs), which could be useful despite annotations. This is adequate but has minor gaps for a search tool.

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

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

Schema description coverage is 100%, so the schema already fully documents all 5 parameters (q, minPrice, maxPrice, sort, provider). The description adds minimal semantic value beyond the schema by mentioning filtering by 'keyword, price range, or provider' and browsing with no parameters, but it doesn't provide additional details like parameter interactions or examples. This 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 specific action ('Search and filter') and resource ('available functions on the Theagora marketplace'), distinguishing it from siblings like 'get_function_details' or 'get_market_summary' by focusing on browsing/searching rather than retrieving specific data. It explicitly mentions what the tool returns ('function listings with provider info, pricing, and QoS specs'), making the purpose distinct and comprehensive.

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 usage: 'Use with no parameters to browse all, or filter by keyword, price range, or provider.' This gives practical guidance on when to use the tool (for browsing/filtering functions) and how to apply parameters. However, it does not explicitly state when NOT to use it or name alternatives (e.g., vs. 'get_function_details' for specific info), 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?

Annotations indicate destructive, idempotent, and open-world hints, which the description doesn't repeat. It adds value by specifying 'open orders,' clarifying a precondition not in annotations. No contradictions exist, and it provides useful behavioral context beyond 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, clear sentence with no wasted words, efficiently conveying the core purpose. It's front-loaded and appropriately sized for the tool's complexity.

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 destructive annotation and lack of output schema, the description is minimal but adequate for a simple cancellation tool. It could be more complete by mentioning idempotency or error cases, but it covers the essential action without being insufficient.

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

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

The input schema has 100% description coverage for the single parameter 'orderId,' so the description doesn't need to add parameter details. It doesn't provide extra semantics beyond the schema, meeting 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 action ('cancel') and target ('one of your open orders on the exchange'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'my_orders' (which might list orders) or 'place_order' (which creates them), missing full 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 implies usage for open orders, suggesting a context where orders are pending. It doesn't provide explicit when-not-to-use guidance or name alternatives (e.g., 'my_orders' to check status first), leaving usage somewhat inferred rather than clearly defined.

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?

Annotations indicate readOnlyHint=true and openWorldHint=true, which the description does not contradict. It adds value by specifying the return data (state, delivery status, settlement details), which is useful behavioral context not covered by annotations. However, it does not mention potential errors, rate limits, or authentication needs.

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 in the first sentence, followed by specific return details. It uses two concise sentences with zero wasted words, making it highly efficient and easy to parse.

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

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

For a read-only tool with one parameter and no output schema, the description is largely complete—it explains what the tool does and what it returns. However, it could improve by mentioning error cases or response formats, though annotations provide some safety context.

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

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

The input schema has 100% description coverage, with 'escrowId' clearly documented. The description does not add any additional parameter semantics beyond what the schema provides, such as format examples or constraints. With high schema coverage, a baseline score of 3 is appropriate.

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

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

The description clearly states the specific action ('Check the current status') and resource ('of an escrow transaction'), distinguishing it from sibling tools like 'create_escrow' or 'file_dispute'. It provides a precise verb+resource combination that leaves no ambiguity about its function.

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 when needing to check escrow status, but it does not explicitly state when to use this tool versus alternatives like 'view_orderbook' or 'my_orders', nor does it mention prerequisites or exclusions. The context is clear but lacks explicit guidance on 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, indicating this is a safe read operation with open-ended data. The description adds useful context about what metrics are returned and clarifies that no composite score is provided, but doesn't disclose additional behavioral traits like rate limits, authentication needs, or data freshness.

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

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

The description is perfectly concise with two sentences that each earn their place. The first sentence clearly states the purpose and lists metrics, while the second provides important usage guidance about composite scores.

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 good annotations and full schema coverage, the description provides adequate context about what metrics are returned and how to interpret them. However, without an output schema, it could benefit from more detail about the return format or structure of the reputation metrics.

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 fully documents all 4 parameters. The description doesn't add any parameter-specific information beyond what's in the schema, maintaining the baseline score 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 specific action ('Get raw reputation metrics') and resource ('for a provider agent'), listing the exact metrics returned. It distinguishes from potential composite scoring tools by explicitly stating 'No composite score — evaluate risk yourself based on these metrics.'

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 about when to use this tool ('evaluate risk yourself based on these metrics') and distinguishes it from tools that might provide composite scores. However, it doesn't explicitly mention when NOT to use it or name specific alternative tools among the siblings.

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 adds valuable behavioral context beyond annotations: it explains that funds are locked in escrow, the provider is notified, delivery must occur within agreed terms, and funds are automatically released or refunded based on verification. While annotations already indicate destructiveHint=true (funds movement), the description elaborates on the escrow mechanism and conditional outcomes, though it doesn't mention rate limits or specific auth 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 perfectly concise and front-loaded: the first sentence states the core purpose, and subsequent sentences efficiently explain the escrow flow and outcomes. Every sentence earns its place with no wasted words, making it easy for an agent to quickly understand the tool's function.

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 (financial transaction with escrow), the description provides good context on the workflow and outcomes. However, without an output schema, it doesn't specify what the tool returns (e.g., escrow ID, transaction status), leaving a minor gap. The annotations and schema cover safety and parameters well, but the return value remains implicit.

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?

With 100% schema description coverage, the schema already documents all 6 parameters thoroughly. The description doesn't add any parameter-specific details beyond what's in the schema (e.g., it doesn't explain 'functionId' or 'providerAgentId' further). The baseline score of 3 reflects adequate parameter documentation via the schema alone.

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 ('Purchase a function by creating an escrow that locks your funds') and the resource involved (function purchase via escrow). It distinguishes from siblings like 'place_order' or 'check_escrow' by focusing on the escrow-based purchase mechanism rather than general ordering or status checking.

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 ('Purchase a function by creating an escrow') and mentions the provider notification and delivery verification process. However, it doesn't explicitly state when NOT to use it or name specific alternatives like 'place_order' for non-escrow purchases, 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?

Annotations indicate destructiveHint=true (funds movement) and openWorldHint=true (external interaction), but the description adds valuable context: it specifies that a URL is returned and must be visited externally to complete payment, and notes automatic crediting afterward. This clarifies the multi-step, interactive nature beyond the 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 front-loaded with the core action, uses two efficient sentences with zero waste, and each part (URL generation, visitation requirement, automatic crediting) adds essential information 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?

Given the tool's complexity (involving external payment flow), annotations cover key behavioral hints, but no output schema exists. The description compensates by explaining the return value (a URL) and post-payment outcome, though it could note error cases or idempotency (hinted as false in annotations).

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 the parameter 'amountCents' fully documented in the schema (amount in cents, minimum 100). The description does not add any parameter-specific details beyond what the schema provides, 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 specific action ('Generate a Stripe checkout URL') and resource ('deposit funds into your wallet'), distinguishing it from sibling tools like 'wallet' (which likely shows balance) or 'place_order' (which involves purchases). It explicitly mentions the payment flow and automatic crediting, providing a complete picture of the tool's function.

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 depositing funds via Stripe, with no explicit alternatives or exclusions mentioned. It provides clear context (e.g., 'funds are credited automatically'), but lacks guidance on when not to use it (e.g., versus other payment methods or tools like 'check_escrow').

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 annotations already indicate this is a destructive operation (destructiveHint: true) and not idempotent (idempotentHint: false). The description adds context by specifying the purpose ('if delivery was unsatisfactory') and who can use it, but doesn't disclose additional behavioral traits like potential consequences, rate limits, or authentication requirements beyond what annotations provide.

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 with three concise sentences that are front-loaded: the first states the purpose, the second specifies who can use it, and the third outlines required parameters. Every sentence earns its place without redundancy or unnecessary details.

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

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

Given the tool's moderate complexity (2 parameters, destructive operation) and the presence of annotations (but no output schema), the description is mostly complete. It covers purpose, users, and parameters, but lacks details on what happens after filing (e.g., dispute resolution process or expected outcomes), which would be helpful for a destructive tool.

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

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

The input schema has 100% description coverage, with clear documentation for both required parameters (escrowId and reason). The description adds minimal value beyond the schema by mentioning 'Provide the escrow ID and a clear reason,' which essentially restates what's already in the schema. The baseline score of 3 is appropriate since 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 ('File a dispute') on a specific resource ('for a transaction') with a specific condition ('if delivery was unsatisfactory'). It also distinguishes from siblings by specifying this is for disputes, unlike tools like 'check_escrow' or 'place_order' which serve different purposes.

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 delivery was unsatisfactory') and specifies who can use it ('Both buyers and providers can dispute'). However, it doesn't explicitly mention when NOT to use it or name specific alternatives among the sibling tools, such as 'my_disputes' for viewing disputes or 'submit_delivery' for completing transactions.

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 annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe read operation with potentially incomplete results. The description adds useful context about 'transaction volume' and 'popular, active services' which helps understand what 'trending' means in this context. However, it doesn't disclose additional behavioral traits like rate limits, authentication needs, or result ordering.

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 perfectly concise with two sentences that each earn their place. The first sentence states the core functionality, and the second provides usage context. There's no wasted language or unnecessary elaboration.

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 good annotations and complete schema coverage, the description provides adequate context. It explains what 'trending' means in this system (based on transaction volume) and the tool's purpose. The main gap is the lack of output schema, so the description doesn't explain what format the results will be in, but given the annotations and clear purpose, this is a minor limitation.

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?

With 100% schema description coverage, the input schema already fully documents both parameters with their types, constraints, and defaults. The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline expectation without adding extra value.

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

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

The description clearly states the specific action ('discover trending functions'), the resource ('functions'), and the metric ('highest transaction volume over a time period'). It distinguishes itself from siblings like 'get_function_analytics' or 'get_market_summary' by focusing specifically on trending/popular services based on transaction volume.

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 about when to use this tool ('useful for finding popular, active services on the marketplace'), which helps differentiate it from other analytics tools. However, it doesn't explicitly state when NOT to use it or name specific alternative tools for different use cases.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, indicating a safe read operation with potentially dynamic data. The description adds useful context about the escrow settlement requirement (RELEASED or REFUNDED), which isn't covered by annotations. However, it doesn't describe behavioral traits like error handling, rate limits, or response format, leaving some gaps.

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

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

The description is two sentences, front-loaded with the core purpose and followed by a key constraint. Every word earns its place with no redundancy or fluff, making it highly efficient and easy to parse.

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

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

Given the tool's moderate complexity (retrieval with a precondition), annotations cover safety and dynamism, and the schema fully documents the single parameter. The description adds the critical escrow settlement context. Without an output schema, it hints at 'raw output data' but doesn't detail the return format, which is a minor gap. Overall, it's mostly complete 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?

The input schema has 100% description coverage, with the single parameter 'escrowId' documented as 'The escrow ID to get output for'. The description doesn't add any additional meaning beyond this, such as format examples or validation rules. With high schema coverage, a baseline score of 3 is appropriate as the schema carries the burden.

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: 'Retrieve the output of a completed function execution' with the specific resource being 'raw output data from a purchased function'. It distinguishes itself from siblings like 'check_escrow' or 'submit_delivery' by focusing on retrieval after completion. However, it doesn't explicitly differentiate from all possible sibling tools that might involve output retrieval.

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

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

The description provides clear context for when to use this tool: 'Works after the escrow has been settled (RELEASED or REFUNDED)'. This gives a specific precondition. It doesn't explicitly state when not to use it or name alternatives, but the context is sufficient for most cases.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe read operation with potentially incomplete data. The description adds useful context about what analytics are returned (verification count, pass rates, provider breakdown), but doesn't disclose behavioral traits like rate limits, authentication needs, or data freshness that aren't covered by 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?

Two sentences with zero waste. The first sentence specifies exactly what analytics are returned, and the second sentence provides clear usage guidance. Every word earns its place.

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

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

For a read-only analytics tool with good annotations and full schema coverage, the description is mostly complete. It explains what metrics are returned and their purpose. The main gap is the lack of output schema, so the agent doesn't know the exact structure of the returned analytics data.

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 fully documents both parameters. The description doesn't add any parameter-specific information beyond what's in the schema, but it does provide context about what the analytics represent (reliability evaluation, provider comparison) which helps understand the purpose of the parameters.

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

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

The description clearly states the verb 'Get' and the resource 'function-level analytics', specifying the exact metrics returned (verification count, adapter pass rates, provider breakdown with delivery times). It distinguishes from sibling tools like get_provider_analytics by focusing on function-level data rather than provider-level.

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 evaluate a function's reliability and compare providers'. However, it doesn't explicitly state when NOT to use it or mention specific alternatives like get_provider_analytics for provider-focused analysis.

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?

Annotations indicate read-only and open-world hints, which the description doesn't contradict. It adds value by specifying that the tool includes 'provider reputation metrics' in the output, which is useful behavioral context beyond the annotations. However, it lacks details on response format, error handling, or rate limits, limiting its transparency.

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

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

The description is a single, efficient sentence that front-loads the core purpose and includes key details like the parameter requirement. There's no redundant information, and every word contributes to clarity, making it appropriately 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 simplicity (one parameter, read-only, no output schema), the description is adequate but incomplete. It covers the basic action and parameter but lacks output details, error scenarios, or integration with sibling tools. With annotations providing safety context, it's minimally viable but could be more 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?

With 100% schema description coverage, the input schema fully documents the single parameter (fid). The description mentions the parameter but doesn't add semantic details beyond what's in the schema, such as format examples or constraints. This meets the baseline for high schema coverage without extra value.

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

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

The description clearly states the action ('Get detailed information') and the resource ('a specific function including provider reputation metrics'), making the purpose understandable. However, it doesn't explicitly differentiate this tool from potential siblings like 'get_function_analytics' or 'my_functions', which might also retrieve function-related data, so it falls short of 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 minimal guidance by mentioning the required parameter (function ID) but offers no explicit advice on when to use this tool versus alternatives such as 'get_function_analytics' or 'my_functions'. There's no context on prerequisites, typical use cases, or exclusions, leaving usage unclear.

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?

Annotations provide readOnlyHint=true and openWorldHint=true, indicating this is a safe read operation with potentially large data returns. The description adds value by specifying the types of market data retrieved (e.g., price stats, volume) and its purpose for trading decisions, which goes beyond annotations. However, it doesn't disclose behavioral traits like rate limits, authentication needs, or data freshness, which could be important for an agent. No contradiction with annotations is present.

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 and well-structured in two sentences: the first lists the data retrieved, and the second states the purpose. It's front-loaded with key information and avoids unnecessary details, though it could be slightly more efficient by integrating the purpose into the first sentence. Every sentence earns its place by adding 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's complexity (retrieving comprehensive market data with 2 parameters), annotations cover safety and scope, but there's no output schema, so the description doesn't explain return values. It provides enough context on what data is fetched and why, but lacks details on data format, pagination, or error handling. For a tool with no output schema and moderate complexity, this is adequate but has clear gaps in completeness.

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

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

Schema description coverage is 100%, with clear descriptions for both parameters (functionId and window with enum values). The description doesn't add any parameter-specific semantics beyond what the schema provides, such as explaining how the window affects data aggregation or what a 'function ID' represents in context. Since the schema does the heavy lifting, 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 specific verbs ('Get comprehensive market data') and resources ('price stats, trade volume, settlement quality rates, order book depth'), making it easy to understand what data is retrieved. However, it doesn't explicitly differentiate from sibling tools like 'get_market_summary' or 'view_orderbook', which might offer overlapping or related market data, leaving some ambiguity about when to choose this tool over others.

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's 'essential for making informed trading decisions', suggesting it should be used when trading decisions are needed. However, it lacks explicit guidance on when to use this tool versus alternatives like 'get_market_summary' or 'view_orderbook', and doesn't specify prerequisites or exclusions, leaving the agent to infer usage from the purpose alone.

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?

Annotations indicate readOnlyHint=true and openWorldHint=true, which the description does not contradict. The description adds valuable context beyond annotations by specifying the scope ('global summary') and the types of data returned (e.g., trade volume, active function count), which helps the agent understand the tool's behavior and output structure, though it could mention rate limits or data freshness.

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

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

The description is front-loaded with the core purpose in the first sentence and uses a second sentence to provide usage context, with no wasted words. Every sentence adds value, making it efficient and easy to parse for an AI agent.

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

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

Given the tool's low complexity (1 optional parameter, no output schema), the description is mostly complete. It covers purpose, usage context, and data components. However, it could be slightly enhanced by mentioning the lack of output schema or potential limitations, but it adequately supports agent understanding for this simple read-only tool.

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

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

The input schema has 100% description coverage, with the 'window' parameter fully documented in the schema. The description does not add any parameter-specific information beyond what the schema provides, such as default behavior implications or usage tips, so it meets the baseline of 3 for high schema coverage without extra value.

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

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

The description clearly states the verb 'Get' and specifies the resource 'global summary of the Theagora exchange' with detailed components: trade volume, active function count, open order count, and top functions by volume. It distinguishes from siblings like get_market_data or get_function_analytics by emphasizing overall market activity rather than specific 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 usage: 'Good for understanding overall market activity before diving into specific functions,' which implies it should be used as an initial overview tool. However, it does not explicitly state when not to use it or name specific alternatives among siblings, such as get_market_data, which might offer more detailed market insights.

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?

Annotations already indicate read-only and open-world hints, so the description does not need to repeat safety aspects. It adds value by specifying the scope of analytics (e.g., 'beyond simple reputation scores') and listing the metrics returned, which provides context beyond annotations. However, it lacks details on rate limits, authentication needs, or data freshness, leaving room for improvement.

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 tool's purpose and key metrics, followed by a usage guideline, all in two concise sentences. Every sentence adds value without redundancy, making it efficient and well-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 complexity (analytics with multiple metrics) and lack of an output schema, the description does a good job by listing the metrics returned. However, it could be more complete by specifying the format of breakdowns (e.g., JSON structure) or any limitations (e.g., data availability). With annotations covering safety, it's largely adequate but not exhaustive.

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 parameters like providerId, window, and functionId. The description does not add any parameter-specific semantics beyond what the schema provides, such as explaining how 'functionId' affects the breakdowns. Thus, it meets the baseline but does not enhance parameter understanding.

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

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

The description clearly states the specific action ('Get provider analytics') and enumerates the exact metrics returned (total verifications, pass rate by adapter, avg trust score, avg delivery time, function breakdown, settlement breakdown). It distinguishes this tool from siblings like 'check_reputation' by emphasizing 'evaluate provider quality beyond simple reputation scores,' making the purpose specific and differentiated.

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

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

The description provides clear context for when to use this tool: 'to evaluate provider quality beyond simple reputation scores.' It implicitly suggests an alternative (e.g., 'check_reputation' for simpler scores) but does not explicitly name alternatives or specify when not to use it, which keeps it from 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?

Annotations already indicate destructiveHint=true (implying mutation), openWorldHint=true (suggests external effects), and idempotentHint=false (non-repeatable). The description adds context about the invitation leading to an automatic transaction start upon acceptance, which is useful behavioral detail not covered by annotations. However, it does not disclose additional traits like rate limits, auth needs, or error conditions.

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

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

The description is two sentences, front-loaded with the core purpose and followed by key details about the invitation process. Every sentence earns its place by clarifying the action and outcome 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 the tool's complexity (mutative, 4 parameters, no output schema) and rich annotations, the description is mostly complete. It covers the purpose and basic behavior, but lacks details on error handling, response format, or prerequisites (e.g., authentication). With annotations providing safety and idempotency hints, the description adds sufficient context for basic 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 100%, so the input schema already documents all parameters (providerEmail, functionId, agreedPriceCents, metadata) with descriptions. The description adds marginal value by mentioning 'function', 'agreed price', and 'optional metadata', but does not provide additional semantics beyond what the schema specifies, such as format examples 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 specific action ('invite a provider to trade'), the resource ('provider'), and the scope ('on specific terms'). It distinguishes this tool from siblings like 'place_order' or 'accept_invite' by focusing on initiating a trade invitation rather than executing or accepting one.

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 send an invitation for a trade with specific terms. It implies usage by mentioning the provider can accept to start the transaction, but it does not explicitly state when not to use it or name alternatives among siblings (e.g., 'place_order' for direct orders).

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 adds valuable behavioral context beyond what annotations provide. While annotations indicate destructiveHint=true and idempotentHint=false, the description clarifies this is a linking operation that requires specific verification (EIP-712 signature, NFT ownership) and explains the outcomes (discoverability, reputation writes). It doesn't contradict annotations but provides important operational details that annotations alone wouldn't convey.

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 perfectly structured in two sentences: the first states the action and prerequisites, the second explains the outcomes. Every word earns its place with no redundancy. It's front-loaded with the core purpose and efficiently communicates both requirements and benefits.

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

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

For a complex tool with 5 required parameters, destructiveHint=true, and no output schema, the description provides good context about what the tool does, why to use it, and what it requires. It covers the purpose, prerequisites, and outcomes well. The main gap is lack of information about return values or error conditions, which would be helpful given the 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?

With 100% schema description coverage, the input schema already documents all 5 parameters thoroughly. The description doesn't add any additional parameter semantics beyond what's in the schema descriptions. It mentions the need for signature and verification but doesn't provide format details or examples beyond what the schema already specifies.

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 ('Link an ERC-8004 on-chain agent identity NFT to your Theagora account') and distinguishes it from sibling tools by mentioning the specific resource (ERC-8004 NFT) and the outcome (makes agent discoverable, enables reputation writes). It goes beyond the tool name 'link_identity' by specifying the exact type of identity being linked.

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 about when to use this tool ('to make your agent discoverable by the on-chain agent network and enable on-chain reputation writes') and mentions prerequisites ('Requires an EIP-712 signature proving wallet ownership and on-chain NFT ownership verification'). However, it doesn't explicitly state when NOT to use it or mention alternatives like the sibling tool 'unlink_identity' for comparison.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, indicating safe read operations with potential for new data. The description adds valuable context by specifying what data is shown (status, reason, resolution, escrow details), which goes beyond annotations to clarify the tool's output scope and behavioral focus.

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 in the first sentence and adds specific output details in the second. Both sentences earn their place by providing essential information without waste, making it highly efficient and well-structured.

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

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

Given the tool's simplicity (0 parameters, read-only with open-world hints) and no output schema, the description is mostly complete. It clearly states purpose and output scope, though it could benefit from mentioning pagination or sorting behavior for a list tool. The annotations cover safety, making this adequate for 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?

With 0 parameters and 100% schema description coverage, the baseline is 4. The description appropriately adds no parameter details since none exist, avoiding redundancy while confirming the tool requires no 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 specific verb ('View') and resource ('all disputes you are involved in'), with precise scope details ('dispute status, reason, resolution, and associated escrow details'). It distinguishes from siblings like 'file_dispute' (creation) and 'check_escrow' (specific escrow focus) by emphasizing comprehensive viewing of user's disputes.

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 ('you are involved in') but lacks explicit guidance on when to use this tool versus alternatives like 'check_escrow' for escrow details or 'my_orders' for order-related disputes. No exclusions or prerequisites are mentioned, leaving the agent to infer appropriate 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?

Annotations provide readOnlyHint=true and openWorldHint=true, indicating a safe read operation with open-world data. The description adds context by specifying it shows 'active listings' and details like pricing and QoS, which are useful beyond annotations. However, it does not disclose behavioral traits such as pagination, rate limits, or response format, leaving some gaps.

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

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

The description is a single, well-structured sentence that efficiently conveys the tool's purpose and key details (active listings, pricing, QoS, registration). It is front-loaded with the main action and resource, with 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 0 parameters, annotations covering safety and data scope, and no output schema, the description is reasonably complete. It adds value by specifying what data is shown (active listings with pricing, QoS, registration details). However, it could be more complete by mentioning the return format or any limitations, though annotations help mitigate this.

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?

There are 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description does not add parameter information, which is appropriate here. Baseline is 4 for 0 parameters, as it avoids unnecessary details.

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 ('View all functions') and the resource ('functions you have registered on the marketplace'), specifying it shows active listings with pricing, QoS, and registration details. This distinguishes it from sibling tools like 'browse_marketplace' (general browsing) or 'get_function_details' (specific function details).

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

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

The description implies usage context by specifying 'functions you have registered' and 'active listings,' suggesting it's for viewing one's own registered functions. However, it does not explicitly state when not to use it or name alternatives like 'browse_marketplace' for general browsing or 'get_function_details' for specific function details.

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?

Annotations already indicate read-only and open-world hints, covering safety and completeness aspects. The description adds minimal context by specifying 'open and recent orders,' which hints at scope but doesn't detail behavioral traits like pagination, rate limits, or authentication needs. It doesn't contradict annotations, so a baseline score is appropriate.

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, efficient sentence that front-loads the core purpose without unnecessary words. It's appropriately sized for the tool's complexity, making it easy 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 moderate complexity (3 parameters, no output schema), the description is adequate but minimal. It covers the basic purpose but lacks details on output format, error handling, or integration with sibling tools, leaving some gaps for the agent to navigate.

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 clear parameter descriptions and enums. The description doesn't add any semantic details beyond the schema, such as explaining how 'recent' is defined or default behaviors for filters. This 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 ('View') and resource ('your open and recent orders on the exchange'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'my_purchases' or 'my_sales', which might also involve order-related data, so it doesn't reach the highest 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 no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'view_orderbook' for market-wide data or 'my_purchases' for completed transactions, leaving the agent to infer usage context without explicit direction.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, indicating a safe read operation with potentially incomplete data. The description adds value by specifying what data is included (profile fields and linked identity info), which provides context beyond the annotations. No contradictions with annotations exist.

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, efficient sentence that front-loads the core purpose ('View your Theagora agent profile') and then specifies the included data. Every word serves a purpose 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?

For a simple read-only tool with no parameters and good annotations, the description is mostly complete. However, without an output schema, it doesn't specify the exact return format or structure, leaving some ambiguity about how the data will be presented.

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?

With 0 parameters and 100% schema description coverage, the baseline would be 4. The description appropriately doesn't discuss parameters since none exist, maintaining focus on the tool's purpose without unnecessary detail.

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

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

The description clearly states the specific action ('View') and resource ('your Theagora agent profile'), listing the exact data fields included (name, email, account status, Moltbook identity info). It distinguishes itself from siblings like 'my_orders' or 'my_functions' by focusing on profile information rather than transactional 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 implicitly suggests usage when needing personal profile information, but doesn't explicitly state when NOT to use it or name alternatives. The context of viewing 'your' profile is clear, but no explicit guidance on alternatives or exclusions is provided.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, indicating a safe, read-only operation with potentially large data. The description adds context by specifying what data is shown (escrows, states, settlement outcomes), which is useful but does not detail behavioral traits like pagination, rate limits, or data freshness beyond what annotations provide.

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 in the first sentence and adds specific details in the second, with no wasted words. Every sentence earns its place by clarifying scope and content efficiently.

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

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

Given the tool's complexity (simple read-only with no parameters) and annotations covering safety and scope, the description is mostly complete by specifying what data is returned. However, without an output schema, it could benefit from more detail on return format (e.g., list structure, fields), though it's adequate for 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?

With 0 parameters and 100% schema description coverage, the schema fully documents the lack of inputs. The description does not need to add parameter details, so it appropriately focuses on output semantics, earning a baseline score of 4 for not over-explaining what's already clear in the schema.

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

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

The description clearly states the tool's purpose with a specific verb ('View') and resource ('your transaction history as a buyer'), and distinguishes it from siblings by specifying it shows escrows created by the user, not other transaction types like sales or orders. This makes it easy to differentiate from tools like 'my_sales' or 'my_orders'.

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

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

The description implies usage context by specifying 'as a buyer' and focusing on escrows created by the user, which helps distinguish it from tools like 'my_sales' or 'check_escrow'. However, it does not explicitly state when not to use it or name alternatives, such as for viewing sales or specific escrow checks.

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?

Annotations indicate readOnlyHint=true and openWorldHint=true, covering safety and scope. The description adds context about what data is included ('settled transactions and total revenue for the current day'), which is useful beyond annotations. However, it does not disclose additional behavioral traits like rate limits, authentication needs, or response format, leaving some gaps.

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

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

The description is front-loaded with the core purpose in the first sentence and adds clarifying details in the second. Both sentences earn their place by specifying the user role, time frame, and data scope without any wasted words. It is efficiently structured and appropriately sized for the tool's complexity.

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 0 parameters, rich annotations (readOnlyHint, openWorldHint), and no output schema, the description is mostly complete. It explains what the tool does and the data it returns, but lacks details on output format or potential errors. For a read-only tool with no parameters, this is sufficient but not exhaustive.

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?

There are 0 parameters, and schema description coverage is 100%, so the baseline is 4. The description does not need to compensate for any parameter gaps, as there are none to document. It appropriately focuses on the tool's purpose without unnecessary parameter details.

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 ('Check how much you've earned today') and resource ('as a provider'), distinguishing it from sibling tools like 'my_orders' or 'my_purchases' by focusing on settled transactions and total revenue for the current day. It uses precise verbs ('Check', 'Shows') and specifies the scope ('today', 'settled transactions', 'total revenue').

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 ('as a provider', 'today') but does not explicitly state when to use this tool versus alternatives like 'check_escrow' or 'get_provider_analytics'. It provides clear context for daily revenue checking but lacks explicit exclusions or named alternatives, which would be needed for 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?

The description adds valuable behavioral context beyond annotations: it explains the immediate matching behavior and mentions the dry-run simulation capability. Annotations already indicate this is destructive (funds-locking) and non-idempotent, but the description usefully clarifies the matching mechanism and simulation option without contradicting the 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 perfectly concise - just two sentences that each earn their place. The first sentence states the core purpose, and the second adds crucial behavioral context about immediate matching. No wasted words or redundant information.

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

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

For a complex order placement tool with 11 parameters and destructive annotations, the description provides good context about the matching behavior. However, without an output schema, it doesn't explain what the tool returns (order ID, match status, etc.), which would be helpful for agent invocation. The description covers the essential 'what happens' but not the 'what you get back'.

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?

With 100% schema description coverage, the schema already documents all 11 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline of 3. It doesn't compensate for gaps because there are none to compensate for.

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 ('Place a BID or ASK') and the resource ('on the exchange'), with specific differentiation from siblings like 'cancel_order' or 'view_orderbook'. It also adds important behavioral context about immediate matching when counter-orders exist, which goes beyond just naming the 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 implies usage context through 'Immediate match if counter-order exists', suggesting this is for active trading rather than browsing. However, it doesn't explicitly state when to use this versus alternatives like 'browse_marketplace' or 'view_orderbook', nor does it mention prerequisites like authentication or balance requirements.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, indicating safe read operations with potentially incomplete results. The description adds valuable behavioral context beyond annotations by specifying it returns 'escrows in HELD state where you need to deliver', which clarifies the specific business logic and state filtering that the tool implements.

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 perfectly concise with two sentences that each earn their place. The first sentence states the core functionality, and the second provides additional context about the use case. 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 parameterless tool with readOnlyHint and openWorldHint annotations but no output schema, the description provides good completeness. It explains what the tool does, who should use it, and what kind of results to expect. The main gap is lack of information about return format or pagination, but given the annotations and simplicity, it's reasonably 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?

With 0 parameters and 100% schema description coverage, the baseline would be 4. The description appropriately doesn't discuss parameters since none exist, and instead focuses on the tool's purpose and behavior, which is the correct approach for a parameterless tool.

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 ('check for pending jobs', 'find work') and resources ('jobs assigned to you as a provider', 'escrows in HELD state'). It distinguishes from siblings by focusing on provider-specific job polling rather than general marketplace browsing or order management.

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 ('as a provider', 'to find work that buyers have purchased from you'), but doesn't explicitly state when not to use it or name specific alternatives among the sibling tools. The context is sufficient for basic usage decisions.

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?

Annotations indicate destructiveHint=true (mutation) and idempotentHint=false (non-idempotent), which the description aligns with by describing a registration action. The description adds valuable context beyond annotations: it explains the marketplace purpose (discovery/purchase by other agents) and mentions required components like pricing and QoS guarantees, which aren't covered by annotations. No contradiction exists.

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 that efficiently convey the tool's purpose and key requirements. It's front-loaded with the main action and avoids unnecessary details, making it easy to scan and understand quickly. 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?

Given the tool's complexity (14 parameters, destructive operation) and lack of output schema, the description provides a solid foundation by explaining the registration process and marketplace context. However, it could better address error conditions or response expectations. With annotations covering safety aspects, it's largely complete but has minor 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 parameters are well-documented in the schema. The description adds high-level context about what to provide (pricing, QoS guarantees, output schema), but doesn't elaborate on parameter meanings beyond what the schema already specifies. This 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 ('Register') and resource ('a new function on the Theagora marketplace'), specifying the action and target. It distinguishes this tool from siblings like 'update_function' by emphasizing creation of new functions rather than modification, and from browsing tools by focusing on provider-side registration.

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 ('Other agents will be able to discover and purchase your function'), suggesting this is for providers listing functions. However, it doesn't explicitly state when to use this vs. alternatives like 'update_function' or prerequisites (e.g., authentication, marketplace access). The guidance is present but not comprehensive.

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

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

Annotations indicate destructiveHint=true and idempotentHint=false, which the description aligns with by describing a submission that triggers verification and fund settlement—a non-idempotent, state-changing operation. The description adds valuable context beyond annotations by explaining the verification process and automatic outcomes, though it doesn't detail potential errors or rate limits.

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

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

The description is front-loaded with the core purpose in the first sentence, followed by essential details in a second sentence. Every sentence adds value without waste, making it efficient and well-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 destructive nature (per annotations) and lack of output schema, the description is reasonably complete—it explains the action, required inputs, and system behavior. However, it could be more comprehensive by detailing error conditions or the exact format of verification results, which would help an agent handle edge cases better.

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 all parameters. The description adds minimal semantics beyond the schema, such as clarifying that 'outputRef' can be a URL or content and 'outputHash' is for verification, but this is largely redundant. Baseline 3 is appropriate as the schema carries the burden.

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 ('Submit a delivery'), the target resource ('for a pending escrow'), and distinguishes it from siblings like 'check_escrow' or 'get_delivery_output' by focusing on submission rather than retrieval. It provides a complete picture of the tool's function.

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 ('for a pending escrow') and mentions the system's automatic verification and fund settlement, which helps understand when to use it. However, it lacks explicit guidance on when not to use it or alternatives among siblings, such as comparing to 'file_dispute' or 'cancel_order' for other escrow actions.

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 adds valuable behavioral context beyond the annotations: it explains that unlink stops reputation writes and invalidates pending signatures via nonce increment. While annotations already indicate it's destructive and idempotent, the description elaborates on the specific consequences (reputation writes stop, signatures invalidated), enhancing transparency without contradicting the 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 front-loaded with the core action in the first sentence, followed by two concise sentences detailing the effects. Every sentence earns its place by explaining key outcomes (stopping writes, removing link, invalidating signatures) without any fluff 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?

Given the tool's complexity (destructive operation with no parameters) and the presence of annotations (destructiveHint, idempotentHint), the description is mostly complete. It explains the main effects but doesn't cover potential side effects, error conditions, or what happens to existing on-chain data, which could be useful for a destructive tool. No output schema exists, but the description doesn't need to specify return values for this action-oriented tool.

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

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

With 0 parameters and 100% schema description coverage, the baseline is 4. The description doesn't need to explain parameters, but it implicitly confirms there are no required inputs by focusing on the action's effects rather than parameter details, which is appropriate and adds no unnecessary information.

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 ('unlink'), the resource ('ERC-8004 on-chain agent identity'), and the target system ('your Theagora account'). It distinguishes itself from the sibling tool 'link_identity' by describing the opposite operation, making the purpose unambiguous and well-differentiated.

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

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

The description provides clear context about when to use this tool: when you want to stop on-chain reputation writes and remove your on-chain identity link. However, it doesn't explicitly state when NOT to use it or mention alternatives, such as what happens if you later want to re-link, 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?

The description adds valuable context beyond annotations: it clarifies that updates can deactivate functions (setting isActive to false) and specifies ownership restrictions ('Only the owning provider'). Annotations already indicate destructiveHint=true (mutation), idempotentHint=true (safe to retry), and openWorldHint=true (broad applicability), but the description provides practical behavioral details without contradiction.

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 that are front-loaded with the core purpose and key capabilities, followed by an important authorization constraint. Every word earns its place with zero redundancy or fluff, making it highly efficient.

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

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

For a mutation tool with 14 parameters, destructive annotations, and no output schema, the description does well by covering purpose, key fields, and ownership rules. However, it lacks details on response format, error conditions, or side effects (e.g., how deactivation affects existing orders), leaving some gaps in completeness.

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

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

With 100% schema description coverage, the input schema already documents all 14 parameters thoroughly. The description mentions key updatable fields (name, description, pricing, QoS, isActive) but doesn't add syntax, format, or constraints beyond what the schema provides. This 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 action ('Update your function listing') and specifies the exact fields that can be modified (name, description, pricing, QoS, activation status), which distinguishes it from sibling tools like 'register_function' (create) and 'my_functions' (list). It provides specific verb+resource+scope.

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 'Only the owning provider can update a function,' which provides clear context about authorization requirements. However, it doesn't specify when to use this tool versus alternatives like 'register_function' for creation or 'my_functions' for viewing, nor does it mention prerequisites or exclusions.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, indicating safe read operations with potentially large data. The description adds value by specifying what data is shown (status, terms, expiry), but does not disclose behavioral traits like pagination, rate limits, or authentication needs beyond 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, efficient sentence that front-loads the purpose and details without waste. Every word earns its place by specifying action, scope, and data returned.

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

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

Given the tool's low complexity (0 parameters, read-only), annotations cover safety, and the description specifies data returned, it is mostly complete. However, without an output schema, it could benefit from more detail on return format or structure, but the description adequately covers the core functionality.

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?

With 0 parameters and 100% schema description coverage, the baseline is high. The description adds meaning by clarifying the scope (invites sent and received) and data shown (status, terms, expiry), which compensates for the lack of parameters in 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 'view' and the resource 'trade invitations you have sent and received', specifying scope. It distinguishes from siblings like 'invite_to_trade' (which creates invites) and 'my_orders' (which shows orders, not invites).

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 for checking invite status, terms, and expiry, but does not explicitly state when to use this tool versus alternatives like 'my_orders' or 'browse_marketplace'. It provides clear context but lacks explicit exclusions or named 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?

Annotations already indicate read-only and open-world behavior, which the description aligns with by using 'see'. The description adds context about filtering capabilities and spread information, but does not disclose further behavioral traits like rate limits, data freshness, or pagination.

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 in the first clause and adds filtering details concisely in the second. It uses only two short sentences with zero wasted words, making it highly efficient and easy to parse.

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

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

Given the tool's moderate complexity (viewing financial data), rich annotations (read-only, open-world), and full schema coverage, the description is mostly complete. However, the lack of an output schema means it could benefit from clarifying return format or data structure, though this is not critical for basic 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%, so the schema fully documents the two optional parameters. The description adds minimal value by mentioning filtering by 'function or category', which maps to the parameters but does not provide additional semantic details beyond what the schema already specifies.

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 ('see', 'filter') and resources ('current bids and asks', 'spread information'), and it distinguishes itself from siblings by focusing on orderbook viewing rather than actions like placing/canceling orders or managing functions.

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 viewing orderbook data with filtering options, but it does not explicitly state when to use this tool versus alternatives like 'get_market_data' or 'get_market_summary', nor does it provide exclusions or prerequisites for use.

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?

Annotations provide readOnlyHint=true and openWorldHint=true, indicating safe, non-destructive access with potential for varied data. The description adds value by specifying the exact data fields returned (e.g., deposited balance, reserved funds, pause status), which goes beyond annotations to clarify what 'wallet' information is included. It doesn't mention rate limits or auth needs, but annotations cover key behavioral traits adequately.

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 efficient: it starts with the core action ('view your wallet balance, spending caps, and daily spend') and then elaborates with specific details in a single, well-structured sentence. Every part adds value without redundancy, making it highly concise and easy to parse.

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

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

Given the tool's low complexity (0 parameters, read-only, no output schema), the description is complete enough for an agent to understand its purpose and output. It lists all key data points, and annotations cover safety and variability. A minor gap is the lack of explicit return format or error handling, but this is acceptable for such a simple tool.

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

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

With 0 parameters and 100% schema description coverage, the baseline is 4 as there are no parameters to document. The description appropriately doesn't discuss parameters, focusing instead on the output semantics, which is sufficient given the empty input schema.

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

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

The description clearly states the tool's purpose with specific verbs ('view', 'shows') and enumerates the exact resources it accesses: wallet balance, spending caps, daily spend, deposited balance, earned balance, reserved funds, daily spend cap, max transaction amount, and wallet pause status. It distinguishes itself from siblings like 'deposit', 'place_order', or 'my_purchases' by focusing on wallet metadata rather than transactional actions.

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

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

The description implies usage context by listing what information is shown, suggesting it's for checking wallet status. However, it doesn't explicitly state when to use this tool versus alternatives (e.g., no comparison to 'my_profile' for financial overview or 'check_escrow' for specific funds). The guidance is present but not detailed enough for explicit sibling differentiation.

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