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

Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds 'operation class write' and warns to confirm state before writes, providing behavioral context beyond annotations. It does not detail undo implications or failure modes, but the pre-flight check guidance is valuable.

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

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

The description is moderately concise but includes redundant phrases like '3.Land' multiple times and a sentence about SAP MCP context that, while useful, could be integrated more seamlessly. It front-loads the purpose but has some wordiness.

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

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

Given the tool's simplicity (2 parameters, output schema exists), the description covers the main purpose, provides pre-write checks, and mentions a pairing condition for registry metadata. It lacks details on post-purchase outcomes, but output schema likely fills gaps. Overall, it is fairly 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?

Input schema covers both parameters (buyer, listingId) with descriptions (e.g., 'Solana public key (base58)'), achieving 100% coverage. The tool description does not add further semantic value beyond confirming their use, 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 'Purchase an NFT from a 3.Land listing,' specifying the verb and resource. It distinguishes from sibling tools like 3land_createCollection, 3land_mintAndList, etc., by focusing on the buy action, making the purpose unambiguous.

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

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

The description advises to 'Confirm marketplace price, seller/buyer wallet, collection, and listing state before writes,' which provides usage context. However, it does not explicitly state when not to use this tool or mention alternatives like 3land_mintAndList for combined minting and listing, leaving some guidance missing.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds 'operation class write' which is redundant. Does not disclose additional behaviors like authentication, side effects, 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?

Reasonably concise with front-loaded purpose. The SAP MCP context adds some verbosity but overall structure is clear and minimal.

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?

Adquate given output schema and annotations. Lacks details on prerequisites (e.g., ownership of listing) and return behavior, but the cautionary note partially compensates.

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 seller and listingId. The description does not add further meaning beyond the schema, so 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?

Clearly states the action: 'Cancel an active NFT listing on 3.Land.' The verb 'cancel' and resource 'active NFT listing' are specific. Distinguishes from sibling tools like 3land_listForSale and 3land_buyNFT.

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?

Broadly mentions using for '3.Land NFT collection, minting, listing, cancellation, and purchase flows' but does not explicitly define when to use or alternatives. Precautionary notes are included but no exclusions.

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

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

Annotations indicate a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds that it is an 'operation class write' and advises confirming marketplace state before writes, which provides some behavioral context. However, it does not disclose potential side effects, reversibility, or failure modes, especially given 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 4 sentences, but it is not tightly focused. It includes redundant information (e.g., 'SAP MCP context: Protocol 3land; operation class write' which repeats annotation info) and a confusing sentence listing multiple flows. It could be more concise by eliminating extraneous content.

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

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

An output schema exists (not shown), so description need not explain return values. However, the description lacks critical context such as what happens on successful creation (e.g., collection ID), error conditions, prerequisites beyond the mentioned confirmation, and how the output schema relates to the process. With high schema coverage, the description is minimally adequate.

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

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

Schema description coverage is 100%, so the input schema already documents all parameters. The description does not add any additional meaning to the parameters beyond what is in the schema. It mentions preconditions but no parameter-specific guidance. Baseline score of 3 is appropriate 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 tool's purpose: 'Create a new NFT collection on 3.Land marketplace.' This is a specific verb+resource pair, and the tool name matches. It distinguishes itself from sibling 3land tools (e.g., 3land_mintAndList, 3land_listForSale) by focusing solely on collection creation.

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 says 'Use for 3.Land NFT collection, minting, listing, cancellation, and purchase flows,' which is overly broad and does not clearly differentiate when to use this specific tool versus siblings. There is no explicit guidance on when not to use it or mention of alternatives like 3land_mintAndList or 3land_listForSale. The caution about confirming state is useful but not sufficient for usage decisions.

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

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

The description states 'operation class write' but annotations declare readOnlyHint=true, indicating it is read-only. This is a direct contradiction. Additionally, the idempotentHint=true annotation is questionable for a listing action. The description fails to add value and instead misleads.

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 relatively concise and front-loaded with the core action. However, the inclusion of 'SAP MCP context' and other meta-instructions slightly reduces conciseness. Still, most sentences serve a 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 covers the main purpose and usage guidelines, but the contradiction and incorrect parameter description (priceMint) detract from completeness. The presence of an output schema reduces the need to describe return values, but the behavioral contradiction is a significant gap.

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

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

Schema coverage is 100%, so baseline is 3. The description mentions 'in any SPL token' which adds context to the price and priceMint parameters, but the priceMint description in the schema is incorrect ('NFT mint address' instead of token mint). No additional semantics beyond schema.

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

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

The description clearly states the tool's function: 'List an NFT for sale on 3.Land in any SPL token.' It also contextualizes its use among sibling tools (e.g., 3land_cancelListing, 3land_buyNFT) by mentioning flows like minting, listing, cancellation, and purchase.

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: 'Confirm marketplace price, seller/buyer wallet, collection, and listing state before writes' and 'Pair marketplace actions with SAP registry metadata only when the marketplace asset is part of the agent identity or service catalog.' This tells when to use and 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?

Repeats annotation info ('operation class write') without adding behavioral details like error handling, atomicity, or fees. The note to 'confirm... before writes' is a prerequisite, not a behavioral trait. Annotations already indicate write and not destructive, so description adds minimal transparency.

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

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

One paragraph, but includes vague 'Use for...' and 'SAP MCP context' that add noise. Core action is clear, but extra sentences reduce conciseness.

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 9 parameters, existing output schema, and sibling tools, the description lacks details on atomicity of mint+list, failure scenarios, and prerequisites beyond 'confirm before writes'. Not sufficiently complete for a complex write operation.

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

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

Schema description coverage is 100%, so baseline is met. The description does not add any meaning beyond the schema's 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?

States 'Mint an NFT on 3.Land and automatically list it for sale' – a specific verb and resource. Distinguishes from sibling '3land_listForSale' by combining both actions, though the broad 'Use for... cancellation and purchase flows' introduces ambiguity.

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?

Does not explicitly guide when to use this tool versus siblings like '3land_listForSale' or '3land_cancelListing'. The vague 'Use for... flows' suggests inappropriate use cases, and no clear alternative is provided.

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

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

