SODAX Builders MCP

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

While annotations declare read-only and non-destructive traits, the description adds valuable behavioral context: it specifies the output format (markdown), notes that returned content includes navigable links, and clarifies URL input expectations with an example. It does not contradict 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 purpose and efficiently structured across 5 sentences. Each sentence serves a distinct function (purpose, usage condition, input format, sibling comparison, output characteristics) with minimal 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 absence of an output schema, the description adequately compensates by describing the return value (markdown content with links). It covers the essential context for a documentation retrieval tool, though it could optionally mention error handling for invalid URLs.

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 coverage, the baseline is 3. The description adds value by providing a concrete URL example ('https://docs.sodax.com//getting-started') and clarifying that full URLs are accepted, which supplements the schema's basic parameter description.

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

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

The description explicitly states the tool 'Fetch[es] the full markdown content of a specific documentation page' with a clear verb and resource. It effectively distinguishes itself from the sibling tool docs_searchDocumentation by contrasting full vs. partial content 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?

Provides explicit when-to-use guidance ('when you have a page URL and want to read its content') and clearly names the alternative tool (docs_searchDocumentation) with the specific condition for choosing between them (partial vs. complete details needed).

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 this is a read-only, non-destructive, open-world operation. The description adds valuable behavioral context: this is a diagnostic/health check tool that should be called proactively when other documentation tools seem unavailable. This clarifies its role as a system status checker 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 perfectly concise with two sentences that each earn their place. The first sentence states the purpose, the second provides critical usage guidance. No wasted words, front-loaded with essential information.

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

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

For a simple diagnostic tool with no parameters, read-only annotations, and no output schema, the description provides sufficient context about when and why to use it. It could potentially mention what the health check actually verifies or what a 'healthy' result looks like, but given the tool's simplicity, the current description is mostly complete.

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

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

The tool has 0 parameters with 100% schema description coverage. The description appropriately doesn't discuss parameters since none exist. It focuses instead on the tool's purpose and usage context, which is correct 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: 'Check SDK documentation availability.' This specifies the verb ('Check') and resource ('SDK documentation availability'). It distinguishes from siblings by focusing on availability checking rather than retrieving or searching documentation. However, it doesn't explicitly contrast with all sibling tools like docs_refresh.

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

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

The description provides explicit usage guidance: 'Call this first if docs tools seem unavailable.' This clearly states when to use the tool (as a diagnostic check when other documentation tools appear broken) and implies an alternative workflow (check health before using other docs tools).

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

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

Annotations indicate readOnlyHint=true, destructiveHint=false, and openWorldHint=true, covering safety and scope. The description adds value by clarifying the tool lists 'tools with parameters' and is for 'discovering what's available,' which provides context beyond annotations. No contradictions exist, and it hints at a discovery-oriented behavior.

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

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

The description is two concise sentences that are front-loaded with the core purpose. Every word earns its place, with no redundancy or fluff, 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 low complexity (0 parameters, no output schema) and rich annotations (readOnlyHint, openWorldHint, destructiveHint), the description is mostly complete. It covers purpose and usage intent adequately. A 5 would require more explicit sibling differentiation or output details, but it's sufficient for this 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. The description doesn't need to explain parameters, and it appropriately doesn't add unnecessary details, maintaining clarity 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: 'List all SDK documentation tools with parameters.' It specifies the verb ('List') and resource ('SDK documentation tools'), and adds the scope ('with parameters'). However, it doesn't explicitly differentiate from sibling tools like 'docs_searchDocumentation' or 'docs_getPage', which would require a 5.

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

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

The description provides implied usage guidance by stating it's 'Essential for discovering what's available,' suggesting it should be used for initial exploration. However, it lacks explicit when-to-use vs. alternatives (e.g., compared to 'docs_searchDocumentation' for specific queries) or any exclusions, keeping it at a basic level.

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=false, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds context by implying a reconnection action that refreshes tools, which suggests network or state changes, but doesn't detail rate limits, auth needs, or specific effects beyond 'refresh.' It doesn't contradict annotations, so it earns a baseline score for adding some behavioral insight beyond the structured data.

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 and waste-free: the first states the purpose, and the second provides usage guidance. Every word contributes to understanding the tool, making it efficient and well-structured for quick comprehension by an 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 has 0 parameters, annotations covering key behavioral traits, and no output schema, the description is largely complete. It explains what the tool does and when to use it. However, it could be more detailed about the refresh process (e.g., what 'reconnect' entails or how long it takes), but for a simple tool, it's sufficient and adds good context beyond the structured fields.

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

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

The input schema has 0 parameters with 100% coverage, so no parameters need documentation. The description doesn't mention any parameters, which is appropriate. It adds value by explaining the tool's effect ('refresh available tools'), but since there are no parameters, the baseline is high, and it compensates well by clarifying the action's outcome.

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: 'Reconnect to SDK documentation and refresh available tools.' It specifies the verb ('reconnect' and 'refresh') and resource ('SDK documentation' and 'available tools'), making the action explicit. However, it doesn't differentiate from sibling tools like 'docs_health' or 'docs_list_tools', which might also relate to documentation status, so it misses 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 provides clear context for when to use the tool: 'Use if docs seem stale or unavailable.' This gives a specific trigger condition, helping the agent decide when to invoke it. However, it doesn't explicitly state when not to use it or name alternatives among siblings, such as 'docs_health' for checking status without refresh, so it lacks full exclusion guidance.

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

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

