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?

Annotations already indicate readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds no additional behavioral context beyond what the annotations provide, such as rate limits or response size constraints.

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

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

The description is a single, concise sentence that directly states the tool's purpose. It lacks structure but is appropriately sized for the tool's simplicity.

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

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

The tool has no output schema, yet the description does not describe the return format or any limitations (e.g., maximum candles). For a data retrieval tool with multiple parameters, some additional context about the response would improve completeness.

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

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

The input schema has 100% description coverage for all 6 parameters, so the baseline is 3. The tool description does not add any extra meaning beyond the schema definitions.

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

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

The description clearly states the verb 'Get' and the resource 'OHLCV candlestick chart data for an AMM pool', which is specific and distinguishes it from sibling tools like sodax_get_volume or sodax_get_orderbook.

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, no context on prerequisites or exclusions. The single sentence only states the purpose without any 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 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 provide readOnlyHint=true and openWorldHint=true. The description adds no behavioral context (e.g., data freshness, pagination, rate limits). It does not contradict 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, front-loaded with verb, no wasted words. Efficiently conveys purpose and optional filter.

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

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

Given no output schema, the description would benefit from mentioning the return structure (list of assets). It implies output but is minimally adequate for a simple 2-param read tool.

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

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

Schema description coverage is 100%, so baseline 3. The description does not add meaning beyond the schema; the chainId parameter description in schema already references another tool. No additional 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?

Description clearly states verb 'Get', resource 'assets representing spoke tokens on the hub (Sonic) chain', and optional filter by source chain. It distinguishes from siblings targeting different data (e.g., borrowers, chains, swap tokens).

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

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

No explicit guidance on when to use this tool vs. alternatives among the many sibling sodax_get_* tools. The description only mentions an optional filter, without context 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 and openWorldHint=true. The description adds that it shows 'pending/open intents', but does not disclose pagination behavior, rate limits, or data freshness, leaving some gaps beyond the annotations.

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

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

The description is a single, front-loaded sentence with no fluff or redundancy, earning its place efficiently.

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

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

Given the tool has 11 parameters, no output schema, and many siblings, the description is minimal and does not explain pagination (offset parameter), data representation, or return values, leaving significant 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 coverage is 100%, so the description is not required to add parameter semantics. It does not provide extra meaning beyond the schema, thus 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 'Get', the resource 'orderbook entries', and the scope 'pending/open intents', distinguishing it from sibling tools like sodax_get_intent which retrieves a single intent.

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

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

The description implies usage for retrieving the orderbook but does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives despite many sibling tools.

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

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

Annotations already declare readOnlyHint and destructiveHint, so the description adds little. It doesn't disclose potential large return sizes, pagination, or other behaviors beyond the listing operation.

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

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

One sentence, succinct and to the point. Could mention optional filters but overall no wasted words.

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

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

Missing output schema, so description should hint at return format. It lists content types but no mention of pagination, ordering, or default response format besides the format parameter.

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

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

Schema coverage is 100% and parameter descriptions are clear. The tool description adds context about what the list contains but no additional parameter meaning beyond the schema.

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

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

Description clearly states the tool lists all SODAX integration partners, specifying categories like wallets, DEXs, and protocols. It distinguishes from sibling tool 'sodax_get_partner_summary' which likely handles individual partners.

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

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

No explicit guidance on when to use this tool vs siblings. There is a sibling 'sodax_get_partner_summary' that might be for individual partners, but the description doesn't mention alternatives or context.

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

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

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, openWorldHint=true, and destructiveHint=false, covering safety and volatility. The description adds no additional behavioral traits beyond the purpose, which is adequate given the strong annotation coverage.

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

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

Two sentences, no wasted words. The first sentence states functionality, the second adds context. Front-loaded and efficient.

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

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

For a simple read-only tool with no output schema, the description explains the output shape (prices per pair) and parameters. It lacks details on result size or pagination, but these are not critical for this tool. Annotations and schema fill most gaps.

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

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

Schema coverage is 100% with clear parameter descriptions. The tool description does not add new meaning beyond the schema, but it provides context for parameters by linking to the overall purpose. Baseline of 3 is appropriate.

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

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

The description clearly states the tool retrieves solver's oracle prices for every (chain, token) pair, with a specific use case for sanity-checking quote amounts. This is a specific verb-resource combination that distinguishes it from siblings like get_solver_quote or get_hub_assets.

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

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

The description explicitly mentions a use case ('sanity-checking quote amounts'), guiding the agent on when to use it. However, it does not provide when-not-to-use conditions or list alternatives.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so this is a read-only operation. The description adds behavioral context by describing error cases ('No path found', rejection of spoke-chain addresses), which goes 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?

Three sentences, each carrying essential information, front-loaded with purpose, no wasted words. Perfectly concise for the 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?