Annotations declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false. The description adds no further behavioral context beyond the basic action, such as authorization needs, state changes, or error scenarios.

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: the first gives a clear purpose, the second adds SAP MCP context. While the second sentence is tangential, it does not significantly bloat the description, but it could be removed for better focus.

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 an output schema, the description does not mention return values, side effects, or error cases. For a state-changing DeFi tool, more context is needed to ensure safe usage.

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

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

Schema coverage is 100% with descriptions for each parameter. The tool description does not add any additional meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.

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

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

The description clearly states the specific action: 'Add collateral to an existing Adrena position.' This distinguishes it from sibling tools like adrena_openPosition, adrena_closePosition, adrena_removeCollateral, and adrena_getPositions.

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

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

The description includes SAP MCP context about publishing tools but provides no guidance on when to use this tool versus alternatives, no prerequisites (e.g., existing position required), and no when-not-to-use conditions.

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

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

Annotations already indicate destructiveHint=true, so the description adds no extra behavioral context. It does not disclose what happens when a position is closed (e.g., collateral returned, fees incurred).

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

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

The description is extremely concise with two sentences. The first sentence states the purpose, and the second provides important ecosystem context. No wasted words.

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

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

Given the simple two-parameter tool with an output schema, the description is minimally adequate. However, it lacks critical details like prerequisites (position must exist) and consequences (destruction of position).

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

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

Schema coverage is 100% with descriptions for both parameters. The description adds no additional meaning beyond what the schema already provides.

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

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

The description clearly states the verb and resource: 'Close a perpetual position on Adrena Protocol.' It is specific and distinguishes from sibling tools like adrena_openPosition and adrena_addCollateral.

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

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

The description includes SAP MCP context and advises using SAP registration tools when needed. However, it does not explicitly state when to use this tool versus other Adrena position 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=true, so safety is covered. The description adds no behavioral details beyond the basic function, such as authentication needs, rate limits, or error handling. It merely restates the purpose without enriching transparency.

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

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

The description is concise with two sentences. The first sentence effectively communicates the core purpose, while the second provides optional integration context. Although the second sentence may be extraneous for basic usage, the overall structure is efficient.

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

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

Given the tool's simplicity (one parameter, read-only, with annotations and output schema), the description sufficiently covers the essential aspects. Missing details like error handling are not critical enough to lower the score significantly.

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 covers 100% of the single parameter with a clear description ('Solana public key (base58)'). The description does not add further semantic value, so 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 'Get all open positions on Adrena Protocol,' specifying the verb (get) and resource (open positions on Adrena Protocol). This distinguishes it from sibling tools like adrena_openPosition and adrena_closePosition, which handle position creation and closure.

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

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

The description includes SAP MCP integration context but fails to provide guidance on when to use this tool versus alternatives. No scenarios, prerequisites, or exclusions are mentioned, leaving the agent without clear usage direction.

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

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

Annotations already provide readOnlyHint=false and destructiveHint=false. The description adds the SAP integration context but does not disclose additional behavioral traits such as fees, liquidation risks, or chain interactions. It is adequate but not enhanced 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, no fluff. The first sentence states the core purpose, and the second provides essential integration context. 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?

An output schema exists, so return values are documented elsewhere. The description is simple but sufficient given the thorough schema and annotations. It does not cover prerequisites or protocol details, but the required parameters implicitly cover wallet and market info.

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 covers all 8 parameters with descriptions (100% coverage). The description does not add any parameter-specific semantics, so it meets the baseline 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 clearly states the action ('Open'), the resource ('leveraged perpetual position'), and the protocol ('Adrena Protocol'). It distinguishes itself from sibling tools like adrena_closePosition and adrena_addCollateral.

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

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

The description includes SAP integration context, indicating when to use SAP registration tools, but does not explicitly specify when to use this tool versus other perpetual position tools (e.g., drift_openPerpPosition). No direct when/when-not guidance is given.

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 destructiveHint=true and readOnlyHint=false. The description adds no extra behavioral details beyond 'Remove collateral,' missing info on side effects, reversibility, or permissions. 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?

The first sentence is concise, but the second sentence is a lengthy, tangential context about SAP tools, which adds noise and reduces conciseness. The description is adequately sized but not optimally structured.

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

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

Given the tool's simplicity and the presence of an output schema, the description is minimally complete. It lacks prerequisites (e.g., position existence, wallet ownership), return value hints, and behavioral safeguards beyond what annotations provide.

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

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

Schema coverage is 100% for the three parameters. The description lists the parameter names but adds no semantic value beyond the schema—e.g., no explanation of 'raw token amount' or examples. Baseline 3 is appropriate.

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

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

The description clearly states the tool's action: 'Remove collateral from an Adrena position.' This is specific verb+resource, and it distinguishes from sibling tools like adrena_addCollateral and adrena_closePosition.

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

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

The description includes a lengthy paragraph about SAP MCP context and names alternative tools, but it does not provide explicit guidance on when to use this tool versus alternatives. It lacks exclusions or contextual cues for the agent.

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 idempotentHint=true, so the safety profile is clear. The description adds the phrase 'operation class read' but does not disclose any additional behavioral traits 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 three sentences that are concise and front-loaded. The first sentence clearly states the action. The second provides SAP MCP context, and the third gives a usage suggestion. No fluff, though the SAP context may be redundant for agents.

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

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

Given the tool's simplicity (2 parameters, output schema exists), the description adequately explains the purpose and usage context. It mentions 'across all TLDs' and provides a discovery usage scenario. The output schema handles return format details.

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

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

Schema description coverage is 100%, so the schema already documents both parameters (wallet and tld). The description adds no extra 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?

The description clearly states the action ('Get all domains owned by a wallet') and the resource (domains owned by a wallet across all TLDs). It distinguishes itself from sibling tools like alldomains_registerDomain and alldomains_resolveDomain, which have different purposes.

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

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

The description provides explicit context: 'Use to list domains owned by a wallet through AllDomains. Use as discovery context before choosing a name to associate with an agent.' This tells the agent when to use it, though it does not explicitly mention when not to use or alternatives.

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

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

Discloses operation class as write, consistent with annotations (readOnlyHint=false). Adds context about needing to confirm terms before writes, which is helpful 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?