Annotations already provide readOnlyHint=true, openWorldHint=true, and destructiveHint=false, indicating a safe, read-only operation with open-ended queries. The description adds valuable context beyond annotations by specifying what the search returns ('contextual content with titles and direct links to documentation pages'), which helps the agent understand the output format and behavior.

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

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

The description is efficiently structured in two sentences: the first states the purpose and scope, and the second provides usage guidelines and output details. Every sentence adds value without redundancy, and it's front-loaded with the core functionality.

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 parameter, no output schema), rich annotations (covering safety and openness), and clear purpose, the description is largely complete. It explains what the tool does, when to use it, and what it returns. A minor gap is the lack of details on search limitations (e.g., ranking, pagination), but this is acceptable for a simple 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?

The input schema has 1 parameter (query) with 0% description coverage in the schema. The description does not explicitly mention the 'query' parameter or provide any additional semantic details about it (e.g., format, examples, or constraints). However, since there's only one parameter and the tool's purpose is clearly about searching, the baseline of 3 is appropriate as the description implies the parameter's role without adding specific value beyond the schema.

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

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

The description clearly states the tool's purpose with specific verbs ('search across the documentation') and resources ('documentation'), and distinguishes it from sibling tools by specifying it's for searching rather than getting pages, listing tools, or refreshing. It explicitly mentions what it searches for: 'information, code examples, API references, and guides'.

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

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

The description provides explicit guidance on when to use this tool: 'when you need to answer questions about Docs, find specific documentation, understand how features work, or locate implementation details.' It distinguishes from siblings like docs_getPage (which likely retrieves a specific page) by emphasizing search functionality across documentation.

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, destructiveHint=false, and openWorldHint=true. The description adds valuable behavioral context by mentioning 'pagination', which signals the dataset is large and requires chunked retrieval. It does not add information about auth requirements or rate limits, but meets the lower bar expected when annotations cover the safety profile.

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 action ('Get all borrowers') and ends with the operational detail ('with pagination'). There is no redundant or wasted text; every word contributes to understanding the tool's scope or behavior.

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

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

Given the tool has 3 simple parameters (all optional, 100% schema coverage), annotations declaring safety properties, and no output schema, the description is sufficiently complete. It covers the domain (money market assets), the scope (all), and the retrieval pattern (pagination), enabling correct agent invocation without information overload.

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 (limit, offset, format are fully documented). The description mentions 'pagination' which conceptually maps to the limit/offset parameters, but does not add syntactic details or usage examples beyond what the schema provides. Baseline score of 3 is appropriate for high schema coverage.

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

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

The description uses a specific verb ('Get'), identifies the resource ('borrowers'), and clarifies scope ('across all money market assets'). The phrase 'all money market assets' effectively distinguishes this tool from the sibling 'sodax_get_asset_borrowers' (which targets specific assets), providing clear differentiation.

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

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

The description implies usage scope through 'all money market assets' (suggesting use for broad queries vs. specific asset queries) and mentions 'pagination' (alerting agents to large result sets). While it lacks an explicit 'use X instead for specific assets' statement, the scope specification provides clear contextual guidance for selection.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, establishing this as a safe read operation. The description adds value by disclosing what specific data is returned (contract addresses, RPCs, token configs), but does not mention rate limits, authentication requirements, or the significance of 'spoke chains' versus other chain types.

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, information-dense sentence with zero waste. Key terms are front-loaded ('Get detailed configuration') and specific examples are appended, making it easy to scan and comprehend immediately.

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 absence of an output schema, the description adequately compensates by listing the specific configuration fields returned. Combined with annotations covering safety properties, this provides sufficient context for a simple retrieval tool, though mentioning the optional nature of the format parameter would improve completeness.

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

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

With 100% schema description coverage for the 'format' parameter, the baseline score is 3. The description adds no additional parameter guidance beyond what the schema provides, but no compensation is needed given the complete schema documentation.

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

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

The description uses specific verb 'Get' and clearly identifies the resource as 'detailed configuration for all spoke chains'. It distinguishes from siblings like 'sodax_get_supported_chains' by specifying the detailed nature of the data (contract addresses, RPCs, token configs) and uses domain-specific terminology 'spoke chains' to indicate 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 provides no guidance on when to use this tool versus similar siblings like 'sodax_get_all_config' or 'sodax_get_supported_chains'. There are no prerequisites, exclusions, or alternative recommendations 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 confirm read-only, non-destructive, open-world behavior. The description adds valuable behavioral context by specifying exactly what data is retrieved (chains, tokens, settings) and implying atomic/batch retrieval ('in one call'), which helps the agent understand the scope versus making multiple individual calls.

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?

Single sentence with zero waste. Every clause earns its place: 'full' establishes scope, the three item types clarify content, and 'in one call' establishes the batching characteristic. Front-loaded with the action verb.

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

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

Given the simple single-parameter schema and strong annotations, the description adequately covers what the tool returns. It successfully compensates for the missing output schema by detailing the returned configuration components.

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 for the single 'format' parameter, the schema fully documents the input options. The description adds no parameter-specific details, which is acceptable given the complete schema coverage, warranting the baseline score of 3.

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

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

The description uses specific verbs ('Get') and resources ('full SODAX configuration'), explicitly listing the three components returned (chains, swap tokens, protocol settings). The phrase 'in one call' effectively distinguishes it from sibling tools like sodax_get_supported_chains or sodax_get_swap_tokens that return partial 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 phrase 'in one call' provides clear context that this is a batch/aggregated operation suitable when comprehensive configuration is needed. While it doesn't explicitly name alternatives or exclusions, the contrast with partial-getter siblings is evident.

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?