Despite no output schema, explains return value ('No path found' error) and format parameter. Covers all necessary context: prerequisites, error conditions, parameter behavior. No gaps.

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

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

Schema coverage is 100%, baseline 3. Description adds meaning beyond schema by explaining effect of quote_type on amount, and reinforcing hub-chain address requirement. This adds value over the schema descriptions.

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

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

The description clearly states 'Get a swap quote from the SODAX solver' with a specific verb and resource, and differentiates from sibling tools by mentioning prerequisite sodax_get_solver_oracle and noting rejection of spoke-chain addresses.

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

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

Provides explicit guidance: when to use (get a swap quote), when not (spoke-chain addresses rejected), prerequisite call, and explanation of quote_type options. This fully clarifies appropriate usage context.

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

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

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 and destructiveHint=false, so the description adds no further behavioral context (e.g., side effects, permissions, rate limits). The description is neutral and does not contradict 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 redundancy. Every word adds value. It is front-loaded with the core purpose.

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

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

The description is adequate for a simple read-only tool with two optional parameters. However, it does not describe the response structure (e.g., format of token list) since there is no output schema. Completeness is average given the tool's simplicity.

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

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

Schema coverage is 100%, but the description adds meaningful context beyond the schema: it explains the format option ('json' vs 'markdown') and provides guidance on chainId usage, including an example and reference to sodax_get_supported_chains. This helps the agent understand the parameters better.

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

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

The description clearly states the tool retrieves tokens for swapping on SODAX, with optional chain filtering. The verb 'Get' and resource 'available tokens for swapping' are specific, and the name reinforces the purpose. However, it does not explicitly differentiate from similar sibling tools like sodax_get_money_market_tokens.

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 using this tool when you need swap tokens, optionally filtered by chain. It references sodax_get_supported_chains for chain IDs. However, it does not provide guidance on when not to use it or how it compares to alternatives like sodax_get_hub_assets or sodax_get_money_market_tokens.

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 already provide readOnlyHint, openWorldHint, and destructiveHint. The description adds no additional behavioral context such as data freshness, pagination, or auth requirements.

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

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

Single sentence, no redundant words. Every word adds value. Highly 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 tool's simplicity and the presence of thorough annotations and schema, the description is complete enough. However, lack of output schema means more context on return values could help.

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

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

Schema coverage is 100% and both parameters are well-described. The description does not add further meaning beyond what the schema provides, so baseline 3 is appropriate.

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

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

Description clearly states the verb 'Get', resource 'user's lending and borrowing position', and context 'money market'. Distinguishes from sibling tools like sodax_get_all_borrowers by focusing on a single user's position.

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

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

No explicit guidance on when to use this tool versus alternatives among siblings (e.g., sodax_get_user_transactions). Usage is implied but not articulated.

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 readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read. The description adds minimal behavioral context beyond stating it retrieves history; it does not address pagination, block range behavior, or response 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, front-loaded sentence. It is highly concise with no unnecessary words, 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?

Despite having no output schema and a relatively complex parameter set (6 parameters including pagination and block range filtering), the description is too brief. It lacks explanation of return format, error handling, and how parameters interact, leaving the agent underinformed.

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

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

Schema coverage is 100%, so all parameters have descriptions. The tool description does not add any additional meaning beyond what the schema already provides. Baseline score of 3 applies.

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

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

The description clearly states the verb 'Get', the resource 'intent/transaction history', and the target 'specific wallet address'. It effectively distinguishes this tool from siblings like sodax_get_transaction (single transaction) and sodax_get_user_position (user position).

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, such as sodax_get_transaction for a single transaction or sodax_get_intent for a specific intent. The description lacks context on prerequisites or filtering scenarios.

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

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

Annotations already indicate readOnlyHint=true, openWorldHint=true, destructiveHint=false. Description adds that this is a paginated list of filled intents with filtering options, providing behavioral context beyond annotations.

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

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

Two sentences efficiently convey purpose, requirements, and constraints. Front-loaded with actionable information, no unnecessary words.

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

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

Given 15 parameters and no output schema, the description covers the main purpose, required inputs, and critical filter constraint. Could elaborate on the return structure but is sufficient for agent understanding.

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

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

Schema coverage is 100% with descriptions for each parameter. Description reinforces the key constraint about not mixing block and time range filters, adding value beyond individual parameter descriptions.

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

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

Description clearly states 'Get solver volume data showing filled intents with filtering and pagination.' This distinguishes from sibling tools like sodax_get_intent and sodax_get_solver_intent by specifying aggregated volume 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?

Explicitly states required parameters (inputToken, outputToken) and optional filters with a clear warning not to mix block range and time range. Provides good usage context but does not list alternatives or when not to use.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false. The description adds behavioral context: it is approximate, cached ~60s upstream, and aggregates fill documents. This information is beyond what annotations provide. No contradictions detected.

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

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