Four sentences, well-structured. Front-loads main purpose, then context, then usage guidance. Could be slightly tighter but overall concise and clear.

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

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

Covers purpose, usage condition, and behavioral advice. Output schema exists, so return value documentation is not required. Complete enough for agent to use correctly.

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

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

Schema covers all 3 parameters fully (100% coverage). Description adds examples for domain and clarifies TLD support, but does not significantly extend beyond 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 tool's function: registering a domain on AllDomains, supporting multiple TLDs. It also distinguishes from SNS-specific tools by noting when to use this tool instead.

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 advises to use only when the name service is not SNS-specific, and recommends confirming domain, TLD, owner, and terms before writes, providing clear guidance on when and how 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 indicate readOnlyHint, idempotentHint, destructiveHint=false. Description adds minimal context beyond stating it is a read operation and the protocol. No contradictions.

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

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

Three sentences, front-loaded with purpose, then context, then usage condition. No wasted words, efficient and 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?

With output schema present, return values are handled. Description covers purpose, context, and usage condition adequately for a simple read-only tool. No major gaps.

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

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

Only one parameter 'domain' with schema description 'Full domain to resolve'. Schema coverage is 100%, so description adds no extra meaning beyond what schema provides.

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

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

The description clearly states the verb 'resolve' and the resource 'multi-TLD domain to its owner wallet'. It distinguishes from siblings by specifying 'Use only when the requested name service is not SNS-specific', though it does not explicitly name alternative 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?

Provides clear usage condition: 'Use only when the requested name service is not SNS-specific'. Also includes context of Protocol alldomains and operation class read. Does not explicitly list alternative tools but implies differentiation from SNS.

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

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

The description claims 'operation class read' but annotations set readOnlyHint=false, creating a contradiction. The tool builds a URL (likely no side effects), but the inconsistency undermines trust.

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, but includes jargon like 'SAP MCP context' that may not help users. It could be more 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?

Given the tool has an output schema (implied), the description doesn't need to detail output, but it fails to clarify the return value or how the URL is used in the broader action flow.

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

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

Schema coverage is 100%, so the description adds minimal value beyond the schema. It mentions wrapping in a Blink provider, which is already in the schema's blinkProvider description.

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

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

The description clearly states it builds and optionally wraps a Solana Action URL for sharing as a Blink. It distinguishes from siblings like blinks_getAction by focusing on URL construction, but the mention of 'operation class read' introduces slight ambiguity.

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

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

The description provides some usage context ('Use for Solana Actions and Blinks metadata fetch, validation, and POST action preparation') but lacks explicit when-not-to-use or differentiation from alternatives like blinks_validateActionsJson.

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

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

The description claims 'operation class read' but annotations indicate readOnlyHint=false, creating a contradiction. Beyond that, minimal behavioral context is provided (e.g., no mention of side effects, authorization needs, or post-confirmation steps).

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

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

The description is concise with three sentences, and the first sentence clearly states the core purpose. However, it could be slightly more front-loaded by removing the less essential MCP context sentence.

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 an output schema and complete input schema, the description is adequate for a simple confirmation tool. However, it does not explain workflow placement (e.g., must be called after signing) or handle potential errors.

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% coverage, so parameters are already documented. The description adds no meaningful extra context beyond the schema's own descriptions. Baseline 3 is appropriate.

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

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

The description clearly states the tool's function: confirming a completed Solana Action by sending the transaction signature back to the provider. The verb 'confirm' and resource 'completed Solana Action' are specific, and it distinguishes from siblings like blinks_executeAction or blinks_getAction.

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

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

The description mentions using the tool for 'Solana Actions and Blinks metadata fetch, validation, and POST action preparation' but does not explicitly differentiate when to use this tool versus alternatives like blinks_executeAction or blinks_validateActionsJson. The guidance is vague and lacks exclusion criteria.

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

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

Annotations already indicate destructiveHint=true and readOnlyHint=false. The description reinforces this by describing the flow as sending to an Action endpoint and receiving a transaction to sign, implying mutation. It adds a caveat to preview/validate output before signing, but no new behavioral traits beyond annotations. No contradiction.

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

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

The description is fairly concise at about 80 words, front-loaded with the core action. It includes necessary context (SAP MCP) and usage warnings, though the phrases 'SAP MCP context' and the repetition of 'SAP transaction tools' could be trimmed. Still, 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?

Given the tool's complexity (executing an external Solana Action and returning a transaction to sign), the description covers the key steps: sending to endpoint, receiving transaction, and need for preview/validation. An output schema exists (not shown), so return values need not be detailed. Slightly more detail on what happens after signing 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?

Input schema has 100% description coverage for all three parameters (actionUrl, wallet, params). The description does not add any additional meaning beyond what the schema already provides; the only reference to parameters is a generic 'confirm the action... parameters.' 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 tool's function: execute a Solana Action by sending wallet to endpoint and receiving transaction to sign. It distinguishes from sibling blinks tools (build, confirm, get, resolve, validate) by specifying 'Use to execute a Solana Action POST flow' and referencing the blinks protocol and write operation class.

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 says when to use this tool ('Use to execute a Solana Action POST flow') and provides action items: confirm metadata, parameters, expected transaction, and user intent before invoking, and preview/validate output before signing. It does not explicitly list alternatives but the context of sibling tools makes them clear.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral details beyond annotations, such as returning specific metadata and supporting validation/preparation, without contradicting any annotation.

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

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

The description is three sentences long, front-loading the core purpose, then adding context and usage. Every sentence adds value without redundancy, making it concise and well-structured.

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

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

With an output schema present, return values are covered. The description sufficiently covers purpose, usage, and validation context. Given the tool's simplicity (single parameter, read-only), it is fully complete.

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

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

Schema coverage is 100% and the only parameter (actionUrl) is well-described in the schema. The description does not add any additional semantics for the parameter beyond what the schema provides, so baseline score 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 fetches metadata for a Solana Action (Blink) and lists the returned fields (title, description, available actions, parameters). It distinguishes itself from sibling tools like blinks_executeAction and blinks_confirmAction by focusing on metadata retrieval and validation.

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 context: 'Use for Solana Actions and Blinks metadata fetch, validation, and POST action preparation' and advises to preview/validate before signing. While it doesn't explicitly state when not to use, the context and differentiation from siblings are clear.

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

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