While annotations declare readOnlyHint=true and destructiveHint=false, the description adds no operational context beyond this. It fails to disclose data availability limits (how far back data goes), maximum date ranges, pagination behavior, or error conditions for invalid pool IDs.

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

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

The description is a single, front-loaded sentence of eight words with zero redundancy. It immediately communicates the action (Get) and resource (OHLCV candlestick chart data) without filler.

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

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

Given the rich input schema (100% coverage) and presence of annotations, the description is minimally adequate for a read-only data retrieval tool. However, the absence of an output schema means the description should ideally hint at return structure or data granularity, which it does not.

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, all six parameters (chainId, poolId, interval, from, to, format) are fully documented in the schema itself. The description adds no additional semantic context, syntax examples, or parameter relationships, meeting the baseline for high-coverage schemas.

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

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

The description uses specific financial terminology ('OHLCV candlestick chart data') that clearly identifies the resource type and distinguishes it from sibling tools like sodax_get_amm_positions or sodax_get_orderbook. However, it does not explicitly contrast its use case against these siblings.

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

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

The description provides no guidance on when to use this tool versus alternatives (e.g., sodax_get_volume for aggregate data or sodax_get_amm_positions for current holdings). There are no prerequisites, filtering recommendations, or exclusions stated.

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

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

Annotations already declare this as read-only and non-destructive. The description adds context about filtering capabilities ('optionally filtered by owner address') but omits other behavioral traits like rate limiting, authentication requirements, or whether returned positions include inactive/closed NFTs. It meets the lowered bar set by annotations but adds minimal behavioral insight.

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 single-sentence description is efficiently structured with the verb front-loaded and no redundant words. However, it may be overly terse for a tool with four parameters and pagination logic, leaving no room for usage context or return value hints.

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 absence of an output schema, the description should clarify what data is returned (e.g., position IDs, liquidity amounts, fee earnings). It mentions 'NFT positions' but doesn't describe the return structure or acknowledge the paginated list nature of the response, leaving gaps for a tool with moderate 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 schema fully documents all four parameters (limit, owner, format, offset). The description implicitly references the 'owner' parameter via 'optionally filtered by owner address' but adds no semantic value beyond what the schema already provides. Baseline score applies.

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

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

The description clearly identifies the action ('Get') and resource ('AMM liquidity provider NFT positions'), which distinguishes it from non-AMM tools. However, it fails to differentiate from the sibling tool 'sodax_get_user_position', which could cause confusion about which position-related tool to use.

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?

While the description mentions the optional owner filter, it provides no explicit guidance on when to use this tool versus alternatives like 'sodax_get_user_position', nor does it explain pagination strategies for the offset/limit parameters or when to choose between JSON and markdown formats.

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, destructiveHint=false, and openWorldHint=true, covering the safety profile. The description adds no behavioral context beyond this—no mention of pagination behavior (despite limit/offset parameters), return data structure, or what constitutes a 'borrower' in this context. For a data retrieval tool with rich annotations, this is minimal added value.

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, tightly constructed sentence with the action ('Get borrowers') front-loaded. Every word serves a purpose—'specific' distinguishes from 'all', 'money market' contextualizes the domain, and 'reserve address' identifies the key input mechanism. Zero waste.

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

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

Given the 100% schema coverage and presence of annotations, the description adequately covers the tool's intent but remains minimal. With no output schema provided, the description should ideally hint at what borrower data is returned (e.g., addresses, amounts, health factors), but it omits this entirely.

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

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

Schema coverage is 100%, with all four parameters (reserveAddress, limit, offset, format) fully documented. The description mentions 'reserve address' which aligns with the required parameter, but adds no semantic meaning beyond what the schema already provides (e.g., no examples, formats, or relationships between limit/offset).

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

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

The description uses a specific verb ('Get'), identifies the resource ('borrowers'), and scopes it to a 'specific money market asset by its reserve address'. This clearly distinguishes it from sibling tool sodax_get_all_borrowers (which lacks asset specificity) and sodax_get_asset_suppliers (which deals with suppliers instead of borrowers).

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

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

The phrase 'by its reserve address' implies prerequisite knowledge of the reserve address, providing implicit context for when to use this tool (when you have a specific asset address). However, it lacks explicit guidance on when to prefer sodax_get_all_borrowers or comparisons to related tools like sodax_get_asset_suppliers.

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 destructiveHint=false, confirming this is a safe read operation. The description adds valuable domain context by equating 'suppliers' with 'lenders'. However, it fails to disclose behavioral traits like pagination requirements (despite limit/offset parameters), rate limiting, or what constitutes a valid reserve address format.

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 with zero redundancy. Critical clarifying information (the 'lenders' parenthetical) is included without bloating the text. Every word serves a distinct purpose in defining scope, resource, and key parameter.

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 absence of an output schema, the description should ideally characterize the return value (e.g., 'returns a paginated list of lender accounts'). While the input schema is fully documented, the description leaves the agent uncertain about the response structure, error conditions, or whether the reserve address must be from a specific chain.

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 baseline score applies. The description mentions 'by its reserve address', which aligns with the reserveAddress parameter, but adds no semantic detail beyond what the schema already provides (e.g., no clarification on address format, checksum requirements, or that limit/offset enable pagination).

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

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