Two concise sentences: first states purpose, second adds caching and approximation details. No filler or redundant information. Every sentence 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 tool with one optional parameter and rich annotations, the description adequately covers what the tool does and its caching behavior. It does not explain the output format or raw data structure, but given no output schema and the simplicity of the tool, this is acceptable.

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

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

Schema coverage is 100% (the single 'format' parameter is fully described in the schema with enum and description). The description does not add any additional meaning or usage details beyond what the schema already provides, so baseline 3 is appropriate.

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

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

The description clearly states the tool gets aggregate solver volume stats, specifically the approximate total number of filled-intent records, and clarifies it's fill documents not distinct intents. This specific verb+resource combination distinguishes it from siblings like sodax_get_volume, which may have a different 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?

No guidance on when to use this tool versus alternatives. It does not mention when to use it or when not, nor does it reference sibling tools like sodax_get_solver_intent or sodax_get_volume. The usage context is entirely implied.

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

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

Annotations indicate idempotent and non-destructive behavior. The description adds value by naming the two caches cleared and stating that it reports entry counts per cache. This provides behavioral context beyond annotations, though it could mention potential latency impacts on subsequent requests.

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

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

Two sentences, no fluff. The first sentence states the action and purpose, the second describes the result. Perfectly concise and front-loaded.

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

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

For a parameterless cache-clearing tool with no output schema, the description is complete: it explains what it does and what it returns. No additional context is necessary.

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

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

There are no parameters, so the description cannot add parameter semantics. Baseline of 4 applies; the description correctly implies no arguments are needed.

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 clears two specific caches (backend API and solver oracle) to force fresh fetches, and reports the count cleared. This is a specific verb+resource that distinguishes it from the many read-only sibling tools.

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

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

The description implies usage for refreshing stale cache data, but does not explicitly state when to use it (e.g., after mutations) or when not to. No alternatives are mentioned, though the sibling list is mostly read operations, providing implicit context.

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

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

Annotations already indicate read-only and non-destructive; description adds return shape on success and error (success:false, message), providing useful behavioral context beyond annotations.

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

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

Two sentences, front-loaded, no wasted words; every sentence adds value.

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

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

Covers core behavior but lacks explanation of relationship between connSn and required parameters chainId/txHash; could be more complete regarding parameter dependencies.

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% (baseline 3), but description adds coercion details for connSn and format options, enhancing meaning beyond the schema.

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

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

Clearly states it fetches a single relay packet by connection serial number, distinguishing it from the sibling tool that fetches multiple packets per transaction.

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

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

Implies usage when needing a specific packet by connSn, but does not explicitly mention alternatives like sodax_relay_get_transaction_packets for multiple packets, nor provides when-not-to-use 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 indicate read-only and non-destructive behavior. The description adds context about status and dst_tx_hash for completion, enhancing transparency 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?

Two sentences, front-loaded with purpose and followed by usage hint. No redundant information.

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

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

For a simple list tool, it provides sufficient context: purpose, usage hint, and output interpretation. Could possibly mention pagination but not critical.

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%, and the description does not add significant meaning beyond the schema; it references params indirectly but no extra semantics.

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

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

The description clearly states it lists every cross-chain packet for a given source transaction. However, it does not differentiate from sibling tools like sodax_relay_get_packet.

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

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

It provides guidance on when to use ('track relay status') and interprets results (completion condition), but lacks explicit when-not-to-use or alternative tool references.

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 idempotentHint=true and destructiveHint=false. The description adds that re-submission is a no-op, which reinforces idempotency. It also implies a write operation but does not contradict annotations. No new behavioral traits beyond what annotations convey.

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

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

Description is three sentences, each contributing essential information: main action, prerequisite, and special case for split-tx chains. No redundancy or unnecessary words. Front-loaded with the primary purpose.

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

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

Given the complexity (4 params, nested object) and no output schema, the description covers prerequisites, idempotency, and special case guidance. It could mention what the response indicates (success/failure), but the format param implies the response format. Overall, it is adequately complete for the tool's complexity.

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

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

Schema coverage is 100%, so schema describes all parameters. The description adds context for the optional `data` parameter: 'Required only for split-tx chains (Solana, Bitcoin).' This is helpful beyond the schema's description. For other parameters, the description does not add meaning beyond the schema.

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

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

Description clearly states the action: 'Submit a confirmed spoke-chain transaction to the SODAX intent relay so it can be delivered to the destination chain.' The verb 'submit' and resource 'confirmed spoke-chain transaction' are specific. Among siblings (mostly get_* tools and relay get tools), this is the only submission tool, so it is well-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?

Description gives explicit prerequisites: 'tx must already be finalized on the source chain.' It also states idempotency: 'Re-submitting the same tx is a no-op.' For split-tx chains, it instructs to supply the optional `data` argument. However, it does not explicitly mention when not to use this tool or list alternatives.

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