Annotations already indicate readOnlyHint, idempotentHint, and non-destructive nature. The description adds context about previewing and validating actions, which is consistent and provides additional behavioral insight without contradiction.

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

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

The description is concise, front-loading the primary action, and uses only two sentences. Some internal jargon ('SAP MCP context') may be unnecessary but does not detract significantly.

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 an output schema, the description does not need to detail return values. It covers purpose, use cases, and context for a simple read-only resolution tool, which is adequate.

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

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

Schema coverage is 100% with a clear description for the single parameter. The tool description repeats the example URL from the schema, adding no significant new semantic value beyond what the schema already provides.

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

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

The description clearly states the tool resolves a Blink URL to a Solana Action URL, with specific uses like metadata fetch and validation. However, it does not explicitly distinguish from sibling tools such as blinks_getAction or blinks_validateActionsJson, though the context of 'operation class read' provides some 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 mentions use cases (metadata fetch, validation, POST preparation) and advises using before signing transactions. However, it lacks explicit guidance on when not to use this tool or direct alternatives, leaving the agent to infer from sibling names.

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?

Contradicts annotations: description says 'operation class read' but annotations declare readOnlyHint: false, indicating potential write capability. This inconsistency severely undermines agent understanding of tool behavior. Description adds no further behavioral context beyond this contradiction.

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

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

Description contains some redundancy (e.g., 'SAP MCP context: Protocol blinks; operation class read' is technical jargon that may not add value for all agents) and could be more concise. It is front-loaded but includes unnecessary details.

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

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

Given the tool's simplicity (one parameter, output schema exists), the description is mostly adequate but the behavioral contradiction leaves a gap. It covers usage context but not all edge cases or behavioral expectations.

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?

Single parameter 'domain' with 100% schema coverage. Description adds useful example ('jupiter.exchange') and clarifies it specifies the domain to check for actions.json, which supplements the schema definition.

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 validates a domain's actions.json file, checking Solana Actions spec compliance. It distinguishes from sibling blinks tools like buildActionUrl or getAction by focusing on validation.

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 context ('Use for Solana Actions and Blinks metadata fetch, validation, and POST action preparation. Preview and validate actions before signing or submitting transactions') but lacks explicit when-not or alternative tool guidance. Sibling tools exist for other actions like building URLs or executing actions, but no exclusions 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 indicate destructive write. Description adds 'fast cross-chain transfers with deterministic pricing' and mentions finality expectations. But no details on failure behavior, refunds, or slippage mechanics. No contradiction 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?

The description is overly long and includes extraneous context like 'SAP MCP context: Protocol bridging; operation class write' and a detailed paragraph on SAP agent registration that is irrelevant for using this tool directly.

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 details on return format, error handling, and slippage behavior (e.g., slippageBps param not explained). The description focuses on SAP setup rather than tool-specific execution context, leaving gaps despite full schema and output schema.

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

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

Schema covers 100% of parameters with descriptions. The tool description echoes some param names (source chain, destination chain, token mint, amount, recipient) but adds no new semantic detail beyond what's in the schema.

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

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

The first sentence clearly states 'Bridge tokens across chains via deBridge DLN' with specific verb and resource. It distinguishes from sibling tools like bridging_bridgeWormhole by naming deBridge, and from status tools by noting it's the submission tool.

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

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

Provides some guidance: 'call the matching status tool after submission' and lists items to confirm before invoking. However, it confusingly says 'through Wormhole or deBridge' while the tool is specifically deBridge, and includes a long irrelevant paragraph about SAP agent registration.

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

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

The description claims this is a read operation ('operation class read', 'check status'), but annotations include 'destructiveHint: true', which directly contradicts. This misleads the agent about side effects, violating transparency.

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

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

Three sentences, each serving a distinct purpose: purpose statement, context, and usage guidance. No redundant or wasted words.

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

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

Given that an output schema exists, the description does not need to explain return values. It covers what and when to call, and what to do with the result. Minor missing details like error handling, but acceptable for a simple status check.

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

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

Schema coverage is 100% with the parameter description already stating 'deBridge DLN order ID'. The description adds no new semantic meaning, 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 'Check the status of a deBridge DLN cross-chain transfer', specifying the protocol (deBridge) and bridge type (DLN). It distinguishes from siblings like bridging_bridgeWormholeStatus by mentioning the specific bridge. The purpose is explicit and unambiguous.

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

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

The description explicitly says 'Call this after bridging_bridgeDeBridge' and instructs to 'keep the resulting status with the user-facing bridge audit trail', providing clear sequencing and output handling. It does not explicitly mention when not to use or alternatives for other bridges, but the context is sufficient.

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 destructive write (destructiveHint=true). The description adds useful context: confirms it is a write operation, advises confirming details before invoking, and mentions calling the status tool afterward. No contradiction with annotations, and the extra workflow steps enhance transparency.

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

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

The description is longer than necessary, mixing purpose, context, guidelines, and an SAP workflow. Some information is repeated (e.g., 'Bridge tokens...' and 'Use for cross-chain asset movement'). The first sentence clearly states purpose, but overall structure could be more concise and better organized.

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 covers purpose, supported chains, usage guidelines, and a specific SAP workflow. However, it lacks details about the output schema (which exists) and does not clarify the ambiguity between Wormhole and deBridge. Given the complexity of cross-chain bridging, more context about return values and potential risks would improve completeness.

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

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

Schema description coverage is 100%, so the schema already explains all parameters. The description lists parameter names in a sentence ('source chain, destination chain, token mint...') but does not add any new semantics beyond what is in the schema. Baseline 3 is appropriate.

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

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

The description clearly states it bridges tokens across chains via Wormhole, supporting Solana to EVM chains. However, it ambiguously mentions 'or deBridge' which could cause confusion with the sibling tool bridging_bridgeDeBridge. The verb and resource are specific, but the inclusion of deBridge slightly undermines clarity.

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

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

The description provides usage guidance: use for cross-chain asset movement, confirm parameters before invocation, call status tool after submission, and follow SAP agent registration workflow if applicable. However, it does not explicitly differentiate from sibling bridge tools or state when not to use this tool, leaving some ambiguity.

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

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