The description clearly identifies the resource (suppliers/lenders) and filtering mechanism (by reserve address). The parenthetical '(lenders)' effectively clarifies domain terminology, distinguishing this from borrower-related siblings. However, it uses the generic verb 'Get' rather than a more specific term like 'Retrieve' or 'List', and does not explicitly differentiate from similar tools like sodax_get_asset_borrowers.

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 explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., needing a valid reserve address from sodax_get_money_market_reserve_assets) or suggest when sodax_get_asset_borrowers might be more appropriate. Usage implications must be inferred from the parameter schema 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 already establish this is read-only and non-destructive. The description adds useful context that the response returns 'as a plain number,' hinting at the output format, but does not mention rate limits, caching behavior, or the open-world nature implied by 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?

Single sentence with zero waste: 'Get' establishes the action, 'SODA token circulating supply' identifies the resource, and 'as a plain number' clarifies the output format.

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 optional parameter, read-only operation) and comprehensive annotations, the description is sufficient. It compensates slightly for the missing output schema by describing the return value as a 'plain number.'

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 for the 'format' parameter, the baseline is 3. The description does not mention the parameter or add syntax details, but the schema is self-sufficient.

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

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

The description uses a specific verb ('Get') and resource ('SODA token circulating supply') and explicitly distinguishes itself from the sibling tool 'sodax_get_total_supply' by specifying 'circulating' supply.

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 explicit guidance on when to use this tool versus siblings like 'sodax_get_total_supply' or 'sodax_get_token_supply', 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 establish the read-only, non-destructive, open-world nature. The description adds valuable domain context by specifying the 'hub (Sonic) chain' architecture and 'spoke tokens' concept. However, it omits operational details like pagination, caching behavior (relevant given the 'sodax_refresh_cache' sibling), or response size expectations.

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

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

The description is a single, front-loaded sentence of 15 words with no redundancy. Every clause serves a purpose: the action, the asset type, the location, and the filtering capability. It could slightly improve by mentioning the response format option, but remains efficiently structured.

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

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

Given the tool's simplicity (2 optional parameters, no nested objects, no output schema) and the presence of safety annotations, the description adequately covers the domain-specific context needed. It appropriately omits return value details (no output schema exists to inform them) but successfully establishes the hub-and-spoke architectural 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 100% schema description coverage, the baseline is appropriately met. The description implicitly references the 'chainId' parameter via 'filtered by source chain' but adds no syntactic details, format examples, or semantics beyond what the schema already provides for either parameter (including the 'format' parameter which is unmentioned).

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'), resource ('assets representing spoke tokens'), and scope ('on the hub (Sonic) chain'). It uses domain-specific terminology ('spoke tokens', 'hub') that distinguishes it from generic asset tools like 'sodax_get_money_market_assets', though it could more explicitly contrast with siblings.

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

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

The phrase 'optionally filtered by source chain' implies when filtering is applicable, providing basic usage context. However, it lacks explicit guidance on when to use this versus related tools like 'sodax_get_money_market_assets' or 'sodax_get_swap_tokens', and mentions no 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 destructiveHint=false, covering safety profile. The description adds valuable semantic context that intent hashes differ from transaction hashes, but omits behavioral details like error handling (e.g., invalid hash format), rate limits, or what constitutes an 'intent' in this domain.

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?

Single efficient sentence with zero waste. Critical distinguishing information ('different from transaction hash') is included inline without verbosity. Front-loaded with the action verb.

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?

Adequate for a simple lookup tool with strong schema coverage and annotations, but gaps remain. No distinction from sodax_get_solver_intent (a close sibling), no indication of return structure (though no output schema exists to require this), and no domain context about what an intent represents.

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?

Input schema has 100% description coverage, establishing baseline 3. The description mentions 'intent hash' but does not add syntax details, format constraints, or usage examples beyond the schema's '66 character hex string' specification. The distinction from transaction hashes adds minor semantic value.

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

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

The description provides a specific verb ('Look up'), clear resource ('intent'), and lookup key ('intent hash'). The parenthetical '(different from transaction hash)' explicitly distinguishes it from sibling tool sodax_get_transaction, clarifying 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 implies usage context by distinguishing intent hashes from transaction hashes, suggesting when to use this versus sodax_get_transaction. However, it lacks explicit when-to-use guidance regarding sodax_get_solver_intent or other related tools, and provides no 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 declare readOnlyHint=true and destructiveHint=false, establishing this is a safe read operation. The description adds no further behavioral context beyond what the annotations provide (e.g., caching behavior, what 'detailed information' includes, or error handling if the address is invalid). With annotations covering the safety profile, this meets baseline but does not enrich understanding.

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 consists of a single, efficient sentence that immediately states the tool's purpose without redundancy. Every word earns its place, and the structure is appropriately front-loaded with the action and resource.

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 (single resource lookup), 100% schema coverage, and presence of safety annotations, the description is functionally complete despite lacking an output schema. A minor gap exists in not elaborating what constitutes 'detailed information', but this is insufficient to lower the score given the contextual signals provided by other fields.

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 'reserveAddress' documented as 'The reserve contract address of the asset' and 'format' fully enumerated. The description mentions 'by its reserve address' but does not add semantic value beyond what the schema already provides. With complete schema coverage, the baseline score of 3 is appropriate.

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

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

The description provides a specific verb ('Get'), resource ('detailed information for a specific money market asset'), and distinguishing scope ('by its reserve address'). This clearly differentiates it from the plural sibling 'sodax_get_money_market_assets' and other related tools by emphasizing the single-asset lookup requiring a specific address identifier.

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?

While the description implies a prerequisite (needing the reserve address), it provides no explicit guidance on when to use this tool versus similar siblings like 'sodax_get_money_market_assets' or 'sodax_get_money_market_reserve_assets'. It does not state that users should first list assets to obtain a reserve address, nor does it mention when the alternative tools are more appropriate.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, indicating a safe, read-only operation with open-world data. The description adds context by specifying the scope ('assets available for lending and borrowing'), but doesn't disclose additional behavioral traits like rate limits, authentication needs, or data freshness. No contradiction with annotations 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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it easy to parse quickly.

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

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