The description indicates a read operation ('Check the status'), but annotations set destructiveHint=true and readOnlyHint=false, which is contradictory. The description does not disclose behavioral traits that explain or align with these annotations, and the contradiction is misleading for the agent.

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

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

The description is concise (4 sentences), front-loaded with the purpose, and includes context (SAP MCP class), usage flow, and audit trail instruction. 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?

Given the tool has an output schema (coverage of return values), the description is complete: it explains the purpose, usage flow, and audit trail context. No gaps for a simple status check 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 coverage is 100%, and the description only restates the schema's parameter descriptions (sequence and sourceChain) without adding new meaning. Baseline 3 is appropriate as the schema already handles parameter documentation.

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

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

The description clearly states the tool checks the status of a Wormhole bridge transfer. It uses a specific verb (Check) and resource (status of Wormhole bridge transfer), and distinguishes from sibling bridging tools like bridging_bridgeWormhole (which submits transfers).

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 advises to use this tool after a bridge submission (bridging_bridgeWormhole) and to keep the status with the audit trail. It provides clear usage context, though it does not explicitly mention 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?

The description does not contradict annotations (all readOnly, openWorld, idempotent, non-destructive). It adds basic behavioral context (retrieves price chart data) but does not disclose additional traits like rate limits, data freshness, or return format. With annotations already providing safety profile, the description adds minimal extra 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 relatively concise (4 sentences) and front-loads the core purpose. The second sentence about SAP MCP context is somewhat redundant given the tool name, but overall it is efficient without unnecessary fluff.

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

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

Given that there is an output schema (indicated by 'Has output schema: true'), the description does not need to detail return values. The description covers the purpose, usage context, and advisory note adequately for a simple read tool with well-defined parameters.

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% (all 3 parameters documented with descriptions). The tool description does not add any further parameter meaning beyond what is already in the schema. Baseline of 3 is appropriate.

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

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

The description clearly states 'Get OHLCV (price chart) data from CoinGecko', which is a specific verb and resource. It distinguishes itself from sibling coingecko tools like getTokenPrice and getTokenInfo by focusing on OHLCV data, but it does not explicitly differentiate usage cases.

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

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

The description provides some usage context by stating 'Use for off-chain market data' and 'Use market data as advisory context', but it does not specify when to prefer this tool over siblings like getTokenPrice or getTrending. The advisory note about on-chain authority is helpful but not a direct usage guideline.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the description adds limited behavioral context. It mentions that the data is advisory but does not disclose pagination behavior, rate limits, or authentication needs. The description 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 somewhat verbose with SAP MCP context and a list of various data types that are not all relevant to this tool (e.g., 'token prices, trending assets'). It could be more concise by focusing solely on pools.

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 an output schema exists covering return values, the description does not explain how pagination works (despite a page parameter) or the role of the network parameter. For a simple list tool with a parameter count of 3, this missing guidance reduces completeness.

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

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

Schema coverage is 100%, so parameters are already described. The description does not add any additional meaning or usage guidance beyond the schema, such as how to use the page parameter for pagination or the network parameter.

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

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

The description uses a specific verb ('Get all liquidity pools for a token') and resource ('CoinGecko on-chain DEX tracker'), making the tool's purpose crystal clear. It is easily distinguishable from sibling tools like 'coingecko_getOHLCV' or 'coingecko_getTokenInfo' by name and description.

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 states to use it for off-chain market data and that on-chain data remains authoritative, implying advisory usage. However, it does not explicitly specify when to use this tool over siblings (e.g., when to use pools vs OHLCV), nor does it provide exclusions or alternative tool names.

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, idempotentHint=true, openWorldHint=true, and destructiveHint=false. The description adds context that the data is off-chain market data and advisory only, which is useful beyond the annotations. No contradictions.

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. The first sentence states the purpose, and the second provides usage context and caveats. No unnecessary words or repetition.

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

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

Given the tool's simplicity (one parameter, read-only, external API) and the presence of an output schema, the description adequately covers purpose, usage, and data nature. It could mention the output format briefly, but the output schema fills that gap.

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 only one parameter (tokenId) with 100% description coverage. The description does not elaborate on the parameter beyond the schema, but the schema is sufficient. Baseline 3 applies.

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

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

The description clearly states the action 'Get detailed token information from CoinGecko' and specifies the content (description, links, market data). It distinguishes from sibling tools like coingecko_getTokenPrice and coingecko_getOHLCV by indicating it provides broader information.

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

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

The description tells when to use it: 'Use for off-chain market data such as token prices, trending assets, token info, pools, and OHLCV.' It also provides a caveat: 'On-chain SAP settlement and escrow state remain authoritative for payments.' It doesn't explicitly state when not to use it, but the use case is clear.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, etc. The description adds context about advisory vs authoritative and mentions CoinGecko source, but does not disclose additional behavioral traits 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?

Three sentences front-load purpose and add context without redundancy. Could be slightly more concise by removing the SAP MCP line if not needed, but overall efficient.

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

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

Given the tool has an output schema, the description adequately explains what the tool returns (price and market data). It sets expectations about advisory nature and constraints on payment authority.

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

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

Schema coverage is 100%, so baseline is 3. The description does not add meaning to individual parameters; schema descriptions are minimal and tautological ('Include24h Change parameter...').

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

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

The description states 'Get token price and market data from CoinGecko' with a specific verb and resource. It lists example data types but these overlap with sibling tools (e.g., coingecko_getOHLCV, coingecko_getTokenInfo), so differentiation is not 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?

The description provides context: use for off-chain market data as advisory, with on-chain state authoritative. However, it does not specify when not to use this tool versus specific siblings for OHLCV, pools, or token info.

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, openWorldHint, idempotentHint, and destructiveHint. The description adds behavioral context by stating the tool provides advisory data and is part of SAP MCP context, which goes beyond the annotations without contradicting them.

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

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

The description is three sentences long, with the first sentence stating the core purpose, the second providing SAP MCP context, and the third giving usage guidelines. It is efficient and front-loaded, with no wasted words.

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

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

Given the tool's simplicity (only two parameters, with one enumerated), the presence of an output schema, and comprehensive annotations, the description is sufficiently complete. It explains the tool's role and the advisory nature of the data, covering the necessary context.

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

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

The input schema has 100% description coverage for both parameters ('duration' and 'vsCurrency'), so the schema already documents them. The description does not add any additional meaning or details about parameter usage, meeting the baseline expectation.

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 top gainers and losers from CoinGecko' and provides context about off-chain market data. However, it does not explicitly differentiate from sibling CoinGecko tools like coingecko_getOHLCV or coingecko_getTrending, which could lead to confusion.

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 explains when to use this tool (for off-chain market data such as token prices, trending assets, etc.) and emphasizes that market data is advisory, with on-chain state being authoritative. This provides clear context, though it lacks explicit exclusion of 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. The description adds useful behavioral context: data is off-chain and advisory, not authoritative for payments. No contradictions.

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: one functional, one contextual. Concise and front-loaded, though the contextual sentence could be more specific.

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 parameters and an output schema, the description covers the basics. Misses details like time frame of trending data, but overall adequate.

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

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

No parameters exist, and schema coverage is 100%. The description does not add parameter semantics, which is acceptable given no parameters.

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

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

The description clearly states the tool retrieves trending tokens and NFTs on CoinGecko. However, it also lists broader use cases like token prices and OHLCV, which could cause confusion with 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?

No explicit guidance on when to use this tool versus alternatives like coingecko_getTokenPrice or coingecko_getOHLCV. The advisory context note is generic and not specific to this tool.

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

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

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds context about the DAS protocol and read operation, which is consistent and adds some value beyond annotations.

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

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

The description is concise but includes a misleading sentence that could confuse agents. It is front-loaded with the purpose but the unnecessary guidance on usage detracts from conciseness.

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 tool is simple with one parameter and an output schema, the description fails to clearly differentiate when to use this tool versus other DAS read tools. The misleading usage suggestion indicates incompleteness.

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 'id' parameter described as 'Asset mint address'. The description does not add additional meaning or context beyond what the schema already provides.

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

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

The description clearly states it gets detailed information about a single NFT/asset via DAS, with a specific verb and resource. It distinguishes from sibling tools like das_getAssetsByOwner and das_searchAssets by focusing on a single asset.

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 says to use for discovery by owner, creator, collection, or search query, which is misleading because this tool fetches by ID, not those filters. It does offer good guidance on preferring DAS reads before Metaplex writes, but the inaccurate usage suggestion reduces clarity.

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, openWorldHint, idempotentHint, and destructiveHint. The description adds 'operation class read' and 'read-only', which reinforce but do not significantly extend beyond annotations. No behavioral contradictions or new insights like pagination behavior or error handling are provided.

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

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

The description is concise, with two sentences that directly state purpose and usage advice. It is front-loaded with the core action and avoids unnecessary details.

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

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

Given the simple parameter set (page, limit, collectionAddress) and the presence of an output schema and annotations, the description provides adequate context. It covers the basic use case and advises on when to prefer DAS reads over Metaplex writes. Minor gaps in error scenarios or edge cases are acceptable for a tool of this complexity.

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

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

The input schema has 100% coverage, so the description adds little to parameter semantics. The description does not explain the purpose of page and limit beyond what the schema provides, nor does it clarify that collectionAddress is the NFT mint address (already in schema). Baseline 3 is appropriate.

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

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

The description clearly states the verb 'Get' and the resource 'all NFTs in a collection via DAS', which is specific and distinguishes it from sibling tools like das_getAsset (single asset), das_getAssetsByOwner, and das_getAssetsByCreator. The mention of 'collection' aligns with the tool name and parameter.

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 advises using DAS reads before Metaplex writes for validation, which suggests a when-to-use scenario. However, it does not explicitly state when not to use this tool or compare it directly with other DAS read tools like das_searchAssets, leaving some ambiguity about selection criteria.

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

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

The description reinforces the read-only, non-destructive nature already indicated by annotations (readOnlyHint, destructiveHint). It adds strategic context about preferring DAS reads over Metaplex writes, which is helpful for agent decision-making. 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?

The description is concise (three sentences) and front-loaded with the core action. Every sentence adds value: main function, protocol context, and usage guidance. No redundant or filler content.

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

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

Given the tool's simplicity (4 parameters, output schema present), the description adequately covers purpose, usage, and protocol. It could mention that the response is a list of assets, but the presence of an output schema mitigates this need.

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 descriptions for all parameters. The description adds no additional parameter-level details beyond what the schema provides, so it meets the baseline for this dimension.

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 retrieves all NFTs/assets created by a specific creator via DAS, using a specific verb ('Get') and resource ('Assets By Creator'). It distinguishes from sibling DAS tools (e.g., das_getAssetsByOwner, das_getAssetsByCollection) by explicitly limiting the query to a creator address.

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 usage context: it is for read-only DAS NFT and asset discovery by various criteria, and it advises preferring DAS reads before Metaplex writes when validating existing assets. However, it does not explicitly list alternative tools or state when not to use this tool.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. Description adds context like 'Protocol das; operation class read' and 'supports pagination', enhancing transparency without contradiction.

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

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

Four sentences, front-loaded with purpose. Could be slightly tighter by removing redundant usage guidance (third sentence partially repeats first). Still concise overall.

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?

Output schema exists, so return values are covered. Description covers purpose, protocol, pagination, and usage context. Missing details like sorting options are covered by schema. Sufficient for an agent to select and invoke.

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

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

Schema coverage is 100%, so baseline is 3. Description mentions 'supports pagination', which groups pagination parameters, but does not add meaning beyond schema details for individual 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?

Clearly states 'Get all NFTs/assets owned by a wallet via DAS (supports pagination)', with specific verb and resource. Distinguishes from sibling tools like das_getAsset (single asset), das_getAssetsByCreator, etc.

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

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

Provides usage context: 'Use for read-only DAS NFT and asset discovery' and 'Prefer DAS reads before Metaplex writes'. However, the sentence 'by owner, creator, collection, or search query' is misleading as this tool is specifically by owner, not the other criteria covered by siblings.

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

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