Given the tool's low complexity (2 optional parameters, no output schema) and rich annotations (readOnlyHint, openWorldHint, destructiveHint), the description is reasonably complete. It specifies the resource scope, though it could benefit from more context on usage or output format. The absence of an output schema is a minor gap, but the annotations provide sufficient 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%, with clear descriptions for both parameters ('format' and 'chainId'). The description doesn't add any meaning beyond what the schema provides, such as explaining default behaviors or parameter interactions. 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 verb ('List') and resource ('assets available for lending and borrowing in the SODAX money market'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'sodax_get_money_market_tokens' or 'sodax_get_money_market_reserve_assets', which might have overlapping or related 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 provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, exclusions, or specific contexts for usage, leaving the agent to infer based on the tool name and description 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 already declare readOnlyHint=true and openWorldHint=true. The description adds semantic context that these assets serve as 'collateral backing,' helping the agent understand the data's purpose. However, it fails to address the openWorld implications or describe the return structure, which would be helpful given the lack of an output schema.

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

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

The description consists of a single, efficient sentence that front-loads the verb ('Get') and wastes no words. It earns its place by conveying both the resource type and its functional role (collateral backing).

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 getter with one optional parameter and good safety annotations, the description is minimally adequate. However, given the absence of an output schema, the description should ideally indicate what data structure or content is returned (e.g., list of asset balances), which it omits.

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 for the single 'format' parameter, the schema fully documents the available options ('json' vs 'markdown'). The description adds no parameter-specific guidance, but per the rubric, the baseline is 3 when schema coverage is high.

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') and specific resource ('money market reserve assets'), adding valuable context that these are 'used as collateral backing.' However, it lacks explicit differentiation from siblings like 'sodax_get_money_market_assets' or 'sodax_get_money_market_tokens,' leaving the agent to infer the distinction based on 'reserve' terminology.

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 the numerous sibling tools (e.g., sodax_get_money_market_asset vs. sodax_get_money_market_assets). There are no prerequisites, conditions, or explicit alternatives 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 already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds domain context that these are specifically for 'lending/borrowing' activities, but does not disclose additional behavioral traits like pagination, data freshness, or the implications of openWorldHint=true.

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

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

The description is a single, front-loaded sentence with no redundant words. It efficiently conveys the core purpose. However, for a complex DeFi domain with numerous sibling tools, it may be overly terse—lacking the detail needed for robust tool selection while remaining technically concise.

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 presence of annotations and complete schema coverage, the description meets minimum viability. However, for a money market tool with no output schema and many similar siblings, it lacks explanatory depth regarding return value structure (token metadata vs just addresses) or the specific lending/borrowing protocols covered.

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

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

With 100% schema description coverage, the baseline is 3. The description mentions 'optionally filtered by chain' which reinforces the chainId parameter's purpose, but adds no additional semantic context for the 'format' parameter or parameter interactions beyond what the schema already documents.

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

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

The description clearly identifies the action ('Get') and resource ('tokens supported for money market lending/borrowing'), and specifies the domain context (lending/borrowing vs general swapping). However, it does not distinguish from the sibling tool 'sodax_get_money_market_assets', leaving potential ambiguity about the difference between 'tokens' and 'assets' in this context.

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

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

While the description mentions the optional chain filter ('optionally filtered by chain'), it provides no guidance on when to use this tool versus siblings like 'sodax_get_money_market_assets' or 'sodax_get_swap_tokens'. There are no prerequisites, exclusions, or explicit selection criteria 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, openWorldHint=true, and destructiveHint=false, indicating a safe, read-only operation. The description adds minimal behavioral context by specifying 'current' and 'pending/open intents', but doesn't detail aspects like rate limits, authentication needs, or data freshness, which could be useful 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 directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, making it easy for an agent to parse quickly.

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

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

Given the tool's low complexity (2 parameters, no output schema) and rich annotations, the description is minimally adequate. It covers the basic purpose but lacks details on output format (beyond parameter hints) or integration with sibling tools, leaving some contextual gaps for an agent.

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

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

Schema description coverage is 100%, with clear documentation for both parameters (limit and format). The description doesn't add any parameter semantics beyond what the schema provides, such as explaining the implications of 'pending/open intents' on the output, 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 action ('Get') and resource ('current orderbook entries showing pending/open intents'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'sodax_get_intent' or 'sodax_get_solver_intent', which might also retrieve order-related data, so it misses 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 provides no guidance on when to use this tool versus alternatives. It doesn't mention context, prerequisites, or exclusions, leaving the agent to infer usage based on the name alone, which is insufficient for optimal 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, openWorldHint=true, and destructiveHint=false, so the agent knows this is a safe, read-only operation with open-world data. The description adds context about what types of partners are included (wallets, DEXs, protocols), which is useful beyond annotations, but doesn't disclose behavioral traits like rate limits, authentication needs, or response structure.

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. Every part of the sentence contributes value by specifying the scope of partners.

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

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

Given the tool's low complexity (one optional parameter), rich annotations covering safety and data scope, and no output schema, the description is minimally adequate. It explains what the tool lists but lacks details on output format or behavioral context, leaving some gaps for the agent.

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

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

Schema description coverage is 100%, with the single parameter 'format' fully documented in the schema (enum values and default). The description doesn't add any parameter semantics beyond what the schema provides, so it meets the baseline of 3 for high schema coverage.

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

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

The description clearly states the verb ('List') and resource ('SODAX integration partners'), with specific examples of what partners include ('wallets, DEXs, and other protocols'). It distinguishes from most siblings by focusing on partners rather than assets, positions, or transactions, though it doesn't explicitly differentiate from 'sodax_get_partner_summary'.

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

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

No guidance is provided on when to use this tool versus alternatives like 'sodax_get_partner_summary' or other data retrieval tools. The description implies it's for listing partners but doesn't specify use cases, 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 destructiveHint=false, indicating a safe read operation. The description adds specificity about the data returned ('volume and activity') which provides context beyond the tool name, but does not address behavioral aspects like caching, rate limits, or what occurs if the receiver address is not found.

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, efficiently structured sentence with no redundant words. It front-loads the action ('Get') and immediately clarifies the subject and method, making it easy to parse quickly.

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

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

Given the tool's low complexity (3 simple parameters, 100% schema coverage, no output schema), the description adequately covers the essential functionality. The annotations handle safety classification, so the description's focus on the core retrieval purpose is sufficient, though error handling details would improve completeness.

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

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

With 100% schema description coverage, the baseline is 3. The description mentions 'receiver address' which reinforces the required parameter's purpose, but does not add semantic meaning beyond what the schema already provides for the 'format' or 'chainId' 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 provides a specific verb ('Get'), identifies the resource ('volume and activity summary'), and clarifies the scope ('for a specific integration partner'). It distinguishes from sibling 'sodax_get_partners' (plural) by specifying this retrieves data for a single partner 'by their receiver address', indicating the unique lookup mechanism.

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

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

The description provides no guidance on when to use this tool versus alternatives like 'sodax_get_partners' or 'sodax_get_volume'. It does not mention prerequisites (e.g., needing a valid receiver address format) or when this summary view is preferable to other partner-related endpoints.

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 this is a safe read operation (readOnlyHint=true, destructiveHint=false). The description adds useful domain context ('SODAX relay network') but fails to describe the return structure or cardinality given the absence of an output schema. It does not disclose potential errors, caching behavior, 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 consists of a single, efficient sentence that front-loads the action ('Get mapping') and immediately qualifies it with the specific domain context. Every word earns its place with zero 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?

While the input schema is fully covered and annotations provide safety information, the description lacks detail about the return value structure (e.g., whether it returns a bidirectional dictionary, a list of mappings, or nested objects) given that no output schema exists. For a mapping tool, this omission leaves a significant gap in understanding the tool's output.

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 fully documents the 'format' parameter options and default value. The description adds no additional parameter semantics or usage examples, meeting the baseline expectation for high-coverage schemas.

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

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

The description uses a specific verb ('Get mapping') and clearly identifies the resource (the relationship between chain IDs and intent relay chain IDs). It distinguishes from siblings like 'sodax_get_supported_chains' by specifying the 'SODAX relay network' context, though it assumes domain knowledge of what 'intent relay chain IDs' represent.

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 sibling alternatives such as 'sodax_get_supported_chains' or 'sodax_get_all_chains_configs'. It lacks explicit prerequisites, exclusions, or usage scenarios that would help an agent select this over similar chain-querying tools.

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

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

Adds valuable domain context beyond annotations: mentions 'fill history' and 'solver documents' clarifying data scope. Explains that includeAll toggles between latest and historical documents. Annotations cover safety (readOnlyHint), so description appropriately focuses on data semantics.

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

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

Two sentences with zero waste. First sentence front-loads the core purpose; second sentence provides specific parameter guidance. Appropriate length 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?

Sufficient for a read-only lookup tool with full schema coverage. Mentions key domain concepts (fill history, solver documents). Minor gap: could explicitly clarify relationship to 'sodax_get_intent', but 'solver-side' provides adequate implicit distinction.

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

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

Schema coverage is 100%, establishing a baseline of 3. The description reinforces the includeAll parameter's function but adds no syntax details, format examples, or semantic constraints beyond what the schema already provides for intentHash or format.

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

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

Specific verb 'Get' with clear resource 'solver-side details for an intent' and scope 'including fill history'. Effectively distinguishes from sibling 'sodax_get_intent' by specifying the solver-side perspective.

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

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

Provides implicit guidance via 'Use includeAll to see all solver documents', explaining how to retrieve history vs. latest state. However, lacks explicit when-to-use guidance comparing it to 'sodax_get_intent' or prerequisites for the intentHash.

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 destructiveHint=false, so the agent knows this is a safe read operation. The description adds valuable context about what's being listed ('blockchain networks supported by SODAX') and their purpose ('cross-chain swaps and DeFi operations'), which goes beyond the annotations. No contradictions with 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?

Single sentence efficiently conveys the tool's purpose without unnecessary words. Every element serves a purpose: action, resource, scope, and context. No structural issues 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 simple read-only tool with one optional parameter and comprehensive annotations, the description provides adequate context. However, without an output schema, it could benefit from mentioning what information about each blockchain network is returned (e.g., chain IDs, names, capabilities).

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 single parameter 'format' fully documented in the schema. The description doesn't add any parameter-specific information beyond what the schema provides, which is acceptable given the 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 ('List all blockchain networks') and resource ('supported by SODAX'), with explicit purpose ('for cross-chain swaps and DeFi operations'). It distinguishes from siblings like 'sodax_get_all_chains_configs' by focusing on supported networks rather than configuration 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 ('for cross-chain swaps and DeFi operations') but doesn't explicitly state when to use this tool versus alternatives like 'sodax_get_all_chains_configs' or 'sodax_get_relay_chain_id_map'. No exclusion criteria 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 already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, indicating this is a safe, read-only operation that might return varying data. The description adds minimal behavioral context beyond this, such as the optional chain filtering, but doesn't detail aspects like rate limits, authentication needs, or response format implications. With annotations covering core traits, the description provides some value but not rich behavioral disclosure.

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 ('Get available tokens for swapping on SODAX') and includes an optional feature ('optionally filtered by chain'). There is no wasted language, and it's 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 low complexity (2 optional parameters, no output schema), rich annotations (readOnlyHint, openWorldHint, destructiveHint), and high schema coverage, the description is reasonably complete. It covers the main purpose and optional filtering, though it could benefit from more explicit usage guidelines or output format details. For a simple read operation, it's largely adequate.

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

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

Schema description coverage is 100%, with both parameters ('format' and 'chainId') fully documented in the input schema. The description mentions 'optionally filtered by chain', which aligns with the 'chainId' parameter but doesn't add semantic details beyond what the schema provides. Given the high coverage, a baseline score of 3 is appropriate, as the description doesn't significantly 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 tool's purpose: 'Get available tokens for swapping on SODAX, optionally filtered by chain'. It specifies the verb ('Get'), resource ('available tokens for swapping'), and scope ('on SODAX'), but doesn't explicitly differentiate from sibling tools like 'sodax_get_money_market_tokens' or 'sodax_get_hub_assets', which might also retrieve tokens. This makes it clear but not fully sibling-distinguished.

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 'optionally filtered by chain', suggesting this tool is for retrieving swap tokens with optional chain filtering. However, it doesn't provide explicit guidance on when to use this tool versus alternatives (e.g., 'sodax_get_money_market_tokens' for non-swap tokens) or any prerequisites. The implied context is adequate but lacks specificity.

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, destructiveHint=false, and openWorldHint=true, covering the safety profile and openness. The description adds no behavioral context beyond what annotations provide, such as rate limits, authentication needs, or performance characteristics. It doesn't contradict annotations, but adds minimal value.

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. Every part of the sentence contributes directly to understanding what the tool does.

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 good annotations (readOnlyHint, openWorldHint) and a well-documented single parameter, the description provides adequate context about what information is retrieved. The main gap is lack of sibling differentiation, but overall it's reasonably complete for this complexity level.

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 one parameter ('format') fully documented in the schema. The description adds no parameter-specific information beyond what the schema provides, such as default behavior or implications of choosing different formats. Baseline 3 is appropriate when 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 verb ('Get') and resource ('SODA token supply information') with specific details about what information is included ('total, circulating, and burned amounts'). It distinguishes from some siblings like 'sodax_get_total_supply' by mentioning multiple supply metrics, though not all sibling differentiation is explicit.

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

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

No guidance is provided on when to use this tool versus alternatives. There are closely related sibling tools like 'sodax_get_total_supply' and 'sodax_get_circulating_supply', but the description doesn't explain how this tool differs from those or when it should be preferred.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context by specifying the return format 'as a plain number', which informs the agent about the response structure 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?

Single sentence with zero waste. Front-loaded with key information (action + resource + format). Every word earns its place.

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

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

For a simple read-only retrieval tool with 100% schema coverage and complete annotations, the description is sufficient. It explains what is retrieved and in what format. Could optionally mention the format parameter, but not required given schema 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?

Input schema has 100% description coverage for the 'format' parameter. The description does not mention parameters, but with full schema coverage, no additional compensation is required. Baseline score applies.

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

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

Description uses specific verb 'Get' with clear resource 'SODA token total supply'. It explicitly specifies 'total supply' which distinguishes it from sibling tools like sodax_get_circulating_supply and sodax_get_token_supply.

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

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

Description provides no guidance on when to use this tool versus the similar supply-related sibling endpoints (circulating_supply, token_supply). No context on selection criteria or prerequisites.

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

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

Annotations already indicate read-only, non-destructive, and open-world behavior. The description adds minimal context by specifying what details are retrieved ('status, amounts, and details'), but doesn't disclose additional traits like rate limits, authentication needs, or response format details beyond the schema.

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

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

The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. Every part contributes to understanding 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 simple read-only nature (annotations cover safety), 100% schema coverage, and no output schema, the description is reasonably complete. It could be improved by mentioning response format implications or error cases, but it adequately covers the tool's basic function.

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 fully documented in the schema. The description implies the 'txHash' parameter is used for lookup but adds no semantic details beyond what the schema provides, such as hash format examples or format implications.

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 ('Look up') and resource ('a specific transaction by its hash'), specifying what information is retrieved ('status, amounts, and details'). However, it doesn't explicitly differentiate from sibling tools like 'sodax_get_user_transactions' which might retrieve multiple transactions.

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

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

The description provides no guidance on when to use this tool versus alternatives, such as 'sodax_get_user_transactions' for multiple transactions or other lookup tools. It mentions the purpose but lacks explicit when/when-not instructions 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 indicate read-only, non-destructive, and open-world behavior, which the description does not contradict. The description adds minimal context by specifying 'in the money market,' but it does not disclose additional traits like rate limits, authentication needs, or data freshness. With annotations covering safety, the description provides some value but lacks rich behavioral details.

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. It front-loads the core purpose efficiently, making it easy to parse. Every part of the sentence contributes directly to understanding 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 annotations cover safety (read-only, non-destructive) and the schema fully describes parameters, the description is adequate for a query tool. However, without an output schema, it does not explain return values (e.g., what data fields are included), and it lacks context on data scope or limitations. This leaves gaps in completeness for effective agent 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 parameters are well-documented in the schema. The description does not add meaning beyond the schema, as it mentions no parameters. However, it implies the 'userAddress' parameter is central by focusing on 'a user's' position, aligning with the schema. Baseline 3 is appropriate since the schema handles parameter documentation.

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

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

The description clearly states the tool's purpose: 'Get a user's lending and borrowing position in the money market.' It specifies the action ('Get'), the resource ('user's lending and borrowing position'), and the context ('money market'), which is specific and informative. However, it does not explicitly differentiate from sibling tools like 'sodax_get_user_transactions' or 'sodax_get_amm_positions', which might have overlapping contexts.

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 lacks context such as prerequisites (e.g., needing a valid user address), comparisons to siblings (e.g., 'sodax_get_user_transactions' for transaction history), or exclusions (e.g., not for general asset queries). This leaves the agent without clear usage 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 indicate read-only, non-destructive, and open-world behavior, so the description doesn't need to repeat these. It adds some context by specifying 'history' and 'specific wallet address,' which clarifies scope. However, it doesn't disclose additional traits like rate limits, authentication needs, or data freshness, limiting added value 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. It's front-loaded with the core purpose and efficiently conveys the tool's function. Every part of the description earns its place, making it highly concise and well-structured.

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

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

Given the annotations cover safety and world hints, and the schema fully describes inputs, the description is adequate for a read-only query tool. However, without an output schema, it doesn't explain return values or format implications, and it lacks usage context compared to siblings, 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?

Schema description coverage is 100%, so the schema fully documents all parameters. The description adds minimal semantic context by mentioning 'specific wallet address,' which aligns with the 'userAddress' parameter. No additional parameter details are provided beyond what the schema offers, meeting the baseline for high coverage.

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

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

The description clearly states the tool's purpose: 'Get intent/transaction history for a specific wallet address.' It specifies the verb ('Get') and resource ('intent/transaction history'), making it easy to understand. However, it doesn't explicitly differentiate from sibling tools like 'sodax_get_transaction' or 'sodax_get_intent,' which might handle similar data, so it doesn't reach 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 no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, exclusions, or compare it to sibling tools such as 'sodax_get_transaction' or 'sodax_get_intent,' leaving the agent to infer usage context. This lack of explicit guidelines reduces its effectiveness.

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, destructiveHint=false, and openWorldHint=true, indicating a safe, read-only operation with open-world data. The description adds useful context about filtering constraints ('don't mix both' for block/time ranges) and pagination, which aren't covered by annotations. However, it doesn't disclose rate limits, authentication needs beyond parameters, or detailed behavioral traits like response structure, so it adds moderate value.

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 front-loaded: it starts with the core purpose, then lists requirements and optional filters in a single sentence. Every part earns its place by clarifying usage, but it could be slightly more structured (e.g., separating prerequisites from filters). No wasted words, but minor improvements in organization are possible.

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 (13 parameters, filtering, pagination) and rich annotations (readOnlyHint, openWorldHint), the description is reasonably complete. It covers key usage aspects like required parameters and filtering rules. However, without an output schema, it doesn't explain return values (e.g., what 'solver volume data' includes), leaving a gap. The annotations help, but more detail on output would improve completeness.

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

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

Schema description coverage is 100%, so the schema fully documents all 13 parameters. The description adds minimal semantic value beyond the schema: it mentions 'Requires inputToken and outputToken' (already in required fields) and hints at filtering logic ('block range OR time range'). Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't significantly 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 tool's purpose: 'Get solver volume data showing filled intents with filtering and pagination.' It specifies the verb ('Get'), resource ('solver volume data'), and scope ('filled intents'). However, it doesn't explicitly differentiate from sibling tools like 'sodax_get_solver_intent' or 'sodax_get_intent', which might retrieve similar data, so it misses 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 clear context for usage: 'Requires inputToken and outputToken. Optional filters: chain, solver, block range OR time range (don't mix both).' This gives explicit prerequisites and filtering options, but it doesn't mention when to use this tool versus alternatives like 'sodax_get_solver_intent' or other sibling tools, so it's not a full 5.

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

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

Annotations indicate this is a non-read-only, idempotent, non-destructive operation. The description adds valuable context by specifying that it clears cached API data and forces fresh fetches, which clarifies the tool's effect beyond the annotations. It doesn't contradict annotations, as 'clear' aligns with non-read-only, and idempotency/destructiveness hints are consistent.

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 directly states the tool's function without redundancy. It's front-loaded with the core action and outcome, making it easy to parse. Every word contributes to understanding, with no wasted verbiage.

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

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

Given the tool's simplicity (0 parameters, no output schema) and annotations covering key behavioral traits, the description is reasonably complete. It explains what the tool does and why, though it could benefit from more usage context or examples. For a cache-clearing tool, this is 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?

With 0 parameters and 100% schema description coverage, the schema fully documents the lack of inputs. The description doesn't need to add parameter details, so it appropriately focuses on the tool's purpose. A baseline of 4 is given since no parameters exist, and the description doesn't introduce unnecessary complexity.

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 ('Clear the cached API data') and the outcome ('force fresh fetches on next requests'), providing a specific verb+resource combination. However, it doesn't explicitly distinguish this tool from sibling tools like 'docs_refresh', which might have similar cache-clearing functionality but for different resources.

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 fresh data is needed, but provides no explicit guidance on when to use this tool versus alternatives (e.g., when cached data is stale or inaccurate). It doesn't mention prerequisites, exclusions, or compare it to similar sibling tools, leaving the agent to infer context.

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