Annotations already provide readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds 'SAP MCP context: Protocol das; operation class read' and mentions 'flexible filters', but does not significantly expand on behavioral traits beyond the annotations. No contradiction.

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

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

Three concise sentences that front-load the core purpose, add context, and give usage preference. No redundant or unnecessary 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?

Given the high schema coverage, full annotations, and presence of an output schema, the description adds sufficient context (use cases, preference over writes) to make the tool easy to select and invoke. Minor omission: pagination or filter combination details are not mentioned, but these are covered by the schema.

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

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

Schema covers all 9 parameters with individual descriptions (100% coverage). The description does not elaborate on parameter meanings or provide usage examples beyond what the schema already states. Thus, it meets the baseline expectation but adds minimal 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 'Search NFTs/assets with flexible filters via DAS' and lists specific filter dimensions (owner, creator, collection, search query). It distinguishes from sibling tools like Metaplex writes by advising to prefer DAS reads first. The verb-resource pair is specific and unambiguous.

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

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

Description explicitly says 'Use for read-only DAS NFT and asset discovery' and advises to 'Prefer DAS reads before Metaplex writes when validating existing assets'. This provides clear context and some guidance on alternative tools, though more detail on when not to use (e.g., for writes) would strengthen it further.

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 it is not read-only, not destructive, not idempotent, but description adds no further behavioral context such as risk of liquidation, effect on collateral, or state changes. Minimal beyond the basic action.

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

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

The first sentence is front-loaded and clear, but the second paragraph about SAP MCP context is tangential and not directly useful for tool invocation. Could be more focused.

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 an output schema, the description lacks context about prerequisites, protocol mechanics, and edge cases. For a complex DeFi action like borrowing, more completeness is expected.

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. Description does not add additional meaning beyond the schema, 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 action 'borrow tokens on Drift against deposited collateral'. It uses a specific verb and resource, and distinguishes from sibling tools like drift_deposit and drift_lend.

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

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

No guidance on when to use this tool vs alternatives like drift_lend or drift_openPerpPosition. No prerequisites mentioned (e.g., need deposited collateral first). The SAP context paragraph does not provide usage guidelines for borrowing.

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

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

Annotations already indicate destructiveHint=true, but the description adds no behavioral details beyond that. No mention of settlement, fees, prerequisites, or effects.

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

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

The first sentence is concise, but the second sentence about SAP context is unnecessary for tool invocation, diluting conciseness.

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 output schema, the description still lacks usage guidelines and behavioral transparency, making it incomplete for effective tool use.

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

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

Schema coverage is 100% with descriptions for all parameters, so baseline is 3. The description adds no extra parameter meaning beyond what the schema already provides.

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

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

The description clearly states the verb 'Close' and resource 'a perpetual position on Drift', which is specific. However, it does not differentiate from sibling tools like drift_openPerpPosition, so it lacks sibling distinction.

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

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

The description provides no guidance on when to use this tool vs alternatives. It only includes irrelevant SAP context about registering the tool, not actual usage conditions.

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

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

The description only states 'deposit tokens' without elaborating on side effects, prerequisites, or post-conditions. Annotations indicate it is a write operation (readOnlyHint=false) but the description adds no further behavioral context beyond the basic action.

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

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

The first sentence is concise and clear. The second sentence about SAP MCP context is extraneous and adds clutter without direct relevance to the tool's operation. Removing it would improve conciseness.

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 covers basic purpose but omits important details such as the return format (though output schema exists), the meaning of subAccountId, and whether a Drift account is automatically created. The SAP context does not contribute to completeness.

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

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

Schema coverage is 100% and the description does not add additional meaning beyond what the schema already provides. The parameter descriptions in the schema are adequate, so the description adds minimal value here.

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

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

The description clearly states the tool's action (deposit tokens) and the target resource (Drift account) and the purpose (trading or lending). This distinguishes it from sibling tools like drift_withdraw and drift_openPerpPosition.

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 includes unrelated SAP MCP context that does not help with usage decisions. A clear 'when to use' statement is missing.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the description's burden is lower. It adds no behavioral details beyond stating it gets positions and account info, which is consistent but not enriching.

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 short (two sentences) but includes a second sentence about SAP MCP context that may be tangential for core usage. It is not overly verbose, but the extra context could be placed elsewhere.

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

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

Given the tool's simplicity (2 parameters, rich annotations, output schema exists), the description is adequate. It covers the main purpose, and the output schema handles return values. Missing edge cases or error info, but acceptable for a read-only tool.

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

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

The input schema has 100% coverage with descriptions for both parameters. The description does not add any further parameter-specific meaning beyond what the schema already provides, so 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 'Get all open positions and account info for a Drift account,' using a specific verb and resource. It effectively conveys the tool's function, though it does not explicitly differentiate from sibling tools like lulo_getPositions or adrena_getPositions, which are for other protocols.

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 includes context about SAP MCP but does not specify prerequisites, when to avoid, or mention alternative tools for similar data.

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 a write operation (readOnlyHint=false) and non-idempotence. The description adds no further behavioral context, such as token lock-up periods, interest accrual details, or approval requirements, which are relevant for an agent invoking the tool.

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

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

The core purpose is stated in a single sentence. The additional SAP MCP sentence is secondary but not clearly separated. Overall concise, but could be more focused.

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

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

Given the tool's complexity (4 params, multiple siblings, output schema exists), the description lacks usage guidelines and behavioral details. While schema explains parameters and output schema covers returns, an agent needs more context to appropriately select and invoke this tool over similar ones.

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 covers 100% of parameters with descriptions. The description does not add meaning beyond schema, such as clarifying units or constraints. Baseline 3 is appropriate as schema does the work.

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

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

The description clearly states the tool's action ('Lend tokens on Drift') and outcome ('to earn interest'), which is a specific verb-resource pair. The tool name 'drift_lend' and sibling tools like 'drift_deposit' and 'drift_borrow' indicate distinct functions, but the description itself is unambiguous.

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

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

No guidance on when to use this tool versus alternatives like drift_deposit or drift_borrow. The SAP MCP context mentions unrelated registration tools but does not help an agent decide between this and other DeFi actions.

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

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

Annotations indicate a non-readonly, non-destructive mutation. The description adds no behavioral context beyond the schema, such as on-chain state changes, fees, or execution risks.

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, the first is concise. The second includes tangential SAP context, adding some bulk. Overall efficient but could drop the SAP part for clarity.

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

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

With 9 parameters and a trading context, the description is minimal. It lacks trading details like leverage limits, order types, or how to close the position. The output schema may help, but the description itself is incomplete.

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

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

Schema coverage is 100%, so baseline is 3. The description does not add any parameter meaning beyond schema descriptions, which already cover the parameters adequately.

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

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

The description clearly states 'Open a perpetual futures position on Drift', specifying the verb, resource, and platform. It distinguishes from siblings like drift_closePerpPosition and drift_getPositions.

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

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

No guidance on when to use this tool vs alternatives. The SAP context is about registration, not usage. No mention of prerequisites like wallet balance or margin requirements.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds no further behavioral traits beyond the first sentence. No contradiction, but 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 two sentences: the first is highly concise and clear; the second provides relevant SAP context. Effective 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?

Output schema exists, so no need to explain return values. Full parameter docs in schema. However, lacks guidance on when to use this tool relative to other Drift operations, which reduces completeness.

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

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

Schema coverage is 100% with descriptions for all four parameters. The description does not add meaning beyond the schema, so 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 'withdraw' and resource 'tokens from a Drift account.' It distinguishes from siblings like drift_deposit, drift_lend, etc., by specifying the action and target.

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

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

The description includes SAP MCP context but does not provide explicit when-to-use or when-not-to-use guidance for this tool versus alternatives. No exclusions or prerequisites are mentioned.

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

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

Annotations show readOnlyHint=false, destructiveHint=false, idempotentHint=false. Description adds 'on-chain escrow' and warns about confirmation before writes, which enriches the behavioral context beyond annotations. However, it does not mention transaction costs or failure modes.

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

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

Description has two sentences that serve purpose but include some redundancy (e.g., 'SAP MCP context') and could be more tightly worded. The second sentence is a bit fragmented.

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

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

Given the tool's complexity (7 params, on-chain write, output schema exists), description covers confirmation and post-completion steps but lacks details on on-chain costs, escrow mechanics, and prerequisites. Adequate but not thorough.

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

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

Schema description coverage is 100%, so baseline is 3. Description does not add new parameter-level meaning beyond what the schema already provides; mentions concepts like 'scope, payout, recipient' but those are not explicit 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?

Description clearly states 'Create a new bounty on Gib Work with on-chain escrow', providing a specific verb and resource. It distinguishes from sibling tools like gibwork_listBounties and gibwork_submitWork.

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 says 'Use for bounty creation, listing, and work submission' and advises to 'Confirm scope, payout, recipient, and deliverable evidence before writes'. It also suggests using SAP tools for reputation after completion, providing context but no explicit when-not-to-use or alternatives.

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

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

Description contradicts annotations: annotations set readOnlyHint=true, but description says 'operation class write' and 'Use for bounty creation' implying write behavior. This is a serious inconsistency.

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 has two sentences, but the second is a long run-on that mixes unrelated guidance, reducing clarity. Could be more 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?

With an output schema present, the description fails to explain what the tool returns (list of bounties) or any notable behavior. The SAP context is confusing and unnecessary for understanding the 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 descriptions for parameters are tautological (e.g., 'Tags parameter for Gibwork List Bounties') and add no real meaning. The tool description does not provide any additional parameter guidance 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?

First sentence clearly states 'List available bounties on Gib Work,' but the following sentence muddles purpose by claiming 'Use for bounty creation, listing, and work submission,' which incorrectly attributes write operations to a read-only tool.

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

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

No explicit guidance on when to use this tool vs sibling tools like gibwork_createBounty or gibwork_submitWork. The mention of 'SAP attestation or feedback tools after work completion' is vague and not directly helpful for selecting this tool.

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

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

Annotations already indicate destructiveHint=true and readOnlyHint=false, signaling a write operation. The description adds caution to confirm details before writing, aligning with annotations. It does not contradict annotations, but it adds limited new behavioral context 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 four sentences: clear verb+resource, SAP MCP context, usage guidance, and follow-up suggestion. The second sentence about SAP MCP context is redundant with annotations but not excessive. The description is mostly 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?

The tool is simple (submit work with wallet, bountyId, submissionUrl, notes). The description does not explain what happens on success/failure or handle invalid inputs. However, an output schema exists (as per context signals), so return values are documented elsewhere. The description is adequate but could be more complete.

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

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

Schema coverage is 100%, and each parameter has a description in the schema (e.g., wallet: 'Solana public key (base58)'). The description adds little beyond the schema; it mentions 'Confirm scope, payout, recipient, and deliverable evidence' but does not map these to parameters. Baseline 3 is appropriate given high coverage.

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

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

The description clearly states 'Submit completed work for a Gib Work bounty,' specifying verb and resource. It distinguishes from sibling tools like gibwork_createBounty by focusing on submission. However, it also mentions 'Use for bounty creation, listing, and work submission,' which broadens the scope unnecessarily, reducing clarity slightly.

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 advises confirming scope, payout, recipient, and deliverable before writes, and suggests using SAP attestation or feedback tools after completion for reputation recording. It does not explicitly state when not to use this tool or compare with alternatives, but it provides some context for usage.

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, idempotentHint=true, and destructiveHint=false. The description adds no new behavioral context beyond the title, such as response format or API requirements. This is adequate but not enriching.

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 first sentence is concise, but the second sentence about SAP tools is tangential and detracts from the tool's simplicity. It could be omitted without loss of 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?

Given the tool is a simple read-only query with an output schema, the description is minimally adequate. However, it lacks context such as typical use after bundle submission or how to interpret the status.

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

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

Schema coverage is 100%, so the baseline is 3. The description does not add any extra meaning about the bundleId parameter beyond what the schema provides (e.g., format, length, or example).

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 states 'Check the status of a submitted Jito bundle,' using a specific verb and resource. It clearly distinguishes from sibling tools like jito_sendBundle and jito_getTipEstimate.

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 given on when to use this tool versus alternatives. It does not mention that it should be called after jito_sendBundle or for polling bundle status. The SAP context sentence is irrelevant to usage.

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