SAP MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.9.16
Disambiguation4/5
Tool names are prefixed by protocol, which largely separates domains. Within a protocol like Jupiter, multiple swap-related tools exist (smartSwap, swap, swapInstructions) but their descriptions clarify distinct use cases. Some overlap remains between sap_ staking and external staking tools, but descriptions draw clear boundaries.
Naming Consistency4/5
The verb_noun pattern with protocol prefix is used throughout (e.g., coingecko_getTokenPrice, jupiter_executeOrder). Minor inconsistencies: hyphens vs underscores (metaplex-nft vs raydium-pools) and a few sap_ tools deviate from verb_noun (e.g., sap_fairscale_score). Overall predictable.
Tool Count1/5
With 269 tools, the server bundles an entire Solana ecosystem into one MCP. This far exceeds typical scopes (3-15). While each tool serves a purpose, the sheer volume makes it unwieldy for agents to navigate and find relevant tools.
Completeness4/5
Each protocol's tool set is generally well-covered: Jupiter has quotes, swaps, DCA, limit orders; SAP protocol covers registration, escrow, chat, memory, SNS, etc. Minor gaps exist (e.g., send-arcade lacks cancel game, some protocols have only basic operations), but overall the surface is comprehensive.
Average 3.7/5 across 269 of 269 tools scored. Lowest: 2/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 314 commits in the last 12 weeks
- Last stable release on August 18, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
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.
Conciseness3/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose3/5
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.
Usage Guidelines2/5
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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description contradicts annotations: it says 'operation class write' but annotations set readOnlyHint=true. This is a serious inconsistency. No additional behavioral context is provided beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is not concise; it includes extraneous information about SAP MCP context, operation class, and parameter aliases that are irrelevant or contradictory. The important core statement is front-loaded but diluted by unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with no parameters and an output schema, the description briefly mentions output (balances and metadata) but lacks details on pagination, rate limits, or data format. The contradictory claims undermine completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, but the description mentions parameter aliases (owner, address, pubkey) without explaining how they are used. This creates confusion as there are no parameters to alias. The description does not add meaningful semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The main sentence clearly states the tool lists SPL token accounts with balances and metadata. However, the description also includes misleading statements like 'operation class write' and suggests it should be used for deploy, mint, transfer, etc., which are not this tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes vague usage guidance like 'Use token tools alongside SAP payments...' but does not specify when to use this tool versus alternatives or provide explicit when-not conditions. It misleadingly suggests using it for write operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false, so the description correctly implies mutation. However, it adds no behavioral details such as token requirements, pool initialization effects, or idempotency. The description carries minimal value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The first sentence is concise, but the second sentence about SAP context is irrelevant to the tool's operation and adds clutter. The description is not well-structured for an agent to quickly understand usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 9 parameters and an output schema, the description fails to explain what a Dynamic Pool is, how to obtain parameter values, or what the return is. The SAP context sentence is extraneous and does not complete the picture. The description is incomplete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter already described. The description does not add any extra meaning, relationships, or usage patterns beyond the schema. Baseline score of 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create a Meteora Dynamic AMM pool', which is a clear verb and resource, but it does not differentiate from sibling tools like meteora_createDLMMPool or meteora_createAlphaVault. The title already indicates the pool type, but the description lacks specifics on what makes 'Dynamic' distinct, leaving ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., when to create a Dynamic vs DLMM Pool). It does not mention prerequisites, conditions, or when-not to use. The SAP context paragraph is about unrelated tools, not usage instructions for this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'Get' implying a read operation, but annotations set readOnlyHint=false, contradicting that. No additional behavioral details (e.g., side effects, idempotency) are disclosed beyond the annotation contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but lacks structure. It front-loads the purpose but could be more informative without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and 5 parameters, the description is too brief. It does not explain what the status represents or how to interpret the output, leaving the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 5 parameters with descriptions (100% coverage), so the description adds no extra meaning. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 'backing SAP memory session status for a chat room', using a specific verb and resource. It distinguishes from sibling chat tools like 'sap_chat_read_all' or 'sap_chat_start_room' by focusing on session status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., 'sap_session_status' or other chat tools). The description lacks context about prerequisites or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description discloses that the tool is currently unavailable and rejects before payment, adding behavioral context beyond annotations (readOnlyHint=false, etc.).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is brief but focuses on unavailability rather than tool function, making it under-specified for the intended purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present, description fails to explain what the tool returns or its intended operation when available, leaving gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions; description does not add further parameter meaning, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description mentions 'setting primary domain' but focuses on unavailability, not a clear statement of what the tool does when functional. No differentiation from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool. Mentions alternative (Bonfida CLI) but does not specify context for using this tool itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and destructiveHint=false, but the description claims 'operation class write' which directly contradicts the read-only intent. No additional behavioral context is provided beyond the contradictory statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The first sentence is concise, but the following sentences introduce irrelevant warnings about writes and SAP context, bloating the description without earning their place for a list tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and an output schema. The description covers the basic purpose but includes misleading write warnings and omits clarity on parameter usage or return format. Output schema mitigates some gaps, but the description could be more coherent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the single parameter (status) with 100% description coverage via enum values. The description adds no extra meaning about the parameter, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'List available games on Send Arcade' which clearly identifies the action. However, it also includes unrelated SAP MCP context warnings that slightly obscure the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Use for Send Arcade game listing and play flows' but provides no distinction from the sibling tool send-arcade_playGame. It gives warnings about writes that are irrelevant to this read-only tool, offering no practical when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description contradicts annotations: burning implies destruction, but destructiveHint=false. Additionally, no disclosure of irreversibility or need for authority. The 'operation class write' adds no new info 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is somewhat wordy with irrelevant SAP MCP context and a list of operations. It could be more concise by focusing on the burn operation and its specific requirements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Missing critical context: irreversibility, authority delegation, requirement for the owner to have a token account, and the need for signing. Although output schema exists, the description should warn about the destructive nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 3 parameters with brief descriptions. The description adds a generic warning about confirming values but no specific parameter-level details (e.g., amount in base units). Schema coverage is 100%, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Burn SPL tokens') and the resource ('owner's token account'). However, it does not explicitly differentiate from sibling tools like spl-token_transfer or spl-token_freezeAccount, though the name 'burn' is specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description lists multiple SPL operations but does not indicate when burning is appropriate or what prerequisites exist (e.g., owner must have token account).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'Check' implying a read-only query, but annotations set readOnlyHint=false, suggesting the tool may perform a write or have side effects. This is a clear contradiction. Additionally, the description does not explain what 'check' entails beyond the return value, nor does it clarify the 'ephemeral RPC' term or any potential state changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence. It is well-structured and gets straight to the point. However, it could potentially be improved by adding a brief note on what the tool does not do (e.g., 'This does not modify state'), but overall it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the contradiction between the description and annotations, and the lack of clarification about the 'ephemeral RPC' concept, the description is incomplete. The existence of an output schema is noted but does not compensate for the misleading behavioral signal. A more complete description would explain the check's implications and resolve the annotation inconsistency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all three parameters (mint, cluster, validator). The description does not add extra meaning or context beyond the schema. Since schema coverage is high, a baseline score of 3 is appropriate. No additional parameter insights are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: checking whether a mint has a validator-scoped transfer queue. The verb 'Check' and the specific resource ('mint' and its queue) are well defined. However, it does not explicitly distinguish this from other magicblock tools, such as 'magicblock_getDelegationStatus' or 'magicblock_balance', which could have similar checking semantics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 instead of alternatives. It does not mention prerequisites, typical use cases, or related tools. For example, there is no advice like 'Use this before initializing a mint' or 'This is only relevant for certain mints.' This lack of contextual usage hints reduces its helpfulness for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, so the description's statement 'Cancel a limit order' adds no extra behavioral context. It does not disclose effects like order removal, refunds, or potential partial fills, which are critical for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The first sentence is concise, but the second sentence is lengthy and irrelevant to the tool's function, making it inefficient. Every sentence should earn its place; the second does not help the agent use this tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 information on success/failure indicators, error conditions, or prerequisites. The SAP context is not useful for understanding this cancellation tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all three parameters with descriptions (100% coverage). The description does not add parameter semantics beyond what the schema already provides, meeting the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence clearly states the tool cancels a limit order on a Manifest market, which distinguishes it from sibling cancel tools like openbook_cancelOrder. However, the long second sentence about SAP MCP context is confusing and does not aid purpose clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs. alternatives. The description mentions related sap_ tools but does not explain when to cancel an order or what prerequisites are needed (e.g., wallet balance, order existence).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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.
Conciseness3/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness3/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds no behavioral context beyond 'withdraw,' such as side effects or requirements. Lacks detail on what happens to the position.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but includes an irrelevant SAP context sentence that detracts from conciseness. Could be streamlined to focus on the tool's core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive action with no output schema, the description is too minimal. It does not explain constraints (e.g., must have existing position, available balance) or the effect on the user's wallet.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 3 parameters with descriptions (wallet, mint, amount). The description does not add any additional meaning beyond 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Withdraw from Lulo lending position,' specifying the verb (withdraw) and resource (Lulo lending position). It distinguishes from sibling tools like lulo_deposit but could be more explicit about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 lulo_deposit or lulo_getPositions. The SAP context note is generic and does not help with tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, so the tool is a mutation. The description adds no behavioral details beyond that, such as side effects (e.g., funds locked, order book state changes) or requirements (e.g., approval, gas fees).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (two sentences), but the second sentence introduces tangential SAP context that may distract from the core function. It could be more focused on the tool's primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a trading tool with 6 parameters and an output schema, the description is minimal. It does not explain typical usage flow, prerequisites (e.g., sufficient balance), or results (e.g., order placement confirmation).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing basic parameter descriptions. The main description adds no extra meaning to parameters, so it meets the baseline of 3 but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Place an order on an Openbook market,' which specifies the action and resource. However, it does not differentiate from sibling tools like openbook_cancelOrder or other trading tools, so it loses some points.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a note about using SAP registration tools when needed, but it provides no guidance on when to use this tool versus alternatives like jupiter_swap or raydium-pools. No explicit context for appropriate use is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, so the description adds no additional behavioral insight. It does not disclose what happens during the swap, token balances, or potential risks, missing an opportunity to provide context beyond the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description has two short sentences and a longer paragraph about SAP integration. The first sentence is concise, but the second paragraph is tangentially related and increases length without directly aiding swap usage, making it less concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 essential context such as prerequisites (e.g., SOL for fees, token accounts), the nature of Whirlpool swaps (exact input/output), and the irreversible nature highlighted by destructiveHint=true. This gap reduces completeness for a complex DeFi operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions, so baseline is 3. The description adds no further meaning or examples for 'slippageBps' or 'isExactInput,' relying entirely on the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Swap tokens on an Orca Whirlpool,' clearly identifying the verb (swap) and resource (Orca Whirlpool). However, it does not differentiate from other swap tools like jupiter_swap or magicblock_swap, which are listed as siblings, limiting its distinctiveness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, but this does not guide when to use this swap tool versus alternatives (e.g., jupiter_swap). It offers no criteria for selection, prerequisites, or situational advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set readOnlyHint=false and openWorldHint=true, so the description adds minimal behavioral detail. It does not explain the bonding curve mechanics, potential slippage, or side effects beyond 'buy or sell'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but includes an unrelated SAP context sentence that could be moved to a separate field. It is not optimally concise for a tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a trading tool with an output schema, the description fails to explain return values, confirmation steps, or how the bonding curve executes. The SAP note is irrelevant to invocation completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage, so the description adds no extra meaning. The description does not clarify the 'slippageBps' parameter's odd 'pagination control' phrasing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it buys or sells tokens on Pump.fun bonding curve, distinguishing it from other trading tools. However, the SAP MCP context note is tangential and may distract from the primary purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks guidance on when to use this tool versus alternatives like Jupiter or Raydium swaps. It only mentions SAP registration flow, not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral details beyond the annotations, which already declare destructiveHint=true and readOnlyHint=false. It does not disclose potential consequences (e.g., loss of liquidity position, fees, slippage), required permissions, or side effects. The minimal text fails to enrich the agent's understanding of the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) but the second sentence introduces unrelated SAP context that may distract or confuse the agent. The core purpose is front-loaded, but the extraneous detail reduces efficiency. It could be more focused on the tool's operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, optional fields like lpAmount, percentage, positionNft) and the existence of an output schema, the description lacks important context. It does not explain parameter interdependencies (e.g., either lpAmount or percentage may be required) or mention return values. Missing guidance on prerequisites (e.g., need to have liquidity tokens).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with each parameter clearly described (e.g., 'Solana public key (base58)', 'Raw token amount (smallest unit)'). The tool description does not add additional meaning beyond the schema, making the score at baseline. The schema itself provides adequate semantic clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove liquidity from a Raydium pool') with a specific verb and resource. However, it does not differentiate from sibling tools like raydium-pools_addLiquidity or other Raydium pool management tools, which would require an agent to infer the distinction from the name alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., addLiquidity, createCPMM). The SAP MCP context note is about unrelated tools for agent registration and does not help in deciding when to perform liquidity removal. No explicit when/when-not or prerequisite conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description indicates a write operation but does not disclose behavioral traits beyond annotations. No mention of balance changes, fees, or authorization requirements. Annotations already provide safety profile, so additional context is limited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is verbose with generic SAP context that does not aid the agent. The first sentence is clear, but subsequent sentences are irrelevant and not concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple native SOL transfer, the description is adequate but lacks details on system program usage and return value. Output schema exists, so return value explanation is not required, but additional context could improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers all parameters with descriptions (100% coverage). Description adds no meaning beyond schema, meeting baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it transfers native SOL between wallets via SystemProgram.transfer, which is specific. However, it includes irrelevant text about SPL token operations, diluting clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. The description mentions SPL token operations, which is misleading for a SOL transfer tool. Sibling tools like spl-token_transfer exist but are not differentiated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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.
Conciseness3/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation ('check'), but annotations set readOnlyHint=false, creating a contradiction. Beyond that, no additional behavioral details (e.g., side effects, rate limits) 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The first sentence is concise and clear, but the second sentence about SAP MCP context is generic boilerplate that adds length without direct value for this tool. Slightly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter check tool, the description is minimally adequate. It does not mention output format, but since an output schema exists (as per context), that gap is mitigated. Still, overlapping sibling tools like spl-token_rugCheck are not addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the 'mints' parameter well. The tool description adds no extra meaning beyond what the schema provides. With 100% schema coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks token mints for security risks (honeypot, freeze authority, low liquidity). It specifies verb (check) and resource (token mints), making the purpose clear. However, it does not differentiate from the similar sibling spl-token_rugCheck.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes generic SAP MCP context about Jupiter tools but does not provide specific guidance on when to use this tool versus alternatives like spl-token_rugCheck, or conditions for use (e.g., pre-swap safety check). Usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate write (readOnlyHint=false) and non-destructive behavior. The description adds 'Create' but does not disclose any additional behavioral traits such as required permissions, token constraints, or side effects beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences: one for core purpose and one for SAP context. It is front-loaded and efficient, though the second sentence may be less relevant for some users.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 covered. However, the description lacks details on market creation specifics like fees, token compatibility, or prerequisites. The SAP context provides integration guidance but not operational completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all three parameters (creator, baseMint, quoteMint). The description does not add extra meaning beyond what the schema provides, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new Manifest market for a token pair,' specifying the verb (Create) and resource (Manifest market). It distinguishes from siblings like openbook_createMarket via the name prefix, though no explicit differentiation is provided.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 guidance on when to use this tool vs alternatives like OpenBook or other DEX market creation tools. No explicit when-to-use or when-not-to-use conditions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate write, non-destructive, non-idempotent. The description adds 'operation class write' and mentions confirmation before writes, but does not disclose side effects (e.g., whether existing royalties are overwritten or merged). It provides adequate context beyond annotations but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose, including tangential SAP context, agent identity planning, and unrelated workflows. It is not front-loaded; the core purpose is buried. Every sentence does not earn its place, reducing efficiency for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (configure royalties), and an output schema exists. However, the description includes extraneous information and omits specifics about the update process. It is complete enough for basic understanding but lacks focus on the tool's core behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%; each parameter has a clear description. The description adds no new semantic information beyond the schema, only generic prerequisites. Baseline 3 is appropriate as the schema already documents parameters well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Configure royalty fee and creator splits for an NFT', which is a specific verb-resource pairing. It clearly identifies the tool's primary function. While sibling tools exist (e.g., metaplex-nft_updateMetadata), the description does not explicitly differentiate, but the focus on royalties is distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists prerequisites ('Confirm metadata URI...') but does not specify when to use this tool versus alternatives. It mentions 'Use for Metaplex NFT collection, mint, metadata... workflows' which is too broad and does not guide selection. No explicit when-not-to-use or alternative tools are referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is not read-only, not idempotent, and not destructive. The description adds preconditions ('Confirm metadata URI, collection mint, creators, royalties... before writes') and mentions it's a single transaction. However, it does not disclose side effects, such as what happens if the collection is already set, or potential errors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than necessary, with the first sentence providing the core action, but subsequent sentences shift to SAP-specific context and agent registration, which are tangential. The content could be streamlined to focus on the tool's function and parameter usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (content unknown), the description does not explain return values or what constitutes success/failure. It lacks explanation of parameter relationships (e.g., how mint and collection differ) and post-conditions. Given the tool's complexity and sibling tools, the description is insufficient for an agent to reliably select and invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers all 4 parameters with descriptions, but 'mint' and 'collection' have identical descriptions ('NFT mint address (base58)'), causing potential confusion. The description adds context about parameters indirectly (e.g., 'collection mint, creators, royalties') but does not differentiate between the two mints or clarify their roles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's primary function: 'Set and verify a collection on an NFT in a single transaction.' This verb-resource pair is specific and distinguishes it from sibling tools like verifyCollection. However, the extensive mention of SAP MCP context and agent identity workflows dilutes the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides broad usage categories ('Use for Metaplex NFT collection, mint, metadata, royalty, creator verification...') but lacks explicit guidance on when to use this tool versus siblings like verifyCollection or updateMetadata. No exclusion criteria or alternatives are mentioned, leaving the agent to guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a write operation (readOnlyHint=false) and the description mentions 'operation class write', which is consistent. However, it does not detail what on-chain state changes occur (e.g., marking the NFT as verified), potential side effects, or error conditions. The pre-checks list adds some context but lacks specificity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose and includes irrelevant details about SAP MCP context, agent identity planning, and references to other tools. The core purpose is stated in the first sentence, but the rest is cluttered with extraneous information that reduces clarity and focus.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 need not be explained. The description mentions prerequisites like confirming metadata URI and ownership, but does not cover all essential context (e.g., that the collectionAuthority must be the authority of the collection). The tool is part of a large set of siblings, and the description could be more tailored to its specific role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters (mint, collection, collectionAuthority) are described in the input schema with full coverage. The description does not provide additional semantic meaning or usage hints beyond the schema, so it adds no extra value. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Verify an NFT as part of a collection' which clearly states the primary action. However, it does not differentiate from sibling tools like verifyCreator or setAndVerifyCollection, as it lists multiple workflows (collection, mint, metadata, etc.) without distinguishing this tool's specific role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description lists pre-checks (confirm metadata URI, collection mint, etc.) but does not specify conditions for using this tool or when another Metaplex tool would be more appropriate. Sibling tools with similar functions exist without mention.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false (write operation) and destructiveHint=false. The description adds the pool type specifics but omits critical behavioral traits such as the need for token approvals, slippage tolerance, or failure conditions (e.g., if the pool does not exist).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The first sentence is concise, but the second sentence is a lengthy, off-topic paragraph about SAP MCP context and other tools, which dilutes the focus. The description could be shortened to the first sentence alone.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 essential context for a DeFi tool: preconditions (e.g., token approvals, pool existence), error scenarios, or liquidity addition mechanics (e.g., single-sided vs. dual-sided). This leaves significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 elaborate on any parameter beyond what the schema already provides, nor does it clarify usage for the enum-based fixedSide parameter or the optional price range parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a clear statement of the tool's function: 'Add liquidity to a Raydium pool (CPMM, CLMM, or AMM v4).' This directly identifies the verb (add liquidity), resource (Raydium pool), and scope (specific pool types), distinguishing it from sibling tools like ray-dium-pools_removeLiquidity, createCPMM, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives (e.g., other DEXes or liquidity methods). The SAP MCP context paragraph discusses unrelated tools (sap_* SDK tools) and does not clarify usage scenarios for addLiquidity itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate it is not read-only (mutating), not idempotent, not destructive, and open world. The description adds no further behavioral context, such as side effects, permissions, or costs. With annotations, the bar is lower, but the description does not 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The first sentence is concise, but the second sentence about SAP MCP context is tangential and reduces focus. It could be shorter without the irrelevant guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and six parameters, the description is minimal. It does not explain the constant product formula, the role of each parameter in pool creation, or expected behavior. The context is insufficient for an agent to confidently use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 adds no additional meaning beyond the schema, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a Raydium CPMM pool (specific verb+resource). It does not explicitly differentiate from sibling tools like createCLMM or createAMMv4, but the name includes CPMM, making the purpose moderately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description mentions unrelated SAP MCP tools but offers no criteria for choosing CPMM over other pool types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims the tool is a 'Read-only SAP SDK wrapper', but the annotations set readOnlyHint to false, creating a direct contradiction. This undermines the agent's understanding of the tool's side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at two sentences, with no unnecessary words. The first sentence states the core function, and the second provides useful context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is insufficient due to the behavioral contradiction, and it omits details like pagination behavior (limit parameter) or how the output is structured. Given that an output schema exists, this is partially mitigated, but the contradiction is a significant flaw.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters are fully described in the schema (100% coverage), so the description does not need to add further meaning. However, it adds no extra context beyond the schema, such as expected values for the category parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool finds tool descriptors by category name or numeric ID, and specifies it is a read-only operation. However, it does not explicitly differentiate from sibling tools like sap_get_tool_category_summary, which may have a related purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using this tool for inspecting chain state before mutations, providing context for when to use it. However, it does not specify when not to use it or point to alternative tools for different needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'Fetch' implying read-only, but the annotation readOnlyHint is false, creating a mild inconsistency. No additional behavioral traits (e.g., side effects, rate limits) are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loading the main action. However, the word 'real' is vague and unnecessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one optional parameter and an output schema, the description is adequate but lacks guidance on when to set 'detailed' to true or what to expect in the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'detailed' is fully described in the schema (100% coverage). The description adds no extra meaning, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (fetch) and resource (SAP network statistics), and references specific registries, distinguishing it from sibling tools. However, it could be more specific about what the statistics contain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 (e.g., other SAP tools). The description does not mention prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description only states returns JSON, implying a read-only operation. However, annotations show readOnlyHint=false, suggesting possible side effects, but no side effects are disclosed. No mention of permissions, rate limits, or other behavioral traits. The description does not contradict annotations, but fails to clarify the operation's nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single clear sentence with no fluff. It concisely states the action, resource, format, and purpose. Could be slightly improved by front-loading the core verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description is minimal. With an output schema present, return values may be sufficiently documented there. However, it lacks details on what 'bundled' means, how skills are aggregated, and the effect of the two parameters. Given low complexity (2 params, no nested objects), it is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds no extra meaning beyond the generic schema descriptions (e.g., 'Skills parameter for Bundle SAP MCP Skills'). It does not explain what 'skills' list expects or how 'includeContents' affects output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Return', resource 'bundled SAP MCP skills', and format 'as JSON'. Purpose is explained: 'so an agent can load or write them itself'. It distinguishes from siblings like sap_skills_list (lists skills) and sap_skills_install (installs skills) by focusing on returning a bundle for self-service, but lacks explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 sap_skills_list or sap_skills_install. The description implies usage for loading or writing skills, but does not specify prerequisites, contexts, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims 'operation class write' which directly contradicts the annotations' readOnlyHint=true. It also includes misleading write-focused context, failing to accurately disclose the read-only behavior 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is bloated with irrelevant SAP MCP context and write-related instructions that should not appear in a read-only tool. The core information is front-loaded in the first sentence, but the rest is noise. Too long for the simple purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the basic behavior of mint-dependent balance retrieval, but the contradictory write context undermines completeness. Output schema exists, reducing the need for return value description. Still, the irrelevant content detracts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite the input schema having zero parameters, the description introduces the 'mint' parameter and explains its impact on return value. It also lists parameter aliases, adding value. Baseline for zero params is 4, and this is met.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets token or SOL balance for a wallet, and differentiates by specifying that omitting mint returns native SOL balance. This is specific and distinguishes from siblings like spl-token_getTokenAccounts and sol_get_balance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. The description includes irrelevant statements about write operations (deploy, mint, transfer, etc.) that do not apply to getBalance, and generic lifecycle context without use-case clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readonlyHint=false and destructiveHint=false. The description adds 'operation class write' but does not disclose additional behavioral traits beyond this, such as required permissions, side effects, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, with the first being direct and clear. The second sentence includes some generic context that could be trimmed, but overall it is relatively concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 full param coverage, the description still lacks critical guidance on when to use thaw versus freeze or other token operations. The generic context does not sufficiently complement the schema and annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter described (mint, account, freezeAuthority). The description does not add any new semantics beyond what the schema provides, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Thaw (unfreeze) a previously frozen token account,' which is a specific verb and resource. It identifies the operation class as write, but does not explicitly distinguish from sibling tool spl-token_freezeAccount.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides generic advice like 'Confirm mint, decimals, authority...' and broadly says 'Use for SPL token deploy, mint, transfer, burn, freeze, thaw...' without specifying when to use thaw vs. alternatives. No explicit when-not or exclusion guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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.
Conciseness3/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness3/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false. The description merely restates the action without adding behavioral details like permissions, side effects, or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description includes an unnecessary long note about SAP MCP context that is irrelevant to the core function, making it less concise. The main action is stated in one sentence, but the extra text reduces clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple destructive action, the description is adequate but minimal. It does not mention prerequisites (e.g., order must exist) or consequences, but annotations and output schema partially compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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. The tool description does not add any additional 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Cancel an open order on an Openbook market,' specifying the verb and resource. It distinguishes itself from sibling tools like manifest_cancelOrder by naming Openbook.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 manifest_cancelOrder or jupiter_cancelLimitOrder. The only context is about SAP integration, which is unrelated to order cancellation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a mutation (readOnlyHint=false) that is not destructive. The description adds 'concentrated liquidity position' but omits side effects like token requirements, wallet approval needs, or position NFT creation. Behavioral traits beyond annotations are not disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose clearly. Second sentence about SAP tools is not directly relevant to this tool's usage, adding slight noise. Length is acceptable but could be more focused.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite output schema existing, the description is too brief for a complex DeFi operation. Missing prerequisites (token balances, pool existence), workflow context, and potential outcomes. An agent would need additional knowledge to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage, so baseline is 3. The description does not add extra meaning to parameters (e.g., priceLower/priceUpper are only described as 'Price Lower parameter for Orca Open Position'). No value added beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Title and description clearly state the tool opens a concentrated liquidity position on an Orca Whirlpool. This verb+resource combination distinguishes it from sibling tools like orca_swap, orca_closePosition, and orca_collectFees.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that it is for providing liquidity in a concentrated range, nor does it contrast with swap or closing positions. The SAP context note is about unrelated tool registration.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'Read' implying read-only, but the annotation readOnlyHint=false indicates the opposite, creating a contradiction. No disclosure of authentication requirements, rate limits, or side effects. The description fails to clarify the behavioral trait beyond the conflicting annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 10 words, highly concise with no fluff. Every word contributes to the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the presence of an output schema, the description lacks context about the ring buffer behavior, when messages are available, or how to use the 5 parameters effectively. The annotation contradiction further reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds no additional meaning or context for parameters like topic, roomId, roomKind, etc. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Read', the resource 'latest SAP chat messages', and the source 'room ring buffer'. This distinguishes it from sibling tools like sap_chat_read_all and sap_chat_send_message.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description mentions 'latest' but does not explain the ring buffer characteristics or when to prefer this over sap_chat_read_all. No scenarios or exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'checks' implying a read-only operation, but annotations set readOnlyHint=false, indicating possible side effects. This contradiction reduces transparency. The description adds no behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the tool's purpose. No unnecessary words, front-loaded with action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 fails to address the contradiction between the read-only implication and the annotation. It omits details about validation outcome, side effects, or specific use cases, making it insufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with the parameter description already fully explaining the domain parameter. The tool description does not add additional semantics beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Validate' and the resource 'SNS records for SAP agent compatibility', specifying the record types checked (SOL, Pic, TXT). This distinguishes it from sibling tools like sap_sns_get_record (retrieve records) and sap_sns_check_domain (domain availability).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. The description implies usage for validation of SAP agent compatibility, but does not mention when not to use it or provide alternative tools for similar tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already confirm the tool is not read-only and not destructive. The description adds no behavioral details beyond what annotations provide, such as side effects, permission requirements, or response format. It does not contradict annotations but fails to enrich transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, but the second sentence is dense with jargon and advisory content ('Publish only schemas and descriptions...') that is not action-relevant. 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of updating tool hashes and the presence of an output schema, the description omits important context such as what the output looks like, how to construct update fields, and any error conditions. It feels incomplete for an agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The main description does not elaborate on parameters. The schema's object description lists updatable fields, but the main description adds no parameter-level meaning. Thus score meets baseline without enhancement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Update tool descriptor hashes using SDK ToolsModule.update,' which specifies a clear verb and resource. This distinguishes the tool from siblings like sap_update_feedback and sap_update_agent, which update different entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions 'Use tool registry writes to advertise concrete capabilities' but does not clarify prerequisites, exclusions, or comparison with other update tools. The agent is left without decision-making context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations clearly indicate read-only, idempotent, non-destructive behavior. The description's claim of 'operation class write' directly contradicts these annotations, making the tool's behavioral profile confusing. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short and front-loads the main purpose. However, it includes an unnecessary contradictory statement ('operation class write') and some tangential instructions about confirming terms before writes, which slightly reduces efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter and an output schema, the description covers the basic purpose and scope. However, the contradiction regarding write operation and the lack of explanation about 'delegation status' or return format (though output schema may cover it) leave gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'wallet' has full schema coverage (100%). The description adds that the tool lists 'all stake accounts' and includes 'delegation status', which provides minor additional meaning beyond the schema's parameter description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('list') and the resource ('all stake accounts for a wallet') with specific output detail ('delegation status'). It also distinguishes from sibling tools by instructing to use SAP staking tools for SAP protocol accounts and AgentKit staking tools for external protocols.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context ('use for SOL and liquid staking flows') and pre-write checks, but it incorrectly labels the operation class as 'write' when annotations declare readOnlyHint=true. This contradiction undermines guidance and could mislead agents into thinking the tool modifies state.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness3/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, so the description's statement of removing liquidity is consistent but does not add behavioral details beyond the annotations. No mention of side effects, prerequisites, or ownership requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The tool purpose is front-loaded in a single concise sentence, but the second sentence about SAP MCP integration is tangential and adds length without aiding tool selection. Could be more focused.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimally complete for a simple tool: it states the action and resource. However, it lacks context on prerequisites (e.g., ownership, position existence), the optional 'percentage' parameter, and potential outcomes. Output schema exists, so return details are not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. However, the parameter descriptions are vague (e.g., 'Percentage parameter for...'), and the tool description does not clarify that 'percentage' likely represents the fraction of liquidity to remove. The description adds no extra semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Remove liquidity from a Meteora DLMM position,' using a specific verb ('Remove') and resource ('liquidity from a Meteora DLMM position'). This distinguishes it from sibling tools like meteora_addDLMMLiquidity and other Meteora pool creation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., meteora_addDLMMLiquidity). The SAP MCP context note is unrelated to selecting between similar liquidity tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions general SAP MCP read/write requirements but does not confirm whether this specific tool is a write operation or describe its effects. Annotations indicate readOnlyHint=false, but the description leaves ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two succinct sentences plus a contextual note. No unnecessary words, front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the output schema may cover returns, the description lacks detail on the tool's effect (e.g., on-chain state change) and has moderate completeness for a write tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'callsServed' is fully described in the schema (100% coverage). The description adds no additional meaning beyond the schema, which is baseline adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The verb 'Report' and resource 'served call count' clearly indicate the tool's purpose. The name and description align, but it does not explicitly distinguish from similar SAP report tools like sap_report_tool_invocations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description provides SAP context but lacks criteria for selection among sibling report tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the confirm requirement, the description does not disclose behavioral traits such as whether existing files are overwritten, directory creation, or permissions needed. Annotations do not contradict but offer no additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two sentences, front-loading the action with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple installation tool but lacks details such as what 'bundled SAP MCP skills' are, the default target directory, and the return value (though an output schema exists but is not shown).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters have schema descriptions (100% coverage), so the baseline is 3. The tool description does not add extra meaning beyond what the schema provides, but that is acceptable per guidelines.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Install bundled SAP MCP skills into a local agent skill directory') and the resource, distinguishing it from sibling tools like sap_skills_bundle and sap_skills_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only mentions a requirement ('Requires confirm: true') but provides no guidance on when to use this tool versus alternatives like sap_skills_bundle or sap_skills_list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, and the description confirms the action of closing an account and reclaiming rent. No additional behavioral traits are disclosed 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description contains some boilerplate context that is not specific to this tool, making it slightly verbose. The first sentence is concise, but the extra sentences could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool and the presence of an output schema, the description adequately covers the purpose and context. No major gaps are present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter having a description in the schema. The tool description does not add any new 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool closes a token account and reclaims rent SOL, which is specific and aligns with the tool name. However, it does not explicitly differentiate from sibling tools like spl-token_transfer or spl-token_burn.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes general context about SPL token operations and safety precautions, but lacks specific guidance on when to use closeAccount versus alternatives. No when-to-use or when-not-to-use instructions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate write operation (readOnlyHint=false). The description adds that it optionally creates a recipient ATA and advises confirming parameters before writes. This is helpful but does not detail side effects or failure modes. 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, but the second and third sentences are generic to the spl-token protocol rather than specific to the transfer tool. Could be trimmed to focus solely on transfer behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema, the description covers the key aspects: token transfer between wallets, optional ATA creation, and parameter verification. It is adequate for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all 6 parameters. The description adds value by explaining the 'createAta' parameter's purpose and stressing verification of critical parameters (mint, decimals, etc.), going beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Transfer SPL tokens between wallets' but later broadens to include deploy, mint, burn, freeze, thaw, and authority management, which are not the function of this tool. This misleads the agent about the tool's scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides general guidance to use token tools with SAP payments but does not specify when to choose this transfer tool over sibling tools like spl-token_mintTo or spl-token_burn. No explicit when-not or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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.
Conciseness3/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds value by stating it creates an unsigned transaction, implying the cancellation is not executed immediately. This complements the annotations but does not reveal additional behaviors like permissions or error states.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose. The second sentence provides useful context but is somewhat generic. No unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the annotations, output schema, and parameter documentation, the description is sufficiently complete for the tool's complexity. It explains the transactional nature and the broader workflow, though it could mention handling of invalid orders.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all three parameters. The description adds no extra meaning beyond the schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool creates an unsigned transaction to cancel a specific limit order. The verb 'cancel' and resource 'limit order' are specific. However, it does not explicitly distinguish from the sibling tool 'jupiter_cancelLimitOrders' (plural), though the singular suggests a single order.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like jupiter_cancelLimitOrders or jupiter_executeOrder. It only gives general context about Jupiter tools in SAP MCP, not specific usage criteria or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description's 'Get all limit orders' aligns. The description adds minimal behavioral context beyond annotations (e.g., filtering capability and SAP ecosystem note).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences. The first sentence is concise and on-point. The second sentence provides generic SAP MCP context that is not tool-specific, slightly bloating the description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is read-only, has comprehensive schema coverage, and an output schema is present, the description adequately covers what the agent needs to know. Filters and wallet requirement are mentioned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema documents all parameters. The description adds little extra meaning, only grouping 'active and optionally historical' which mirrors the enum. Baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves limit orders for a wallet and mentions filtering by active/historical. However, it does not explicitly differentiate from sibling tools like jupiter_getOrder, which might retrieve a single order.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., jupiter_getOrder). It implies use for querying limit orders but lacks exclusions or context-specific advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint: false, but a health check is inherently read-only. The description does not clarify this discrepancy or add behavioral details beyond the annotations. It also does not disclose any side effects or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence, front-loading the core purpose. There is no unnecessary information, though the double period is a minor formatting issue.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple health check with no parameters, the description is minimally adequate. However, it lacks context about the expected output or how the health status is represented. Given the output schema exists but is not described, the description could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, achieving 100% coverage. The description adds no parameter information, which is acceptable given no parameters exist. Baseline is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Check' and the resource 'health status of the MagicBlock Private Payments API'. It differentiates from sibling tools like magicblock_balance or magicblock_challenge, which serve different purposes. However, it could be more specific about what 'health status' entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description does not mention prerequisites, exclusions, or when not to use it. The agent must infer usage context from the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, destructiveHint=false, and openWorldHint=true. The description adds no additional behavioral context, such as side effects, permission requirements, or output characteristics. It fails to disclose any 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences: the first defines the core purpose, and the second provides SAP context. No unnecessary content. It is front-loaded with the primary action, making it efficient for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of creating a DEX market (5 required params) and the presence of many sibling market creation tools, the description is incomplete. It lacks prerequisites, error scenarios, or differentiation from similar tools. The existence of an output schema reduces the need to explain return values, but overall context is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all 5 parameters described in the schema. The description adds no further meaning to parameters, so it earns the baseline score of 3. The schema's descriptions (e.g., 'Solana public key (base58)') are adequate but not enriched by the tool description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new Openbook DEX market for a token pair,' specifying the action and resource. It distinguishes the tool as an Openbook-specific market creator among sibling tools like raydium-pools_createCPMM, manifest_createMarket, and meteora_createDynamicPool, though it does not explicitly compare to these alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage guidance for the SAP MCP context, directing the agent to related SAP tools for on-chain registration. However, it does not guide on when to use this tool versus other market creation tools (e.g., Raydium, Manifest, Meteora), leaving ambiguity for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a write (readOnlyHint false), non-destructive, non-idempotent operation. The description adds the prerequisite (requiring an existing market) but does not disclose other behaviors like transaction submission, gas costs, or error conditions. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences, 52 words) and front-loaded with the core purpose. The second sentence provides additional but somewhat tangential SAP MCP context, which slightly detracts from focus but is not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description mentions the key prerequisite and the SAP MCP context, but lacks details on return values (though output schema exists), error handling, or side effects. Given the complexity of a DeFi pool creation tool, the description could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all parameters described. The description does not add any parameter-level information beyond what is in 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (create) and resource (Raydium AMM v4 pool), and mentions a prerequisite (existing Openbook market). However, it does not explicitly distinguish this tool from sibling pool creation tools (e.g., createCPMM, createCLMM), which slightly reduces clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a prerequisite (requires an existing Openbook market) but no guidance on when to use this tool vs. alternatives like other pool creation tools or when not to use it. The SAP MCP context is about registration, not usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate mutability (readOnlyHint=false) and non-destructiveness. The description adds no behavioral details beyond what annotations provide, such as transaction costs, permission requirements, or side effects. This is adequate but minimally adds value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two clear sentences. The first sentence captures the core purpose. The second sentence provides ecosystem context, which is useful but slightly tangential. No wasted words, and it is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 and full parameter descriptions, the description is adequate but lacks usage guidelines and behavioral details. For a complex tool with 10 parameters and multiple siblings, more completeness would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter described. The description does not add any additional meaning or context beyond the schema itself. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a Raydium CLMM pool with a price range, using specific verb and resource. While it distinguishes from other pool types via the name and 'CLMM' mention, it does not explicitly differentiate from sibling pool creation tools like createCPMM or createAMMv4.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as createCPMM or createAMMv4. It includes SAP MCP context about agent registration, which is unrelated to usage decisions for this specific tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims the tool derives an ID, suggesting a read-only operation, but annotations indicate readOnlyHint=false, creating a contradiction. No additional behavioral traits are disclosed beyond the DM reservation note.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences: first stating purpose, second adding status and reservations. No unnecessary words, and information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and annotations, the description leaves gaps: it contradicts annotations, lacks usage guidelines, and does not explain side effects or prerequisites. The DM reservation note helps but overall completeness is low.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameter descriptions already exist. The tool description adds marginal value by hinting at roomKind behavior (DM reserved), but does not enhance understanding of other parameters beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it derives a deterministic SAP chat room/session ID, distinguishing it from sibling chat tools like sending messages or starting rooms. The mention of 'Group and public room IDs are active' further clarifies scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context about active room kinds (group and public) and notes DM derivation is reserved, implying when to use it. However, it lacks explicit guidance on when not to use it or alternatives like sap_chat_start_room.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a caution about storing only encrypted payloads and on-chain visibility of PDAs, which is useful beyond the annotations. Annotations already indicate it's not read-only, idempotent, or destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core action. The second sentence adds valuable context but could be slightly more efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple status fetch with one parameter and an existing output schema, the description provides sufficient context including a security note. It does not need to explain return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description of sessionId. The description does not add additional 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetch high-level SDK session status by session ID' and provides context about the SAP session flow. However, it does not explicitly distinguish from sibling tools like sap_fetch_session, which may cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The mention of 'SAP MCP context: Memory/session flow' is vague and does not help with tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'Reads escrow/pricing when available' and 'Estimate or fetch state', which implies a read-only operation. However, annotations indicate readOnlyHint=false (not read-only), creating a direct contradiction. The description also does not disclose any behavioral traits beyond what annotations provide, and the contradiction severely undermines transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no wasted words. It front-loads the main purpose and uses straightforward language. Every sentence provides necessary context without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 explain return values. It covers the core functionality, optional features, and SAP MCP context. It is mostly complete, though the contradiction with annotations slightly reduces completeness from a behavioral standpoint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds minimal extra meaning by mentioning 'optional volume curve overrides' for the volumeCurve parameter, but does not elaborate on other parameters beyond what the schema already provides. The description adds marginal value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool estimates cost for a number of calls using SDK X402Registry.estimateCost, and mentions reading escrow/pricing and supporting volume curve overrides. It gives a specific verb and resource, but does not explicitly differentiate from siblings like sap_x402_calculate_cost or sap_x402_prepare_payment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using the tool before creating escrows or settling calls, and notes that write operations require signer mode and MCP policy approval. However, it does not specify when not to use this tool or provide explicit alternatives, leaving usage context somewhat implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description describes the tool as a 'check' (read operation), but annotations set readOnlyHint to false, indicating it is a write operation. This is a direct contradiction. Additionally, no other behavioral traits (like side effects or permissions) are disclosed beyond the misleading check intent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise but includes extraneous phrases like 'SAP MCP context' and generic lifecycle guidance that do not directly help an agent select or invoke this specific tool. It could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool has an output schema (so return values are handled externally), the description fails to reconcile the read vs write contradiction and omits important context like prerequisites or the fact that it is a read operation. This undermines completeness for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a description for the mint parameter. The description adds context about what the check analyzes (authority, concentration, liquidity) but does not enhance understanding of the parameter itself beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool checks a token for rug pull risks, listing specific factors (mint/freeze authority, holder concentration, liquidity). This clearly distinguishes it from sibling tools like spl-token_burn or spl-token_mintTo which perform token operations rather than analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description suggests using this tool before token operations like deploy, mint, transfer, etc., implying it is a prerequisite check. However, it does not explicitly state when not to use it or provide alternatives, though the intent is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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.
Conciseness3/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior1/5
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.
Conciseness3/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness2/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness3/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate it's a write operation (readOnlyHint=false), non-idempotent, and not destructive. The description adds no further behavioral details such as order lifecycle, confirmation, or potential failures. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences. The first sentence states purpose directly. The second sentence introduces SAP context, which may be slightly distracting but does not significantly degrade clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal for a complex trading tool. It lacks essential context: no explanation of what happens after placing an order (e.g., on-chain transaction, pending fill), no mention of required balances or fees, and no description of the output schema (though output schema exists).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds no extra meaning beyond the schema, such as price units or order type details. Baseline 3 is appropriate as no negative evidence.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Place a limit order on a Manifest market,' specifying the verb and resource. The title is consistent. However, it does not differentiate this tool from other order placement tools like openbook_placeOrder or jupiter_createLimitOrder, which are siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context about SAP MCP and directs to use other sap_* tools for on-chain publishing, offering some guidance. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., 'use for standard limit orders on Manifest'), and does not mention prerequisites like wallet funding or market existence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, and the description confirms closure. However, it does not disclose any additional behavioral details (e.g., prerequisites, return values) 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise but includes an extraneous note about SAP context that does not help the agent select or use the tool. It could be more focused.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 annotations, the description is adequate but lacks detail on the outcome and side effects of closing the position. It is neither severely incomplete nor fully informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both parameters. The description adds no extra information about parameter usage or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Close a Whirlpool position and collect all fees/rewards.' The verb 'close' and resource 'Whirlpool position' are specific, and it distinguishes from siblings like orca_openPosition and orca_collectFees.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 orca_collectFees or orca_openPosition. The mention of SAP context tools is irrelevant for usage decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, so the tool is mutative. Description says 'collect' implying a write operation, but does not disclose specifics like token transfers or modifications to the position. With annotations present, the bar is lower, but additional context would be valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The first sentence is concise, but the second part about SAP MCP context adds length without direct relevance to this tool's usage, reducing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic action but omits prerequisites, side effects, and usage context. Given the tool's simplicity and presence of output schema, completeness is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with clear parameter descriptions. The tool description does not add 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Collect accumulated fees from a Whirlpool position' which is a specific verb+resource. It clearly distinguishes from sibling tools like orca_swap, orca_openPosition, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 note mentions other tools but does not provide usage context for fee collection. Lacks prerequisites or typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, openWorldHint=true, etc. The description adds that it optionally includes an initial dev buy, but lacks details on prerequisites (e.g., wallet funding), fees, or constraints (e.g., uniqueness of name/symbol). Not contradictory but could be more informative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The core description is two sentences, but it includes a lengthy SAP context paragraph that is tangential to the tool's primary function. This extra text reduces conciseness and may distract from the main purpose. Front-loaded adequately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Has an output schema to cover return values, but the description does not explain how to use optional parameters (e.g., image, twitter) or any dependencies (e.g., SOL balance, deployer authority). Missing important context for a token launch tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are described in the schema. The description does not add any extra meaning beyond the schema descriptions. For example, 'initial dev buy' maps to initialBuyAmount, but the schema already explains it. No added value over structured data.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('launch'), the resource ('new token on Pump.fun via PumpPortal'), and an optional feature ('initial dev buy'). It distinguishes from sibling tools like pump_trade, which is for trading, making the purpose 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides SAP ecosystem context and mentions related tools but does not explicitly state when to use this tool vs. alternatives (e.g., other token deployment tools) or when not to use it. It gives some guidance but lacks clarity on selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims a read operation, but annotation readOnlyHint=false indicates the tool may have side effects, contradicting the implied behavioral safety. Additionally, no side-effect or permission details are disclosed beyond the contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, complete sentence (13 words) that immediately identifies the action and sources. No redundant or unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, output schema present) and available annotations, the description is minimal and omits context like usage scenarios or implications of the data sources. It is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents parameters. The description adds no parameter-level information beyond what the schema provides, meeting the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Read all SAP chat messages') and the specific sources ('sealed ledger pages plus the latest ring buffer'), effectively distinguishing it from siblings like sap_chat_read_latest which likely returns only latest messages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving full message history but does not explicitly state when to use this tool versus alternatives like sap_chat_read_latest. No exclusions or when-not guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds minimal behavioral insight beyond repeating the read-only nature and mentioning the underlying RPC and program, without disclosing rate limits, error behaviors, or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, efficient, and front-loaded. However, the second sentence mixes context and guidance into a somewhat dense phrase, slightly affecting readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 comprehensive annotations, the description adequately covers the tool's role within the SAP ecosystem, referencing read-only chain state inspection for mutations. It assumes familiarity with SAP concepts but is sufficient for informed use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the single parameter clearly described in the schema as 'Pending settlement PDA (base58) to fetch'. The description adds no further meaning to the parameter, consistent with the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches a 'V2 pending settlement PDA', which is a specific resource and action. However, it does not distinguish this fetch from other SAP fetch tools like sap_fetch_attestation, as all 'sap_fetch_*' tools share the same read-only wrapper context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for inspecting chain state before mutations ('Use these reads to inspect current chain state before mutating...'), but does not specify when not to use it or suggest alternatives. No prerequisites or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims the tool reads data, but annotations set readOnlyHint=false and destructiveHint=true, contradicting the read-only nature. This is a critical inconsistency that misleads 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short with two sentences. The first sentence directly states the purpose; the second adds relevant context. It is efficient, though the mention of write operations might cause minor confusion for this read-only tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's role in the payment flow and the contradictory annotations, the description is incomplete. It does not explain what 'next' means or how the index is used, though an output schema exists to partially compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 the three optional parameters (nonce, agentWallet, depositorWallet). The description adds no further meaning or usage guidance beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read the next V2 settlement index' with a specific verb and resource, and places it in the SAP MCP payment and settlement flow, distinguishing it from sibling tools that might create or settle escrows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: 'Estimate or fetch state before creating escrows or settling calls'. It also mentions prerequisites for write operations, implying this is a read tool. However, it does not explicitly contrast with siblings like sap_fetch_escrow_v2 or sap_fetch_pending_settlement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states the tool returns a public key without reading or exposing keypair bytes, suggesting a read operation. However, the annotation readOnlyHint is false, which contradicts this. This discrepancy reduces transparency significantly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the purpose and adds a security-relevant qualifier. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with an output schema, the description is minimally adequate. However, it lacks guidance on when to use it and does not resolve the annotation contradiction, which could confuse the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (one parameter fully described in schema). The description adds no additional meaning beyond the schema's description of the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: returning the configured public agent key for a profile. The verb 'Return' and the resource 'public agent key for a profile' are specific, and the additional clause 'without reading or exposing keypair bytes' distinguishes it from other sap tools that might expose more sensitive data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
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 implies the tool is for retrieving public keys, but does not mention when not to use it or suggest other tools for different key retrieval needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds that the caller must be the agent owner wallet and that write operations require signer mode and policy approval. However, it lacks details on failure modes, partial success, or what exactly gets settled beyond the entries array.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at three sentences, efficiently conveying the core purpose and key usage constraints. It could be slightly more structured (e.g., separate sentences for prerequisites), but it remains clear and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 explain the return format or success/failure behavior. The 'entries' parameter structure is vaguely referenced but not detailed. For a complex batch settlement operation, this leaves significant gaps in understanding the tool's full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 8 parameters have descriptions in the schema (100% coverage). The description does not add any additional meaning or constraints beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Batch-settle served x402 calls' using 'SDK X402Registry.settleBatch', giving a clear verb and resource. It places the tool within the 'Payment and settlement flow', but does not distinguish it from sibling settlement tools like sap_settle_escrow_v2.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes that the tool 'Must be called by the agent owner wallet' and requires 'enabled signer mode and MCP policy approval'. It advises to 'Estimate or fetch state before creating escrows or settling calls', but does not explicitly contrast with alternative settlement tools or specify when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a write operation (readOnlyHint=false) and not destructive, which aligns with the description. The description adds the constraint 'requires mint authority', but does not elaborate on other behavioral traits like success/failure conditions or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description contains useful information but includes boilerplate like 'SAP MCP context: Protocol spl-token; operation class write' which adds noise. It could be more concise without the generic context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema (not shown but indicated), so the description does not need to explain return values. The description covers the main action and caution, but lacks details on error states or post-conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all 4 parameters, so the description does not need to add meaning. The description reiterates the parameter names but adds no new semantic details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Mint additional tokens to a destination wallet' with a specific verb and resource. It distinguishes from sibling spl-token operations by specifying 'requires mint authority' and focusing on minting, though it includes generic context about other operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises confirming parameters before writes and mentions using token tools with SAP tools only in certain lifecycle contexts, but it does not explicitly state when to use this tool over alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness3/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states it is a read operation, but the annotation readOnlyHint=false contradicts this, indicating a potential inconsistency. The description itself transparently identifies the operation as a read and notes the auth requirement, but the contradiction with annotations 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with clear front-loading of the core purpose. However, it contains a minor typo (double period at the end), which slightly detracts from professionalism.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 need not detail return values. It covers the essential action and auth requirement. However, it lacks context about what 'ephemeral-rollup' means and how to obtain the auth token (magicblock_login), which could be inferred but not explicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so each parameter is already documented. The description adds no further semantics beyond mentioning the auth token requirement, which is already captured in the schema. It meets the baseline but adds little value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read the ephemeral-rollup SPL token balance for an address', specifying a verb ('read') and a resource ('ephemeral-rollup SPL token balance'). It distinguishes itself from the sibling magicblock_balance by mentioning 'ephemeral-rollup', implying this is for private/rollup balances.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions that a bearer token from login is required, providing a prerequisite. However, it does not explain when to use this tool versus alternatives like magicblock_balance (presumably for public balances), nor does it offer guidance on when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description aligns ('Get the current orderbook') but adds no 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence. The additional SAP context sentences are informative but add length. Overall, it is concise and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 100% schema coverage, an output schema present, and comprehensive annotations, the description covers the tool's basic operation. However, it lacks elaboration on the 'depth' parameter's effect, leaving a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema documents both parameters. The description does not add meaning beyond the schema; for example, the 'depth' parameter remains vague. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'Get the current orderbook for a Manifest market.' It distinguishes this tool from sibling tools like manifest_placeLimitOrder and manifest_cancelOrder, though the SAP context note is slightly extraneous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some context on when to use related SAP tools for on-chain registration but does not explicitly state when to use this tool itself or provide alternatives for getting an orderbook. Usage is implied but no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (write, not destructive), the description adds that it requires confirmations before writes and returns addresses. It also provides context for agent identity planning, which is useful but 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose and mixes multiple concerns (purpose, SAP context, agent planning, usage guidance). It could be more concise and better structured, with a clear separation of concerns.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description mentions return values and prerequisites but does not elaborate on parameter behavior like maxSupply or isMutable. Given the existence of output schema, it is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions per parameter. The description reinforces some parameters (URI, creators, royalties) but does not add new meaning beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deploys a new NFT collection via Metaplex and returns addresses. It is distinct from sibling tools like mintNFT which mints individual tokens. However, the description is overloaded with SAP context, slightly blurring focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when the agent needs an NFT collection, but lacks explicit when-not or alternatives to sibling tools like mintNFT or updateMetadata. The guidance is implied rather than prescriptive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims 'read-only' and 'never signs', yet the annotation readOnlyHint is false, indicating a contradiction. This is a serious inconsistency that misleads the agent about whether the tool modifies state. No other behavioral traits (e.g., auth needs, rate limits) are mentioned beyond the contradictory claim.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences plus a context line) and front-loaded with the tool's purpose. Every sentence adds value, though it could be slightly more streamlined. No unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (14 parameters, no required fields), the description covers the main use case and workflow positioning. With an output schema referenced, return values need not be explained. However, it lacks detail on the planning output content and fails to resolve the readOnly contradiction, leaving gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 parameters thoroughly. The description provides overarching context (e.g., 'pricing metadata') but does not add individual parameter meaning beyond what's 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is a 'Free read-only planner' for SAP agent identity tasks, including registration, updates, and linking. It explicitly lists the resources involved (Metaplex, SNS, x402) and distinguishes itself from sibling tools like sap_payments_register_agent by being a planning step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use the tool: 'Use this before sap_payments_register_agent or sap_payments_update_agent'. It also clarifies what it does not do ('does not touch chain and never signs'), providing clear context. It lacks explicit when-not-to-use statements, but the guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond annotations by mentioning 'chunked' behavior and the difference between public/private storage. However, it does not disclose potential side effects, rate limits, or authentication requirements. Annotations are neutral (readOnlyHint=false, destructiveHint=false), so 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences, front-loaded with the primary action. Every sentence provides essential information without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (13 parameters, nested objects, output schema), the description is too brief. It does not explain return values, chunking mechanics, or how to choose between public and private message types. Missing critical context for a multi-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds no additional meaning to individual parameters beyond what the schema provides, earning the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Send a chunked SAP chat message to a room') and distinguishes between public and private messages. However, it does not explicitly differentiate from sibling tools like sap_chat_read_all or sap_chat_derive_room, though no other send tool exists among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (to send messages), but provides no explicit guidance on when not to use it or alternatives. Since no other send tool is listed, the uniqueness is implicit, but the description lacks direct usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds general MCP context about write tools requiring signer policy and RPC, but lacks specific details on dispute effects (e.g., blocking settlement, cost). Annotations already indicate it's a write operation, so additional context is marginal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no wasted words. Efficient and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite output schema existing, the description lacks guidance on when to file a dispute, what happens after, or any dependencies. Only generic MCP context is provided, leaving gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description adds no extra meaning beyond parameter descriptions. With 0 required parameters, the description could clarify importance of settlementIndex, but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool files a dispute for a V2 pending settlement, using a specific verb and resource. This differentiates it from siblings like sap_create_escrow_v2 and sap_settle_escrow_v2.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives, nor prerequisites or conditions. The description does not clarify if parameters are effectively required or how to know when a dispute is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a non-read-only, non-destructive operation; the description adds context about on-chain creation and the need for stability/auditability. However, it does not elaborate on side effects (e.g., irreversibility) or prerequisites beyond verification.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and the first sentence clearly states the primary purpose. The 'SAP MCP context' line is somewhat redundant given the title, but overall it is well-structured and not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 full parameter descriptions, the description covers the basics. However, it lacks guidance on obtaining the target wallet PDA or when feedback is appropriate, leaving some context gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters are documented in the schema with descriptions (100% coverage), but the tool description adds no additional semantic detail beyond what is already in the schema parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create on-chain feedback') and the resource ('agent wallet'), and the 'SAP MCP context' line adds domain specificity. However, it does not explicitly distinguish this tool from siblings like `sap_update_feedback` or `sap_revoke_feedback`, relying on the name alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises verifying the target agent PDA or wallet and ensuring data stability, which is helpful but provides no direct comparison to alternative feedback tools. No guidance on when to use this over update or revoke variants.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a write operation with no destructive or idempotent hints. Description adds context about the SAP staking flow and urges confirmation, but does not elaborate on side effects, permissions, or return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words, front-loading the core purpose. Could be slightly more structured but remains clear and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Explains the tool's role in the SAP staking flow, but omits prerequisites, edge cases (e.g., already staked), and potential state changes beyond the immediate operation. Output schema exists, mitigating need for return details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description does not add significant meaning beyond what the input schema already provides for both parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it initializes stake for an agent wallet, with a specific verb and resource. Distinguishes from external AgentKit tools, but does not differentiate from internal SAP staking siblings like sap_deposit_stake.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides pre-condition to confirm wallet, amount, and timing, and notes distinction from AgentKit tools. However, lacks explicit guidance on when to use this tool versus other SAP staking operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description claims 'Free read-only', but annotation has readOnlyHint=false, contradicting the description. The description does not explain this discrepancy.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is front-loaded with key info but includes some redundant context (SAP MCP context). Generally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 (implied), the description lists return fields and usage context sufficiently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters; schema coverage is complete. Baseline for 0-param tool is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns protocol invariants (specific resources) and lists what is included. It does not explicitly differentiate from siblings but provides usage context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends using this tool before SAP registry writes and when fee/treasury behavior is unclear. Provides context about read vs write tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, so it is a write operation. The description mentions write tools require signer policy, RPC, and active SAP profile, but this is general context. No contradiction with annotations, but specific behavioral details (e.g., what happens on invocation, error scenarios) are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each adding value: the first states the purpose, the second provides SAP context. No redundant or extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of a complete output schema and annotations, the description adequately explains the tool's purpose and context. It covers the key aspects but could be slightly more specific about output or prerequisites for the 'invocations' parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters are described in the schema. The description adds no additional parameter details beyond what the schema provides, so it meets the baseline without adding extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reports invocation count for a SAP tool descriptor. It provides context about the SAP MCP wrapper but does not explicitly distinguish from the sibling tool sap_report_calls, which may have a similar purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description includes general SAP context about read/write tools but does not specify conditions for using this tool or compare it to similar tools like sap_report_calls.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims 'Read latest entries', implying a read-only operation, but annotations set readOnlyHint=false, indicating it may modify state. This contradicts the behavioral hint. Additionally, the description lacks details on side effects or authorization needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, concise and front-loaded with the core action. The second sentence adds context but is slightly tangential, earning a 4 rating.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values are covered. However, the behavioral contradiction (read vs. potentially write) undermines completeness. The description omits important behavioral context despite the existence of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the sessionId parameter with 100% coverage. The description adds no further semantic meaning beyond what the schema provides, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads latest entries from a session ID, with a specific verb ('Read') and resource ('entries from a high-level SDK session ID'). It distinguishes from siblings like sap_session_status (checks status) and sap_session_start (starts session).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context about the SAP MCP memory/session flow and advice on what data to store. However, it does not explicitly state when not to use this tool or suggest alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds context about the return content (agent identity, wallet, metadata, SNS records) and mentions using 'SAP SDK SnsModule', but does not elaborate on other behavioral aspects like rate limits, authentication needs, or cost.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the purpose and lists key outputs. No unnecessary words, making it highly concise for the information it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema, the description provides appropriate high-level context of what is returned. However, it lacks details on edge cases, prerequisites, or comparison to similar SNS tools, which would be beneficial for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with the parameter 'domain' described in the schema. The description does not add any additional parameter semantics beyond what the schema already provides; it only restates the purpose in broader terms.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (resolve) and target (.sol domain), listing specific outputs (SAP agent identity, wallet, metadata, SNS records). This differentiates from the sibling 'sns_resolveDomain' which likely resolves domains generally, but does not explicitly contrast with other SNS tools like 'sap_sns_resolve_wallet'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description implies it is for resolving .sol domains to SAP-specific data, but does not mention when not to use it or name specific alternatives among the many SNS sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive. Description adds use of Bonfida SDK, but does not disclose whether external API calls are made or response behavior. Adequate given annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, no redundancy, front-loaded with action and result. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present and simple single-parameter input, description covers the core functionality. Could mention error handling or domain format, but not essential for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameter description. Description does not add extra meaning beyond the schema's 'The .sol domain name to resolve...' Baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool resolves .sol domains to owner wallet public key using Bonfida SDK. Verb and resource are specific, but does not explicitly differentiate from sibling 'sap_sns_resolve_domain'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 'sap_sns_resolve_domain' or other SNS tools. Missing context on prerequisites or edge cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness3/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness3/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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 that prices are 'heuristic' and supports extra info, but does not disclose potential issues like data staleness or rate limits. It adds modest 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences: one for purpose and one for SAP MCP context. The second sentence is useful but somewhat generic for Jupiter tools. Efficient but could be slightly more tailored to this specific tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema (so no need to describe return values), the description covers purpose and key features. It adequately informs the agent about the heuristic nature and optional extra info, though it could mention that prices are approximate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter having clear descriptions (e.g., vsToken: 'Token mint address (base58)'). The description adds 'Supports buy/sell price, confidence, and depth info,' which aligns with the showExtraInfo parameter but does not provide new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches real-time heuristic prices for tokens, specifying support for buy/sell price, confidence, and depth info. While it distinguishes from other Jupiter trading tools, it lacks explicit differentiation from similar price tools like coingecko_getTokenPrice or pyth_getPrice.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions SAP MCP context and that Jupiter tools are for quote/route/swap preparation, but does not provide specific guidance on when to use this tool versus alternatives. No when-not-to-use or exclusion criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds return types but no new behavioral traits (e.g., side effects, auth needs). It adds marginal value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear first sentence. The second paragraph adds ecosystem context, which is useful but slightly tangential. Front-loaded and no unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With full schema coverage, output schema present, and comprehensive annotations, the description is adequate for a simple query tool. It covers search capabilities and return fields, though it could elaborate on terms like 'organic score'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter 'query' has full schema description coverage (100%). The overall description repeats the schema's explanation but adds no new semantics or constraints. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for token information by mint address, symbol, or name, and lists what it returns (metadata, price, organic score, audit info). However, it does not explicitly differentiate from sibling tools like jupiter_searchTokens or jupiter_getTokenList, relying on implicit differences in returned fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides ecosystem context (Jupiter tools for preparation, SAP for signing) but gives no specific guidance on when to use this tool versus alternatives like getPrice or searchTokens. Context is present but lacks explicit when/when-not usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, destructiveHint. Description adds minimal behavioral context beyond the purpose, so it meets the baseline but doesn't exceed it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences; the first is concise and clear. The second sentence about SAP context is somewhat extraneous and could be moved to a separate note, but overall the description is not overly long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With annotations covering safety and an output schema available, the description is sufficient for a simple read-only query. However, it could add more context about the protocols or rate formats.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description adds no additional meaning beyond the parameter's name and type. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'get', the resource 'best lending/yield rates', and the scope 'across all protocols via Lulo'. This distinguishes it from sibling Lulo tools like lulo_getPositions, lulo_deposit, and lulo_withdraw.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 second sentence about SAP context is not usage guidance for this tool but instructions for on-chain registration, which is irrelevant for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description adds little beyond stating the returned data (identity and FQDN). No behavioral traits are disclosed that aren't already covered by annotations, but there is 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words. The trailing double period is a minor formatting issue but does not detract significantly. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity of the tool (one optional parameter, simple read operation) and the presence of an output schema, the brief description is sufficient. It covers the core purpose and does not leave critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with one optional parameter 'endpoint' having both enum values and a description. The tool description does not add any additional meaning beyond what the schema already provides, resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the identity and FQDN of the current ER Validator node, using a specific verb and resource. It distinguishes itself from sibling magicblock tools like getAccountInfo or getDelegationStatus, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, context, or when to avoid it. The agent must infer usage purely from the tool name and sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true. The description adds that the tool builds an unsigned transaction and mentions a builder fee, which provides extra behavioral context. However, it does not detail what side effects occur (e.g., token destruction) or prerequisites for operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences: the first clearly states the action, the second provides follow-up steps and mentions the fee. No extraneous information, making it efficient for an agent to read.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, output schema present), the description is brief and may leave an agent without sufficient context about the Ephemeral Rollup process, the meaning of optional parameters, or the expected output. It is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 tool description does not add additional semantics or context to the parameters, earning a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'withdraw' and the resource 'SPL tokens from an Ephemeral Rollup back to Solana'. It distinguishes the tool's purpose from siblings like magicblock_deposit or magicblock_swap, but does not explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a basic usage flow by advising to use sap_preview_transaction, sap_sign_transaction, and sap_submit_signed_transaction. However, it does not give explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: it discloses support for compressed NFTs (cNFT) and lists prerequisites like confirming metadata URI and ownership. This complements the readOnlyHint=false and destructiveHint=false annotations, though it does not detail error states or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, but includes extraneous details about SAP MCP context and agent identity workflows that are not essential for all users. It could be trimmed to focus on the minting functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers prerequisites and mentions both minting types, but it does not explain the output (likely a mint address) or provide guidance on parameters like isMutable or sellerFeeBasisPoints. Since an output schema exists, the return value is not required, but more parameter guidance would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers all parameters with descriptions, but many are tautological (e.g., 'Share parameter for...'). The tool description does not substantially deepen understanding of parameter meanings or usage, such as how creators or sellerFeeBasisPoints affect minting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool mints a new NFT via Metaplex and supports both standard and compressed minting. The verb 'mint' and the mention of Metaplex distinguish its primary purpose, though it does not explicitly differentiate from sibling tools like deployCollection or updateMetadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a broad list of use cases (collection, mint, metadata, etc.) and mentions when to use Metaplex tools generally. However, it lacks explicit guidance on when not to use this tool or how it compares to alternative tools for similar tasks, such as deployCollection for collection creation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide destructiveHint=true. The description adds 'Irreversible for some types' which is useful, but lacks details on which types are irreversible and what happens on failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description includes a long block about SAP MCP context and agent identity planning that is not specific to this tool, making it less concise. The core purpose is front-loaded but the extra content wastes space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (destructive write) and that an output schema exists, the description covers the action, irreversible nature, and pre-operation checks. It is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The description adds minimal extra 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Revoke (remove) a specific authority' which is a specific verb and resource. It distinguishes from sibling tools like delegateAuthority by the opposite action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Use for... authority workflows' but does not explicitly state when to use this tool versus alternatives like delegateAuthority, nor does it provide when-not-to-use criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false. The description does not disclose any additional behavioral traits such as permission requirements, state changes, or side effects beyond the basic 'Add liquidity' action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core purpose, and includes a relevant context note. Every sentence serves a purpose with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While schema and output schema cover parameter details and return values, the description lacks behavioral transparency and usage guidelines. For a complex DeFi tool, it should explain distribution strategy options or prerequisites, making it minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter has a description. The tool description does not add extra meaning beyond what is already in the schema, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add liquidity to a Meteora DLMM pool with a distribution strategy.' It uses a specific verb and resource, and distinguishes from sibling tools like meteora_createDLMMPool and meteora_removeDLMMLiquidity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a context note about when to use SAP registration tools, but does not explicitly specify when to use this tool vs alternatives like raydium-pools_addLiquidity or what prerequisites are needed. Usage is implied but not differentiated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. Description adds no additional behavioral context (e.g., network, data freshness). With strong annotations, credit is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two brief sentences. The first is efficient and front-loaded. The second is context-specific but not excessive. Slightly verbose due to the SAP context, but overall concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 documented. Description lacks details on which pool attributes are returned, but for a simple read-only tool with one param, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single param 'poolAddress'. Description adds no extra meaning beyond the schema (e.g., format examples). Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
First sentence clearly states the verb 'Get' and resource 'Orca Whirlpool pool information', distinguishing it from sibling tools like orca_swap or orca_openPosition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 (e.g., other Orca tools). The second sentence describes unrelated SAP registration context, not usage conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly=false, openWorld=true, idempotent=false, destructive=false. The description adds that it creates vault, session, ledger, which is useful context beyond annotations. However, it lacks discussion of permissions, costs, or idempotency nuances, which are relevant for an on-chain operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the primary action 'Start an on-chain SAP chat room', followed by implementation details. No extraneous words; every phrase adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return value explanation is unnecessary. However, the description omits important context like ownership requirements, cost (SOL needed), and whether participants must already exist. The openWorldHint annotation suggests public use, but description could clarify access control.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with descriptions for all 5 parameters. The tool description does not add any parameter-specific information beyond what the schema provides, so score is baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Start', the resource 'on-chain SAP chat room', and the mechanism 'creating the backing vault, session, and ledger if needed'. It distinguishes itself from sibling tools like sap_chat_send_message or sap_chat_derive_room by specifying it is for initiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many chat-related siblings (e.g., sap_chat_derive_room, sap_chat_seal_room), an agent would benefit from explicit statements about prerequisites or scenarios where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims 'Read-only SAP SDK wrapper', but annotations set readOnlyHint=false, creating a contradiction. It adds context about being a wrapper and inspecting chain state, but the contradiction undermines transparency. Also, 'Paid hosted discovery' suggests possible costs not covered by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two short paragraphs. The first paragraph front-loads the core purpose and filters. The second provides contextual information. No unnecessary sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (15 optional parameters, output schema exists), the description adequately covers the tool's role in the SAP ecosystem, pagination, and read-only intent. It omits details on output format, but the output schema presumably handles that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter is already described. The description lists filter categories (query, wallet, protocol, etc.) but adds no new details beyond the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search and filter the current on-chain AgentAccount directory' with specific filter types. It hints at sibling differentiation by mentioning 'before calling per-agent fetch tools', but does not explicitly contrast with similar tools like sap_list_all_agents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'Use this for targeted agent discovery before calling per-agent fetch tools.' It implies alternatives (per-agent tools) but does not explicitly 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false (write operation) and openWorldHint=true. The description adds context about storing encrypted data and visible on-chain metadata, which is useful. However, it does not disclose other behavioral traits like cost, confirmation, or side effects 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences: one stating the action, one providing usage guidance. It is front-loaded and avoids unnecessary words. Minor improvement could be adding a structure with separate bullet points for parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool writes encrypted memory in a session/vault context, the description mentions 'Memory/session flow' but does not explicitly state prerequisites (e.g., an active session) or what the output is. With an output schema present, return values are covered, but the description could be more complete regarding the overall flow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no defined properties, but the description lists expected fields (sequence, encryptedData, nonce, contentHash, etc.) with types, adding significant meaning beyond the schema's generic description. The schema description coverage is 100% per context, but the tool description still adds value by specifying types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Inscribe encrypted memory using SDK VaultModule.inscribe'. It also mentions the SAP MCP context (Memory/session flow). However, it does not explicitly differentiate from the sibling tool 'sap_compact_inscribe_memory', which likely has a similar but compressed function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on what to store ('intentionally encrypted payloads or public hashes') and warns about on-chain visibility of metadata. However, it does not specify when to use this tool versus alternatives like 'sap_compact_inscribe_memory' or prerequisites (e.g., existence of a vault/session).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, which cover safety and idempotency. The description adds no additional behavioral context beyond the basic action of listing. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words. It is front-loaded and efficient, though it could benefit from slightly more detail without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description need not explain return values. However, it does not mention that the 'skills' parameter is optional (no required params) or its purpose. For a simple list tool, it is minimally adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has an array parameter 'skills' with a poor description repeating the title. The tool description does not clarify whether the parameter is used for filtering or its format. Schema coverage is high but the schema descriptions are unhelpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'bundled SAP MCP skills and their files'. It distinguishes from sibling tools like sap_skills_bundle and sap_skills_install, which are for creating or installing skills.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (to list bundled skills), but does not explicitly state when to use this tool over alternatives or provide guidance on when not to use it. Since it's a simple list, explicit guidelines are less critical, but still absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds the return format ('key-value map') and the SDK usage, which are useful but not extensive behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff, front-loaded with action and outcome. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return value explanation is not required. However, the description does not address the optionality of the domain parameter (required array missing in schema), potential errors, or performance implications for domains with many records.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 'a .sol domain' for the domain parameter, but does not add meaning beyond what the schema already provides (e.g., format, examples).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetch') and resource ('all configured SNS records for a .sol domain'), clearly distinguishing this tool from other SNS-related tools that handle single records, registration, or resolution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 (e.g., sap_sns_get_record for a single record). The mention of 'using the Bonfida SDK' is informational but does not provide usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotation contradiction: readOnlyHint=false conflicts with description stating 'Pure local cost calculation; does not read chain state,' implying a read-only pure function. This inconsistency undermines trust in behavioral accuracy.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three compact sentences: core purpose, flow context, and usage advice. No wasted words, front-loaded with the most critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the annotation contradiction, the agent cannot reliably determine side effects. Output schema exists (not shown) so return values are covered. The description provides flow context but the contradiction is a critical gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema provides 100% description coverage for all 4 parameters. Description adds no additional parameter detail 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool performs a local cost calculation using SDK X402Registry.calculateCost and does not read chain state. This verb-resource pair is specific and distinguishes from siblings like sap_x402_estimate_cost.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides clear context: it flows in 'Payment and settlement flow' and should be used 'before creating escrows or settling calls.' It also hints at prerequisites (signer mode, policy) for subsequent write ops, but does not explicitly exclude alternatives or state 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'operation class read', implying the tool is a read-only operation. However, the annotation readOnlyHint=false contradicts this, indicating the tool may have side effects or modifications. This contradiction undermines transparency and misleads the agent about the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, with the main action in the first sentence. It is concise, front-loaded, and every sentence adds value (action, context, pairing guidance).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values need not be described. However, the description does not cover prerequisites, error conditions, or behavioral details beyond the basic purpose. The annotation contradiction also indicates incompleteness. Overall, it is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 significant meaning beyond the schema. The schema already describes the wallet parameter. Description adds no syntax, format, or example details, resulting in no extra value beyond the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('reverse-lookup'), resource ('.sol domains'), and scope ('owned by a wallet'). It also distinguishes from sibling tools by naming specific pairing tools, 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly defines when to use this tool ('Use to find the SNS domain associated with a wallet') and suggests pairing with sap_sns_resolve_wallet or sap_sns_check_ownership. However, it does not explicitly state when not to use it or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds the context of using the 'configured Solana RPC endpoint' but does not disclose further behavioral traits like error handling or edge cases. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundant words. It is front-loaded and efficient, though it could briefly mention the safe read-only nature already covered by annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with full annotations and output schema, the description adequately covers the tool's purpose and context. It lacks details about the RPC endpoint configuration, but that is likely global context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema already describes all parameters with descriptions. The tool description adds no 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Fetch', the resource 'SOL balance', and the target 'wallet or account'. It distinguishes itself from siblings like spl-token_getBalance by specifying SOL balance rather than SPL token balance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There are sibling tools for token balances and other reads, but the description does not differentiate or advise on selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior1/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, openWorldHint=true, etc. The description adds no further behavioral details such as success/failure outcomes, fees, or the need to check status via jito_getBundleStatus. Without this, an agent may not understand potential side effects or the non-deterministic nature of bundle inclusion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences. The first sentence delivers the core purpose. The second sentence provides SAP context, which may be useful for agents integrating with the SAP ecosystem but is not essential for basic usage. No fluff, and the most critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with 2 parameters and full schema coverage, so the description is mostly adequate. However, missing behavioral context (e.g., non-guaranteed inclusion, tip role) and no mention of output (though output schema exists) leave gaps in understanding. For a tool of this complexity, it is minimally complete but could be improved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly defining 'transactions' as an array of base64-encoded signed transactions (max 5) and 'tipLamports' as a raw token amount. The tool description does not add extra 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Send a Jito bundle for MEV-protected, atomic transaction execution.' This specifies the action (send), resource (Jito bundle), and intent (MEV protection and atomicity). The title and description distinguish it from sibling tools like jito_getBundleStatus, which retrieves bundle status. The description effectively communicates its unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for sending bundles requiring MEV protection and atomic execution. It does not explicitly state when not to use it or compare with alternatives, but given there are no direct siblings for sending bundles, the implied context is sufficient. The SAP context note provides ecosystem guidance but is secondary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true. The description adds that the tool 'creates unsigned transactions', which is a key behavioral trait. It also implies batch operation. This adds value beyond annotations by clarifying the output is not directly executed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, with the first sentence being direct and the second providing context. While not overly verbose, the second sentence is somewhat extraneous and could be trimmed for better conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, output schema exists), the description covers the basic purpose and the unsigned transaction nature. However, it lacks details about prerequisites (e.g., owning the orders), error conditions, or output structure beyond what the schema provides. It is minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already documented in the schema. The description does not add any additional meaning or usage hints for the parameters, so it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'cancel' and the resource 'multiple limit orders in batch', distinguishing it from siblings like jupiter_createLimitOrder or jupiter_cancelDCA. The core action is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions SAP MCP context and the need to use transaction submission tools afterward, but it does not provide explicit when-to-use or when-not-to-use guidance relative to other cancellation tools like manifest_cancelOrder or openbook_cancelOrder. The context is helpful but insufficient for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, signaling safe read behavior. The description adds that it returns matching tokens with metadata, which is consistent but does not extend beyond what annotations convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the clear purpose and followed by ecosystem context. No unnecessary words, but the second sentence could be considered tangential for a search tool definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and the description explains what returns, the tool is adequately documented. It misses potential edge cases like handling of query format or empty results, but for a simple search tool with one parameter this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the parameter description identical to the tool description's mention ('Search by token symbol, name, or mint address'). The description adds no new semantic information beyond the schema, so the baseline is 3 but with no added value it falls to 2.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Search for tokens' and the resource 'tokens by symbol, name, or mint address'. It distinguishes from sibling tools like jupiter_getTokenInfo and jupiter_getTokenList by focusing on search rather than exact lookup or full list retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes SAP MCP context about using Jupiter tools for quote/route preparation before SAP transaction tools, but does not explicitly guide when to use searchTokens versus alternatives like getTokenInfo or getTokenList. The guidance is more about workflow integration than comparative usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations show readOnlyHint=false and openWorldHint=true, but description adds no behavioral details beyond 'Create'. No mention of permissions, side effects, or on-chain complexity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states core purpose, second provides SAP context. No wasted words, front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite high parameter count (11) and no explanation of DLMM or prerequisites, the description is too minimal. Output schema existence doesn't compensate for missing usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema provides 100% parameter coverage with descriptions. Description adds no extra meaning beyond schema fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Create a Meteora DLMM pool' using specific verb and resource. Distinguishes from sibling tools like meteora_createDynamicPool and meteora_addDLMMLiquidity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides SAP MCP context and explicitly names alternative tools (sap_agent_identity_plan, etc.) for on-chain registration. Does not compare directly to other pool creation methods but gives relevant guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the 'immutable' trait, indicating permanence, which is useful beyond annotations. However, it does not disclose side effects, required permissions, or whether the action is reversible. Annotations provide minimal behavioral info, so the description partially compensates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence that front-loads the action. It is efficient, though it could benefit from including more contextual details without being wordy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (sealing a ring buffer), the description is minimal. It does not explain the state of the ring buffer after sealing, whether the room remains usable, or what the output schema contains. More details would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description does not expand on parameter details. Each parameter is adequately described in the schema, so the description adds no additional semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('Seal') and resources ('chat ring buffer', 'immutable SAP ledger page') to clearly indicate the tool's function. It distinguishes from sibling tools like sap_chat_send_message or sap_chat_start_room by focusing on finalizing history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for making chat history permanent but does not explicitly state when to use this over alternatives, nor does it provide exclusions or prerequisites. The context hints at a one-time action, but guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations set readOnlyHint=false, but decoding a transaction is inherently read-only. The description does not clarify this contradiction or mention any side effects, error conditions, or limitations. It only says 'return stable transaction metadata'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently convey purpose and usage. Every sentence adds value; no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the essential purpose and usage context for a simple decode tool with full parameter descriptions and an output schema. Lacks details about what 'stable transaction metadata' includes, but output schema can fill that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 mentions 'transactionBase64' as input, which aligns with the encoding enum, but adds no extra semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it decodes a serialized Solana transaction and returns stable transaction metadata. Provides context about when to use it, but does not explicitly differentiate from similar decode/preview tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this before signing when a SAP MCP, Jupiter, MagicBlock, SNS, Metaplex, or DeFi tool returns transactionBase64 or an unsigned transaction.' This gives clear context and triggers, though it does not state when NOT to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation ('score'), but annotations set readOnlyHint=false, indicating side effects. The description does not disclose that scoring likely writes a transaction or modifies state, contradicting the annotations. This is a critical omission.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first directly states the purpose, the second adds usage context. No extraneous information, front-loaded effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks essential behavioral context (write vs read) and side effects. Despite having an output schema, the description omits whether the call is mutable, which is critical for the agent to decide usage. The annotations are insufficient to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters with descriptions (100% coverage). The description adds value by emphasizing verification of the agent parameter and stability of metadata, which is not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Score an agent') and the resource ('using SDK FairScaleRegistry.score'), and adds SAP MCP context that distinguishes it from siblings like sap_fairscale_trust_gate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage guidance: 'Use after verifying the target agent PDA or wallet and keep hashes/attestation metadata stable and auditable.' No explicit alternatives or when-not-to-use, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=false, openWorldHint=true, etc. The description adds context about reputation/trust flow and metadata stability, but does not fully disclose behavioral traits (e.g., side effects, state changes) beyond what annotations indicate. It adds some value but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core action, and contains no fluff. Every sentence adds necessary context, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description covers purpose and usage context well. With an output schema available, it does not need to detail return values. However, it could mention the outcome of 'passing the gate' and how it fits into the broader SAP workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented. The description does not add significant extra meaning beyond the schema, such as clarifying expected formats or valid ranges. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Evaluate' and the resource 'agent with SDK FairScaleRegistry.trustGate,' and provides context about reputation and trust flow. It is specific but does not explicitly distinguish from the sibling tool 'sap_fairscale_score,' which likely has a similar focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a precondition ('after verifying the target agent PDA or wallet') and a caution ('keep hashes/attestation metadata stable and auditable'), implying when to use. However, it does not mention alternatives or when not to use, such as compared to 'sap_fairscale_score.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate write operation (readOnlyHint=false) and nondestructive. Description adds security guidance: 'Store only intentionally encrypted payloads or public hashes; session and vault PDAs are visible on-chain metadata,' which warns about data visibility. This goes beyond annotations. No contradiction found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences plus a brief security note. Information is front-loaded with the primary action. Could be slightly more structured, but no unnecessary content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists so return value is handled. For a session-start tool, additional context about lifecycle (e.g., subsequent tool usage or failure conditions) would be helpful but not strictly required. Adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage of 2 parameters with descriptions. Description does not add extra meaning beyond the schema, such as format constraints or usage examples for vaultNonce. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Start a high-level SDK session by session ID' with a specific verb and resource. It includes 'SAP MCP context: Memory/session flow' which helps distinguish it from sibling tools like sap_open_vault_session, though the term 'high-level SDK session' could be more precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage through context ('Memory/session flow'), but no explicit guidance on when to use this tool vs. alternatives like sap_open_vault_session. No 'when not to use' or prerequisite conditions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, idempotentHint) already convey the read-only, idempotent nature. Description adds 'using the Bonfida SDK' but provides no additional behavioral context. Adequate but doesn't extend beyond structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundant words, concise and clear. Every word is meaningful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool and the presence of an output schema, the description is sufficient. Could mention output format briefly, but not necessary. No missing critical context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for all three parameters. Description does not add extra 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly specifies the action ('check whether a wallet owns a .sol domain') and the resource (ownership). It distinguishes itself from sibling SNS tools that handle registration, resolution, or record management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 (e.g., sap_sns_resolve_domain or sap_sns_get_record). Missing context about prerequisites or scenarios where ownership check is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint=false. The description adds no additional behavioral details (e.g., whether it involves an RPC call, cost, or side effects). 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words. It is efficiently front-loaded with the key action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low parameter count, high schema coverage, and presence of an output schema, the description adequately explains the tool's purpose. It could mention the return type or usage context, 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.
Parameters3/5
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 'domain'. The tool description adds no extra meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Derive'), the resource ('SNS domain PDA'), and the specific domain type ('.sol domain'). This distinguishes it from sibling tools like `sap_sns_get_record_pda` which derive a different PDA.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., when to use this instead of `sap_sns_resolve_domain`). The description lacks context on prerequisites or complementary tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the tool's safety profile is clear. The description adds that it uses 'SAP SDK SnsModule' but provides no extra behavioral context (e.g., whether it works for unregistered domains, error cases). 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence with no extraneous information. It efficiently conveys the tool's core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 parameters, output schema present), and annotations cover behavioral aspects. The description is brief but sufficient for a derivation operation. However, it could improve by clarifying how it differs from fetching an existing record PDA.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters having clear descriptions. The description does not add additional meaning beyond what the schema provides, so baseline score 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool derives an SNS record PDA given a domain and record type. It uses a specific verb 'derive' and identifies the resource (PDA). Among sibling SNS tools like sap_sns_get_domain_pda, this uniquely targets record-level PDAs, differentiating it adequately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as sap_sns_get_record (which might fetch existing records) or sap_sns_resolve_domain. The description does not specify prerequisites or exclusions, leaving the agent to infer usage context from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: it states the tool 'pays entry fee via transaction,' indicating a financial cost. Annotations set destructiveHint=false, but the spending nature is disclosed. However, it does not detail post-game outcomes or irreversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat verbose and includes extraneous information ('SAP MCP context: Protocol send-arcade; operation class write'). It can be shortened without losing meaning. The core purpose is clear but padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks guidance on return values (although an output schema exists), error handling, or prerequisites like wallet funding. For a game-playing tool involving transactions, more completeness about flow and consequences is expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and all three parameters ('gameId', 'wallet', 'betAmount') have descriptions in the schema. The tool description adds no further parameter details beyond the schema, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Enter and play a game on Send Arcade (pays entry fee via transaction).' It specifies a verb ('enter and play') and a resource ('game on Send Arcade'), and it distinguishes itself from the sibling tool 'send-arcade_listGames' which lists games.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for when to use the tool ('Use for Send Arcade game listing and play flows') and includes a cautionary note ('Confirm account, wager or spend, and game rules before writes'). However, it does not explicitly state when not to use it or provide alternatives beyond the sibling tool list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=false, destructiveHint=false. The description adds that it returns an unsigned transaction, implying the agent must sign and submit separately. This goes beyond the annotations, though it lacks details like idempotency or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is several sentences, starting with the core action but including some redundant phrases (e.g., 'SAP MCP context'). It could be more concise by focusing on the essential purpose and return value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of deploying a token (10 parameters, output schema present), the description is incomplete. It does not explain prerequisites like rent-exempt balance, default handling for decimals/isMutable, or error conditions. The output schema existence reduces burden but core setup steps are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with clear parameter descriptions. The tool description adds no extra parameter semantics beyond restating the tool's purpose. With full schema coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deploys a new SPL token with Metaplex metadata, and returns the mint address and unsigned transaction. This specific verb-resource-action distinguishes it from sibling tools like spl-token_transfer or spl-token_mintTo.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists general use cases ('deploy, mint, transfer...') but does not specify when to use this tool versus alternatives, nor does it give explicit exclusions or prerequisites. The caution 'Confirm mint, decimals... before writes' 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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior1/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds no additional behavioral details (e.g., data freshness, rate limits) 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short with two sentences. The first sentence provides the core purpose. The second sentence is about SAP context and unrelated to the tool's functionality, which slightly dilutes conciseness. Overall, it is reasonably concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, has output schema), the description is largely adequate. It explains the purpose but could elaborate on what 'tip percentile estimates' mean. The output schema likely covers return details, so completeness is high.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, and schema description coverage is 100%. The description does not need to add parameter meaning, but it also does not explicitly note the absence of 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get current Jito tip percentile estimates for bundle inclusion priority.' This accurately describes the tool's function and distinguishes it from sibling tools like jito_sendBundle and jito_getBundleStatus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes context about when to use SAP tools for on-chain registration, but does not provide explicit guidance on when to use this tool versus alternatives like other Jito tools or tip-related services. The usage is implied but not clearly differentiated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. Description adds no new behavioral insights beyond stating the query nature. No contradiction, but also no 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with the first directly stating the tool's purpose. The second sentence provides ecosystem context that may be helpful but is not specific to this tool. Overall concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 comprehensive annotations, the description is sufficient for understanding the tool's core function. However, it does not differentiate from similar query tools in the sibling list, which could be improved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 8 parameters have descriptions in the schema, achieving 100% coverage. The description does not provide any additional semantic clarification beyond what the schema already states, so it meets the baseline but adds nothing extra.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves DCA orders for a wallet, specifying active and optionally historical. This action is distinct from sibling Jupiter tools like jupiter_cancelDCA or jupiter_createDCA.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description includes context about SAP MCP and Jupiter tools as AgentKit ecosystem, but does not explicitly tell the agent when to use getDCAOrders versus other query tools like jupiter_getLimitOrders or jupiter_getOrder. It implies read-only use but lacks direct alternatives comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. Description adds 'including USD valuations' and SAP context, which are helpful but not critical behavioral details 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, efficient and front-loaded with purpose. Second sentence is somewhat tangential but not harmful; loses a point for minor extraneous context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 adequately covers purpose and includes USD valuations. Could mention that it queries Solana token accounts, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage for all parameters. Description repeats the schema's intent but does not add new meaning or usage details beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool fetches token balances and holdings for specific accounts, including USD valuations. This distinguishes it from sibling Jupiter tools like jupiter_getQuote or jupiter_getPrice.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context about being part of a larger workflow (quote/route/swap with SAP tools) but does not give explicit guidance on when to use this tool versus other Jupiter read tools like jupiter_getTokenInfo.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool is a read operation and requires no authentication, but there is a contradiction with the annotation 'readOnlyHint: false'. The description itself is clear, but the inconsistency with annotations reduces trust.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys the core purpose. It is concise, though there is a minor typographical error (double period at the end).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (read operation, 3 parameters, no nested objects, and an output schema exists), the description adequately covers the essential context. It lacks details on output format or errors, but these are partially covered by the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are well-documented in the schema. The description adds no additional parameter details beyond what is already stated, hence a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads the base-chain SPL token balance for an address, which is a specific verb+resource combination. It distinguishes itself from sibling tools like magicblock_privateBalance by specifying 'public' and 'no auth required'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for public balance queries by noting 'public, no auth required', but does not explicitly state when to use this tool over alternatives like magicblock_privateBalance or other balance-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds that write operations require enabled signer mode and MCP policy approval, which is valuable context 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose, second adds context and requirements. No unnecessary words, front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description covers purpose, prerequisites, and context. Output schema is present. However, lacks details on error conditions or side effects of cancellation. Adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage for both parameters (subId, agentWallet). The description does not elaborate on parameter meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool cancels a recurring subscription. It adds SAP MCP context but does not explicitly distinguish from other subscription tools like create_subscription or fund_subscription. The verb 'Cancel' and resource 'recurring subscription' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides guidance such as 'Estimate or fetch state before creating escrows or settling calls' and prerequisites like enabled signer mode and MCP policy approval. However, it lacks explicit when-not-to-use or comparison with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-read-only, non-destructive, non-idempotent. The description adds no further behavioral context such as side effects, permissions, or rate limits. Neutral, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, clear sentence with no wasted words. Front-loaded with the core action and audience.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 10 parameters (including nested objects) and an output schema, the description is minimal. It covers the main purpose but lacks details about manifest structure or signed nature. Adequate but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are fully defined in the schema. The description does not add additional meaning or examples beyond what's in the schema, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'publish' and the resource 'signed thematic room/group manifest', specifying the target audience. It distinguishes from sibling tools by focusing on publishing a manifest rather than reading, sending, or starting rooms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
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 sap_chat_start_room or sap_chat_send_message. The purpose is clear but omits exclusions or context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims 'Read-only SAP SDK wrapper' but the annotation readOnlyHint is false, directly contradicting the claim. This is a serious inconsistency that 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (three sentences) with no wasted words, delivering purpose, usage guidance, and context efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple check tool with an output schema, the description covers purpose, usage context, and relationship to other tools, making it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter, and the description does not add significant extra semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a 'Free exact activity check for an owner wallet' and distinguishes it from paid discovery tools, providing a specific verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using this tool 'before paid discovery when the wallet is known' and provides context for read-only checks before mutations, but does not name specific alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate mutation (readOnlyHint=false) and non-destructive nature. Description adds confirmation context but omits details on what the request entails (e.g., transaction submission or pending state creation).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences are efficient and front-loaded: purpose, context, then guidance. No extraneous words; every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, return value omission is acceptable. However, the description lacks detail on the overall flow (e.g., subsequent steps like sap_complete_unstake) and could better address the protocol's sequential nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover both parameters fully (100% coverage), so baseline is 3. Description adds no extra 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Request unstake for an agent wallet,' specifying the verb (request unstake) and resource (agent wallet). It also provides SAP protocol context and distinguishes from external AgentKit staking tools, ensuring no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises confirming wallet, amount, and timing before writes and notes distinctness from external tools, but does not specify when to use this tool versus internal siblings like sap_complete_unstake, leaving room for confusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds valuable behavioral detail: 'Resolves V2 first, then V1 fallback,' which is beyond the annotations (readOnlyHint, idempotentHint). 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Relatively concise with two functional sentences and a general note about write operations. The note is slightly extraneous for this read-only tool, but the core information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Combined with the output schema, the description covers the main behavioral aspects (fallback, usage context). Could mention idempotency or safety, but those are covered by annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 3 parameters. The description does not add new parameter information beyond what the schema already provides, so scores at baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fetch raw x402 escrow account data') and the SDK method used. It distinguishes from siblings by specifying the x402 namespace and raw data, but doesn't explicitly differentiate from the similar sibling sap_fetch_escrow_v2.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context: 'Estimate or fetch state before creating escrows or settling calls.' This implies when to use, but there are no explicit exclusions or alternatives listed, leaving the agent to infer usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds key behavioral context beyond annotations: it explains the effect ('prevents all transfers') and the authority requirement. Annotations already indicate a write operation (readOnlyHint=false), and the description aligns. However, it does not mention reversibility or state transitions, which would 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The first sentence is concise and front-loaded. However, the description includes redundant boilerplate about 'SAP MCP context' and generic warnings about confirming values, which add length without specific value. It could be more focused.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (3 required parameters, no enums) and presence of an output schema, the description is adequate but lacks details on edge cases (e.g., already frozen accounts) or side effects. It does not reference related tools like thawAccount, which would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with clear descriptions for each parameter (mint, account, freezeAuthority). The description does not add additional parameter-level detail beyond what the schema 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Freeze a token account (prevents all transfers).' This is a specific verb and resource, and it distinguishes the tool from siblings like thawAccount and transfer, which have opposite or different behaviors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Requires freeze authority' as a prerequisite but does not explicitly guide when to use this tool over alternatives like thawAccount or when freezing is appropriate. The generic advice about token operations and SAP context does not provide specific selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds a note to confirm before writes but does not elaborate on side effects, state changes, or other behavioral traits beyond what annotations provide. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences long, front-loaded with purpose and context. It is relatively concise but includes some redundancy (e.g., 'SAP MCP context: Protocol staking; operation class write'). Still, every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema (not shown but indicated), the description covers purpose, usage, safety, and alternative tool groups. It is complete for a write tool, though it could briefly mention the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema already describes both parameters (amount and wallet) sufficiently. The description does not add additional parameter-specific context or semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Stake', resource 'SOL', and destination 'sSOL via Solayer', distinguishing it from other staking tools like staking_stakeJupSOL and staking_stakeSOL. It also mentions it's a re-staking protocol with additional yield.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use for SOL and liquid staking flows' and provides pre-write checks. It also distinguishes from SAP staking tools and AgentKit staking tools, offering guidance on when to use this tool versus alternatives. However, it doesn't elaborate on when not to use it or specific sibling exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness3/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive=true, so the description's mention of 'on-chain execution' aligns but adds minimal behavioral detail (e.g., no side effects or failure modes). 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first clearly states the primary purpose, the second adds important context. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's role within the larger Jupiter/SAP ecosystem and mentions the output schema exists. It could briefly mention prerequisites (e.g., having a signed transaction) but is otherwise sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for both parameters. The description does not add additional semantic meaning beyond what the schema already specifies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Submit a signed limit-order transaction for on-chain execution') and distinguishes it from sibling tools that deal with creating or canceling orders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on the Jupiter protocol workflow and SAP MCP signer policy, but it does not explicitly differentiate this tool from other Jupiter execute tools (e.g., jupiter_executeOrder, jupiter_executeDCA) regarding when to use each.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint true, and destructiveHint false, so the safety profile is clear. The description adds that it returns token metadata, organic score, price, and audit info, providing extra behavioral context beyond annotations. No contradiction (annotation_contradiction false).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first effectively states the function, the second provides SAP ecosystem context. While not verbose, the SAP context is extraneous for this specific tool and could be placed in a general note. The important line is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one optional enum parameter, output schema exists), the description is fairly complete. It covers purpose, return fields, and ecosystem context. Schema and annotations cover the rest. No major gaps for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with explicit descriptions for the single parameter (query enum). The description adds no new information about the parameter meaning, only about the output. Baseline 3 is appropriate as the schema already documents parameters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Get', resource 'Jupiter tokens', and filter by tag ('verified' or 'lst'). It lists return fields (metadata, organic score, price, audit info), distinguishing it from siblings like jupiter_getTokenInfo (single token) and jupiter_searchTokens (search).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions using Jupiter tools for quote/route/swap preparation and then SAP transaction tools, which provides general context but does not explicitly state when to use this tool versus siblings. Implied usage is for obtaining token lists before swaps, but no exclusions or comparisons are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld, and non-destructive. Description adds the constraint 'max 100' accounts and specifies the return values (blockhash and last valid block height), providing useful behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with key action. No wasted words. Minor typo (double period) does not detract from conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple with 2 parameters and output schema exists. Description covers purpose and a key constraint. Could optionally explain the use of blockhash, but sufficient for a read-only query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. Description repeats schema info ('batch of account addresses (max 100)') but adds no new semantic detail about parameter usage or edge cases.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states the action 'Get a blockhash and last valid block height for a batch of account addresses', with a clear verb and resource. It distinguishes from sibling magicblock_get* tools (e.g., getAccountInfo, getDelegationStatus) by specifying the unique output and input constraint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 other magicblock_get* tools. No mention of prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims it is a lightweight read tier, implying no side effects, but annotations set destructiveHint=true, indicating potential destructive effects. This is a direct contradiction that misleads the agent about behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, direct and front-loaded with the tool's purpose and usage. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema (not shown but present), so return values are covered. The description provides context about being a proxy for an underlying API and its relation to magicblock_swap. Minor deduction due to the annotation contradiction affecting overall trust, but the description itself is complete for a read-tier tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description does not add meaningful new information beyond the schema, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches a swap quote between two SPL mints and explicitly mentions it is a proxy for the Triton Metis swap API. It also directs to pass the result into magicblock_swap, distinguishing its purpose from that sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says use this before any value-moving swap and pass the result into magicblock_swap. It also calls itself a lightweight read tier, indicating when to use it. This clearly guides the agent on when to invoke this tool versus alternatives like magicblock_swap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, which are consistent with a write delegation. The description adds value by listing authority types and prerequisites, but lacks details on whether delegation is additive or replaces existing delegates, and whether the current authority remains valid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph mixing purpose, context, and a separate agent workflow. Some phrases like 'SAP MCP context...' are redundant given annotations. It could be more structured and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (4 required params, output schema exists), the description covers usage context, prerequisites, and a high-level workflow for agent use. It lacks return value description, but output schema presumably covers that, so this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with all four parameters described in the schema. The description merely lists the authority types already in the schema and the prerequisite fields, adding no new parameter-level insight beyond what the schema provides. Baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Delegate' and the resource 'specific authority', listing the four types (update, mint, freeze, collection). It distinguishes from sibling tools like revokeAuthority and verifyCreator by specifying the action and scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use context ('Use for Metaplex NFT collection... workflows') and prerequisites ('Confirm metadata URI... before writes'). It also outlines related tool sequence for agent identity, but does not explicitly contrast with alternative delegation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral details beyond annotations, such as 'requires creator's signature' and 'operation class write,' which are not captured in the annotations (readOnlyHint=false, dangerousHint=false). 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is unnecessarily verbose, including extraneous context about SAP MCP and agent identity. It front-loads the purpose but contains redundant information that could be streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the existence of an output schema (though not shown), the description provides essential behavioral and prerequisite information. However, it lacks explanation of return values or error conditions, leaving gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions ('NFT mint address (base58)', 'Creator wallet to verify'). The description does not add further semantics beyond the schema, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Verify a creator on an NFT's metadata (requires creator's signature).' It uses a specific verb-resource combination and distinguishes from sibling tools like metaplex-nft_verifyCollection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use (e.g., Metaplex NFT workflows, creator verification) and includes prerequisites ('Confirm metadata URI, collection mint, creators, royalties...'). It does not explicitly state when not to use or contrast with alternatives, but the guidance is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false (mutating) and destructiveHint=false. The description adds that it creates a vault with vesting but does not disclose authorization requirements, potential side effects, or non-idempotent behavior. It provides adequate but not deep transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is composed of two sentences, with the first covering the core purpose and the second adding valuable SAP context. While concise, the SAP guidance could be slightly streamlined or moved to a separate note. No wasted words, but the context is relevant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (launching a vault with vesting), the description is minimal. It does not explain the vault lifecycle, parameter relationships, or output schema. However, the presence of a schema and annotations partially compensates. An agent familiar with Meteora might find it acceptable, but newcomers may need more detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add any additional meaning or usage notes beyond what the parameter descriptions already provide, such as the format of timestamps or constraints on deposit caps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description includes a specific verb ('Create'), resource ('Meteora Alpha Vault'), and purpose ('fair token launches with vesting'). This clearly distinguishes it from sibling tools like meteora_createDynamicPool and meteora_createDLMMPool, which focus on different pool types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context about SAP MCP and directs which sibling tools to use for on-chain registration steps. However, it does not explicitly state when to use this tool versus other vault creation tools, nor does it mention prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, etc. The description adds minimal discovery: 'Read-only SAP SDK wrapper against the configured Solana RPC and SAP program.' It confirms the read-only nature but adds limited behavior 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence. It uses three sentences, the third being slightly verbose but still efficient. Every sentence adds value, though some repetition exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and an existing output schema, the description is fairly complete. It states the action, usage timing, and context. It does not list what the global state contains, but the output schema likely covers that. Minor gap in prerequisites but acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and the description implies a simple, parameterless call with 'Free compact global SAP registry state read.' Schema description coverage is 100% (empty schema), so baseline is 4. No further parameter details needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific language: 'free compact global SAP registry state read'. It clearly indicates the verb (read) and resource (global SAP registry state). However, it does not explicitly distinguish from sibling read tools like sap_network_stats or sap_fetch_protocol_index, leaving ambiguity about when to choose this over others.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context: 'Use for initial orientation before paid network analytics' and 'inspect current chain state before mutating...'. This gives a strong usage hint. However, it lacks explicit exclusions or alternatives, which would raise the score to 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include destructiveHint=false and readOnlyHint=false, but the description adds context by mentioning that the tool reloads client, signer, connection, and policy. However, it does not detail the extent of state changes or whether the switch is reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the main action and includes essential side effects. Every word contributes value, with no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a simple interface (2 parameters, no required ones, output schema present), the description is largely complete. It could be improved by explicitly stating that the profile must already exist in the runtime, but it is adequate for the given context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 both parameters. The description does not add additional meaning beyond what the schema provides, such as format or examples for 'profileName'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Switch' and the resource 'SAP MCP profile', and it distinguishes this from sibling tools like 'sap_profile_list' (list profiles) and 'sap_profile_current' (show current) by specifying that it switches the runtime and reloads components.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes that `confirm` must be true because the switch changes signer, network, and policy, which provides a usage constraint. However, it does not explicitly state when to use this tool vs alternatives, such as when only viewing the current profile is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-readOnly, non-idempotent, non-destructive. The description adds that it is a write tool requiring signer policy, but does not detail behavioral traits such as reversibility, side effects, or required permissions beyond the generic context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action. The second sentence provides useful but generic context. It is efficient with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 need not be explained. However, the description lacks specifics about prerequisites (e.g., agent must be deactivated first) and what changes occur on reactivation. It is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so the description cannot add parameter-level meaning. Baseline of 4 applies as no parameter details are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Reactivate the connected wallet SAP agent.' This verb+resource combination is specific and distinguishable from sibling tools like deactivate, register, update, and close. It leaves no ambiguity about the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes generic context about write tools requiring signer policy and active profile, but it does not explicitly specify when to use this tool versus alternatives (e.g., when an agent is deactivated). Usage guidance is implied by the name but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint, so safety profile is clear. The description adds that it returns a command and is a 'free helper', which is useful but not beyond what annotations cover. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, zero wasted words, and all information is front-loaded. Every sentence adds necessary context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 (not shown) and the simplicity of the tool (one optional parameter, read-only, idempotent), the description covers the essential behavioral aspects. It's complete enough for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning the parameter's description already explains it as 'Optional runtime to focus repair instructions on'. The tool description does not add further 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a pinned latest-release repair command for SAP MCP and local sap_payments bridge. The verb 'returns' and specific resources make the purpose clear. However, 'runtime repair' could be more precisely defined for unfamiliar users.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using this tool 'before asking users to manually edit runtime config', providing clear usage context. No alternatives are mentioned, but sibling tools don't include a similar repair function, so exclusion isn't necessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the description's 'check availability' aligns. However, description does not add additional behavioral context beyond the batch limit, such as rate limits, error handling, or what happens on partial failures. With annotations covering safety, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with 17 words, front-loaded with the main purpose. Every word adds value; no unnecessary details. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that output schema exists (covering return values), annotations handle safety, and parameters are fully described, the description is mostly complete. It includes the batch size limit. The only minor gap is lack of mention of error handling or partial results, but that is minor given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter description in the schema already explains the domains array (1-25 .sol domains). The tool description adds no new information about parameters beyond what the schema provides. Baseline 3 is correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (check availability), the resource (multiple .sol domains), and includes a specific limit (up to 25). It also mentions the SDK module. Differentiates from sibling tool sap_sns_check_domain by indicating batch operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for batch checking, but does not explicitly state when to use this tool vs alternatives like sap_sns_check_domain. No guidance on when not to use or prerequisites. The batch nature is clear but lacks contrast guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds that it uses the Bonfida SDK but does not disclose error handling or rate limits. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, 14 words, with no unnecessary information. Extremely concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, output schema exists), the description covers the essential purpose. Could mention error scenarios but output schema likely handles return format. Adequate overall.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters have descriptions. The description does not add additional 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Fetch', the resource 'single SNS record value', and the context '.sol domain using the Bonfida SDK'. It distinguishes from sibling tools like sap_sns_get_domain_records and sap_sns_get_record_pda.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for fetching a single record but does not explicitly provide when to use vs alternatives or exclude cases. No comparison with other SNS tools is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate write operation and non-idempotent. Description adds authorization requirements ('enabled signer mode and MCP policy approval') and hints at SDK interaction, providing context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description has 4 sentences, front-loaded with the main action, but contains some vague phrases ('SAP MCP context: Payment and settlement flow') that add little value. Not overly long but could be more succinct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (10 parameters, presence of output schema), the description provides reasonable context: overall flow (payment/settlement), prerequisite actions, and authorization needs. Output schema likely explains return values, so this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema documents all 10 parameters. The description only vaguely references 'nonce-aware flows' but adds no specific parameter details. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Prepare an x402 payment context' using a specific SDK method. It adds domain-specific guidance about new production escrow funding, but does not explicitly differentiate from sibling tools like sap_x402_settle_batch or sap_x402_fetch_escrow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides usage guidance: 'Estimate or fetch state before creating escrows or settling calls' and 'write operations require an enabled signer mode and MCP policy approval.' It implies sequencing but does not directly compare with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness3/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint: true, and description does not add significant behavioral context beyond 'submit a signed transaction'. No mention of side effects, success/failure outcomes, or non-idempotence (idempotentHint: false), so description adds minimal value over annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently convey the core purpose and ecosystem context. The second sentence, while providing useful workflow context, could be considered slightly extraneous for a single tool description, but overall it is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description covers the tool's role in the DCA workflow and mentions the broader Jupiter/SAP tool ecosystem. However, it does not explicitly state that a DCA order must first be created via jupiter_createDCA to obtain a requestId, nor does it explain the signing step. Output schema exists but was not provided; description still has some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both parameters ('Request ID from createDCA response' and 'Base64-encoded signed transaction'). Description adds no additional parameter meaning, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb (submit) and resource (signed DCA transaction). It distinguishes from sibling tools like jupiter_createDCA (which creates the order) and jupiter_cancelDCA by specifying it handles the submission of signed transactions for both creation and cancellation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides ecosystem context about using Jupiter tools for preparation and SAP tools for unsigned transactions. However, it does not explicitly differentiate from other Jupiter execution tools (e.g., jupiter_executeOrder) or state prerequisites like needing a requestId from jupiter_createDCA.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, and the description adds that it returns instructions for signing, but does not detail side effects, fees, or failure modes beyond what annotations suggest.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded and efficient, though could be slightly tighter; the SAP MCP context adds helpful but somewhat redundant guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity and presence of an output schema, the description covers the main workflow, inputs, and next steps (assembly/ signing), but omits error handling or prerequisite checks.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 only mentions a few parameters (input/output mints, amount, wallet) without adding new semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines it as a compound tool that fetches a quote and builds swap instructions in one call, distinguishing it from siblings like jupiter_swap and jupiter_swapInstructions by being the recommended entry-point.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states required inputs and how to use the output (assemble into a transaction), and provides SAP MCP context for workflow integration, but does not explicitly list when not to use this tool vs. alternatives like jupiter_getQuote.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is not read-only and not destructive. The description adds 'step 1 of the PER auth flow' but does not disclose side effects or state changes beyond what annotations suggest.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. Minor formatting issue with trailing double period, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple and has an output schema. Description explains the role in the auth flow and the output's purpose, sufficing for a one-step tool. Could mention next steps but not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 provide additional meaning beyond the schema's parameter descriptions; it only restates that the wallet will sign.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool generates a challenge string for wallet signing, identifying it as step 1 of the PER auth flow. This is specific and distinguishes it from siblings like magicblock_login.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context ('step 1 of the PER auth flow') indicating when to use this tool, but does not explicitly mention exclusions or alternatives. Clear usage context is present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint. Description adds 'via the Magic Router' but doesn't disclose other 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with key information, no redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, description adequately covers the tool's purpose and parameters. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description does not need to add parameter semantics. It lists returned fields but not parameter details, so it meets baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Fetch' and the resource 'account information', specifying the data fields. It distinguishes from sibling tools like magicblock_balance by focusing on full account info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
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 magicblock_balance. Usage is implied but not contrasted with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds that it returns authority, owner, delegation slot, and lamports, but this is likely covered by the output schema. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action. It is concise and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 does not need to detail return values. It adequately covers the purpose and behavior, though it could mention any prerequisites or edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 does not add any additional parameter-level details, meeting the baseline for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the verb 'Check' and the resource 'Solana account delegation status'. It clearly distinguishes from sibling MagicBlock tools like balance or getAccountInfo by focusing on delegation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While no explicit when-to-use vs alternatives is given, the description clearly implies its use for checking delegation status. Given the self-explanatory nature, it's sufficient to guide an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive. Description adds no new behavioral context beyond 'check', which is consistent 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, 12 words, perfectly front-loaded and efficient with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given existence of output schema and simplicity of tool, description fully covers what the tool does without needing return value explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage; description does not add meaning beyond the parameter descriptions already present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'check' and resource 'confirmation status' with specific states (processed/confirmed/finalized). Distinguishes from other magicblock tools by specifying the unique action on transaction signatures.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use or avoid, but the context implies usage for checking status. No alternatives mentioned or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate write operation (readOnlyHint=false) and no destruction. Description reinforces this with 'Update NFT metadata', warns about confirming authority and ownership, and mentions authority workflows. This adds useful behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose but includes lengthy SAP MCP context that may not be essential for all agents. Some sentences are broad (e.g., 'Use for Metaplex NFT collection... workflows') and could be trimmed for clarity. Adequate but not maximally efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has many parameters and an output schema (not shown but indicated), the description covers prerequisites, confirmation steps, and use cases. It provides sufficient context for an agent to use the tool correctly without missing critical information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing baseline. Description adds value by grouping key parameters (name, symbol, URI, creators, royalties, authority) and giving usage hints like 'Confirm metadata URI, collection mint, creators, royalties, update authority, and ownership before writes.' This contextualizes the parameters beyond the schema's generic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update NFT metadata fields' with a list of fields, indicating a write operation on metadata. It distinguishes from sibling tools like mintNFT or deployCollection through the specific verb 'update', but does not explicitly differentiate itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context on when to use (for agent identity, NFT collection needs) and prerequisites (plan with sap_agent_identity_plan, register SAP profile). Includes verification steps before writes. However, lacks explicit when-not-to-use or direct comparison to alternatives like verifyCreator.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds important behavioral context beyond annotations: warns that 'session and vault PDAs are visible on-chain metadata' and clarifies what data should be stored. Annotations (readOnlyHint=false, openWorldHint=true) are consistent, and description provides extra safety guidance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose, second gives context and warning. No filler, front-loaded, efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a tool with output schema and annotations. However, the concept of 'inscribe memory' might be unclear without additional context about the SAP protocol. Sibling 'sap_inscribe_memory' could provide more, but this description alone is somewhat minimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 5 parameters. The description does not add per-parameter details beyond the schema, but provides an overarching security note. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Compact memory inscription with explicit vault/session PDAs.' It specifies the resource (memory) and action (inscribe) and distinguishes from sibling 'sap_inscribe_memory' by being 'compact' and requiring explicit PDAs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context: 'SAP MCP context: Memory/session flow' and a guideline: 'Store only intentionally encrypted payloads or public hashes.' However, it does not explicitly state when not to use this tool or mention alternatives like 'sap_inscribe_memory'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. Description adds 'Free' and 'exact' and mentions it's a read-only SDK wrapper, reinforcing safety. No contradictions and adds marginal context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: purpose, usage, broader context. Front-loaded with key functionality. Efficient without waste, though could be slightly tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given simple tool with one param, existing output schema, and rich annotations, description covers purpose, usage, and read-only context. Lacks details on edge cases (missing wallet) but adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage and describes 'wallet' as Solana public key. Description only repeats 'by owner wallet' without adding extra semantics or format details. Baseline 3 maintained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it reads an SAP agent profile by owner wallet. Distinguishes from sibling tools like sap_profile_current (current user) and sap_profile_list (all). Explicit verb+resource+scope: 'Free exact SAP agent profile read by owner wallet'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly guides to use for a known agent before paid discovery or enrichment. Also mentions using reads to inspect chain state before mutations. Does not list exclusions or alternatives, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false; description adds minimal extra behavioral context like 'using SAP SDK SnsModule' but no error handling or edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no fluff, front-loaded with key action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, read-only, idempotent) and existence of an output schema, the description adequately covers necessary context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameter description; the tool description adds no new 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Check' and resource '.sol domain availability', distinguishing it from sibling tools like registration or batch check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking a single domain's availability, but lacks explicit when-to-use vs alternatives (e.g., batch check) or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a write operation (readOnlyHint=false, destructiveHint=false). The description adds context about confirming validator, amount, and ownership before writes, but this is more cautionary than behavioral disclosure. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with the key action first. It includes protocol context and usage notes without excessive verbosity. Could be slightly more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simple two-parameter staking operation), the description covers the purpose, usage context, and necessary precautions. An output schema exists (not shown) to explain return values. Adequately complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for both parameters. The description does not add significant meaning beyond the schema, which already describes wallet as 'Solana public key (base58)' and stakeAccount as 'Stake account to deactivate and withdraw'. The confirmation advice is tangential.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Deactivate and withdraw SOL from a stake account' with a specific verb and resource. It distinguishes this from sibling tools like staking_stakeSOL and staking_getStakeAccounts by focusing on unstaking SOL.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use this tool ('For SOL and liquid staking flows') and suggests verifying terms before use. It differentiates between SAP staking tools and AgentKit staking tools, but does not explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=false and destructiveHint=false. The description adds that it is a write operation and warns to confirm terms, but does not disclose other behavioral traits like error handling, side effects, or response specifics. The existing output schema mitigates some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with 4 sentences, front-loading the primary purpose. It could be slightly more efficient by merging the warning sentence, but overall it is appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 covers the operation's context, including usage flows and precautions. It does not explain prerequisites like sSOL balance, but the overall completeness is sufficient for a write tool with schema support.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters with complete descriptions (amount and wallet). The description does not add additional parameter details beyond what the schema provides, so it meets the baseline for 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Unstake sSOL back to SOL via Solayer', providing a clear verb (unstake) and resource (sSOL to SOL). It distinguishes from siblings like staking_unstakeSOL (for regular SOL) by specifying 'via Solayer'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using this tool for SOL and liquid staking flows and instructs to use SAP staking tools for SAP protocol accounts and AgentKit for external protocols. However, it does not explicitly compare with sibling unstake tools like staking_unstakeSOL or staking_unstakeJupSOL, which are more directly related.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds key behavioral context beyond annotations by stating that the tool creates an 'unsigned transaction,' meaning it does not directly cancel the order but prepares a transaction for later signing. This is valuable given destructiveHint=true, as it clarifies the mutation is deferred.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences. The first sentence delivers the core purpose, and the second provides ecosystem context. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity and the presence of an output schema, the description adequately covers the essential outcome ('unsigned transaction'). However, it could briefly note that the order must be owned by the provided user wallet to improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema already describes all parameters sufficiently. The description adds no additional semantic value for the parameters (e.g., explaining the enum values or the optional computeUnitPrice).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 an unsigned transaction to cancel a DCA recurring order.' It uses a specific verb ('cancel') and resource ('DCA recurring order'), effectively distinguishing it from sibling tools like jupiter_cancelLimitOrder which cancel limit orders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide specific guidance on when to use this tool versus alternatives. The SAP MCP context note is generic for all Jupiter tools and does not help differentiate from siblings like jupiter_cancelLimitOrder. No prerequisites or use-case scenarios are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare non-read-only, open world, non-idempotent, non-destructive. Description adds 'deposit' (mutating) and aggregator context, but no additional behavioral details such as side effects or authorization needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states core purpose, second provides crucial integration context. No redundant information, efficiently front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given full schema coverage and output schema existence, the description covers the essential purpose and integration context. Lacks details on output format but output schema handles that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% per context signals, so baseline is 3. Description does not add extra meaning beyond what the schema provides for wallet, mint, and amount.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states action 'Deposit' and resource 'best APR lending protocol via Lulo aggregator'. Distinguishes from sibling deposit tools by specifying the aggregator and yield focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for depositing into Lulo for best APR, and provides SAP context for when to register the tool on-chain. However, no explicit when-not or comparison with alternative deposit tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate write operation (readOnlyHint=false). Description adds beyond annotations: it only builds an unsigned transaction (not submitting it), explicitly lists required subsequent tools (sap_preview_transaction, sap_sign_transaction, sap_submit_signed_transaction), and mentions a builder fee. These details help the agent understand the tool's behavior and workflow.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences with no filler. The first sentence immediately states the purpose, and the second adds essential workflow and fee info. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 (describing return values), the description does not need to explain outputs. It covers the tool's purpose, workflow, and fee. However, it could mention prerequisites (e.g., whether mint exists) or refer to the sibling magicblock_isMintInitialized for checking initialization state. Still, it is mostly complete for the core function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage for all 4 parameters, providing clear definitions (e.g., mint, owner, cluster, validator). The description does not add extra parameter details beyond the schema, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds an unsigned transaction to initialize a validator-scoped transfer queue for a mint. It uses specific verb ('initialize') and resource ('transfer queue for a mint'), distinguishing it from other magicblock tools like magicblock_transfer or magicblock_deposit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by outlining the workflow (preview, sign, submit), but it does not explicitly state when to use this tool over siblings or provide exclusions. No comparison to alternative tools is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate the tool is not read-only, not idempotent, not destructive. The description adds context like 'unsigned', 'delayed settlement', 'split transfers', 'gasless mode', and 'private/public' visibility, which go beyond the annotations and clarify the tool's non-finalizing nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph of four sentences that covers the main purpose, features, and workflow without redundancy. However, it could be more scannable with structured sections for parameters or use cases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (20 parameters, optional features like split and delayed settlement), the description provides a solid high-level overview but does not fully explain parameter interdependencies or the mechanics of private transfers. An output schema exists, somewhat compensating for return value details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter described. The description adds some high-level grouping (e.g., 'base/ephemeral source and destination') but does not significantly enhance understanding beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds an unsigned SPL token transfer via Ephemeral Rollup, specifying verb ('Build'), resource ('unsigned SPL token transfer'), and unique context ('public or private', 'Ephemeral Rollup'). It distinguishes from sibling tools like spl-token_transfer by emphasizing the rollup and subsequent workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly indicates the follow-up tools (sap_preview_transaction, sap_sign_transaction, sap_submit_signed_transaction) to complete the transaction lifecycle. It also mentions builder fee, but lacks explicit guidance on when not to use this tool or specific exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, indicating safe, non-mutating behavior. The description adds context about being a 'routing resolver' for errors, but does not introduce new behavioral traits beyond what annotations provide. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two succinct sentences that immediately convey the tool's purpose and usage context. No unnecessary words or details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (6 parameters, no required, output schema present), the description covers the essential purpose, usage triggers, and error scenarios. The output schema handles return value documentation. Slight room for improvement could be mentioning output type, but overall sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for all 6 parameters (e.g., 'intent' enum, 'errorCode' values). The description does not add additional meaning beyond the schema, so a baseline score of 3 is appropriate. The description implicitly relates parameters to error handling, but no explicit parameter guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Free routing resolver for SAP MCP errors and partial results', specifying its role as a resolver for error conditions. It lists concrete error codes (e.g., payment_required, BlockhashNotFound) and scenarios (timeout, unconfirmed signature), making the tool's purpose distinct from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly directs agents to use this tool 'before retrying after' a list of specific errors and partial results (e.g., payment_required, timeout). This provides clear when-to-use guidance. It does not explicitly state when not to use it, but the positive context is strong enough to avoid misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context that confirmation is needed before writes, implying side effects. Annotations do not provide behavioral details, so the description adds value but lacks specifics on state changes or authorization.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with purpose, and contains no extraneous information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameter set and presence of output schema, the description adequately explains the tool's role in the SAP staking flow and distinguishes it from similar tools. Slightly more detail on prerequisites could be added, but it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter described. The description adds no additional parameter information beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'complete unstake' and the resource 'agent wallet', and distinguishes it from external AgentKit staking tools, 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises confirming agent wallet, amount, and timing before writes, and notes it is distinct from external tools. However, it does not explicitly list alternatives or when-not conditions beyond the sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=false, openWorldHint=true, etc., so the description's job is lighter. The description adds context about reputation/trust flow and metadata stability/auditability, which is useful but not extensive. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, no wasted words. First sentence states the main purpose, second sentence provides usage context. Highly efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of output schema and good annotations, the description is fairly complete. It covers purpose and usage context. Could be improved by mentioning error conditions or prerequisites more explicitly, but overall adequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers all 4 parameters with descriptions (100% coverage). The description does not add any parameter-specific details beyond the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create an on-chain attestation') and the target ('for an agent wallet'), with a clear verb and resource. It also provides context ('SAP MCP context: Reputation and trust flow') that distinguishes it from siblings like sap_revoke_attestation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: 'Use after verifying the target agent PDA or wallet and keep hashes/attestation metadata stable and auditable.' This gives a clear precondition. It does not explicitly list when not to use or alternative tools, but the sibling list implies alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds context about being a 'Read-only SAP SDK wrapper against the configured Solana RPC and SAP program,' which is useful but does not reveal additional behavioral traits beyond what annotations cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the action, and every word serves a purpose. No redundancy or wasted space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 optional parameters, output schema present), the description sufficiently covers its purpose and usage context. It could mention output format, but output schema fills that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 describes both parameters (agentPda and reviewer). The description does not add any extra meaning or constraints beyond what the schema provides, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fetches a feedback PDA by agent PDA and optional reviewer wallet. The verb 'Fetch' and resource 'feedback PDA' are specific. It distinguishes from sibling mutation tools (e.g., sap_give_feedback) by indicating it's a read-only operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use the tool: 'inspect current chain state before mutating... accounts.' This provides clear context for its use case, though it does not explicitly list alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate mutability (readOnlyHint=false) and non-destructiveness. Description adds that vault PDAs are visible on-chain, which is useful. However, it does not disclose idempotency or side effects beyond creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two succinct sentences: first states purpose, second provides security context. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 the simple input (1 param), the description adequately covers initialization context. Could mention creation outcome, but output schema handles return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%; the parameter 'vaultNonce' is described in the schema as a byte/hex/base64 array. Description adds no further semantics beyond the schema, so score is baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Initialize a memory vault for the connected agent.' The verb 'initialize' and resource 'memory vault' are specific. It differentiates from sibling vault tools (e.g., sap_fetch_vault, sap_open_vault_session) by being the init step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on appropriate usage: 'Store only intentionally encrypted payloads or public hashes' and notes that PDAs are visible on-chain. While it doesn't explicitly list alternatives, the context is clear for safe use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false (write operation), openWorldHint=true, etc. The description adds value by noting that session and vault PDAs are visible on-chain metadata and advising on what to store (intentionally encrypted payloads or public hashes). This goes beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no unnecessary words. The first sentence states the core purpose; the second adds essential context. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, input, and behavioral context. An output schema exists, so return values are handled. For a vault session opener, the description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description repeats the parameter format (32-byte session hash as byte array, hex, or base64). It adds no new meaning beyond the schema, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Open a vault session') and the input ('by 32-byte session hash'). It distinguishes from sibling tools like sap_fetch_session and sap_session_start by specifying 'vault session' and providing SAP MCP context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives context about the SAP MCP memory/session flow and what to store, but does not explicitly state when to use this tool versus alternatives, nor when not to use it. It lacks clear usage guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-destructive (destructiveHint=false) and not read-only (readOnlyHint=false). Description adds that it's a required preflight step, but doesn't detail what the preview entails (e.g., decoding, validation).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. First sentence states purpose, second gives usage guideline. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 is complete for a preview tool given the annotations and sibling context, though a bit more detail on what information is returned would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes the parameters (encoding and transaction). Description adds no additional parameter-specific meaning beyond what's in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool previews a Solana transaction before signing or submission. The specific verb 'preview' and resource 'Solana transaction' are provided, and it distinguishes from siblings by noting this is a required preflight step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (before signing/submission) and what not to do (avoid local signing scripts or reading keypair files). Context suggests it's a prerequisite for sap_sign_transaction, but no direct alternative mention.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover readOnly (false), destructiveHint (false), and idempotentHint (false). The description adds that the tool is a write operation requiring specific configuration, but does not disclose detailed side effects or potential errors 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and efficient, with two sentences: one for purpose and one for context. No redundant or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 present), the description adequately covers purpose, usage context, and parameter. It could be improved by noting what the output contains, but the schema fills that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter 'toolName' already described in the schema as 'Name of the tool descriptor to reactivate'. The description merely mentions 'by name', adding no extra semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Reactivate a SAP tool descriptor by name') with a specific verb and resource. It uniquely identifies the tool's purpose and distinguishes it from sibling tools like sap_deactivate_tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides important context about write tool prerequisites (signer policy, RPC, active SAP profile) and separates read vs write behavior. However, it does not explicitly state when to choose this tool over alternatives like sap_deactivate_tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and non-readonly behavior. The description adds context about audit stability but lacks details on side effects or reversibility. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two succinct sentences: one for purpose, one for usage context. No redundant words, front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with annotations and output schema, the description provides necessary context and prerequisites, though it could elaborate on the outcome or conditions for revocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear parameter description. The description mentions 'target agent PDA or wallet' which reinforces the schema, but does not add new information beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Revoke feedback') and the resource ('for an agent wallet'), making it distinct from siblings like sap_give_feedback and sap_update_feedback.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context ('SAP MCP context: Reputation and trust flow') and usage prerequisites ('verify the target agent PDA or wallet and keep hashes/attestation metadata stable and auditable'), offering clear guidance on when to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context like SDK method name and flow position beyond annotations. However, it is ambiguous whether the tool performs writes: it says 'fetching escrow data' (read) but annotations mark readOnlyHint=false, suggesting possible writes. The description does not clarify side effects or state modifications, leaving agents uncertain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no fluff, first sentence states purpose and method, second gives context, third provides guidance. Ideal conciseness for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 (not shown but present) and full schema coverage, the description covers high-level usage context and flow. It does not explain error conditions or prerequisites (e.g., existence of escrow data), but is adequate for a builder tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers all 3 parameters with 100% description coverage. The description adds no additional semantics about parameters (e.g., format, defaults, or constraints beyond schema). Baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it builds SAP x402 HTTP headers by fetching escrow data, using a specific SDK method. It distinguishes itself from sibling tools like sap_x402_fetch_escrow (which fetches but does not build headers) and sap_x402_settle_batch (which settles). The verb 'build' and resource 'HTTP headers' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises to use this tool before creating escrows or settling calls, placing it in the payment flow context. It warns that write operations require signer mode and policy approval. However, it does not explicitly say when not to use it or compare with alternative tools for pre-payment steps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive, so the description doesn't need to repeat. The additional SAP context is helpful but not about behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states the main purpose, second provides relevant ecosystem context. No wasted words, front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (1 param, read-only, output schema present). The description fully covers its purpose and context. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage with a clear description of the single 'wallet' parameter. The description adds no further meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get all Lulo lending positions for a wallet' with a specific verb and resource, distinguishing it from sibling Lulo tools like lulo_deposit or lulo_withdraw.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives; it only provides SAP MCP context about related tools, which is not directly about usage of this tool itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, establishing a safe read-only profile. The description adds context by listing returned fields (identity, FQDN, fee, block time, country), which goes beyond annotations. However, it does not disclose other behavioral traits such as pagination, rate limits, or authentication requirements, which are not needed given its simplicity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 14 words, with the core action 'List available Ephemeral Rollup nodes' front-loaded. The parenthetical enumeration of fields is efficient. There is zero wasted text, and the extra period at the end is negligible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a simple input schema (1 optional parameter with enum), an output schema (so return values are documented there), and annotations covering safety, the description provides sufficient context. It states what is listed and the fields included, making the tool fully understandable for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 the single 'endpoint' parameter with its enum values. The description mentions 'from the Magic Router' but adds no new meaning beyond the schema. Baseline of 3 is appropriate as the description does not significantly enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to list available Ephemeral Rollup nodes from the Magic Router, and enumerates specific fields (identity, FQDN, fee, block time, country). This is a specific verb+resource that distinguishes it from other magicblock_ tools like magicblock_balance or magicblock_deposit, which have different functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. While its function is straightforward and no direct sibling alternative exists for listing routes, the lack of explicit usage guidance lowers the score. Usage is implied from the description but not clarified with when-not or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior. The description adds that the price comes from an on-chain oracle and cautions against settlement use, which provides useful behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action. Every sentence serves a purpose: stating the operation and providing usage context. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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), annotations and schema cover the essential details. The description adds the source (on-chain oracle) and usage boundaries (not for settlement). With an output schema present, the description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already describes the parameter (priceId: hex or symbol). The description does not add new meaning about the parameter beyond what the schema provides, so it meets the baseline but adds no extra clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the current price from a Pyth oracle feed. It mentions 'feed discovery' which slightly broadens the purpose, but the primary action is well-defined and distinguishable from sibling tools like pyth_getPriceHistory and pyth_listPriceFeeds.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: use for oracle price reads and feed discovery, as context for pricing and risk checks, and explicitly warns against using for settlement. It doesn't directly compare with siblings but contextually implies alternative tools for history or listing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false. The description adds behavioral context (e.g., 'oracle reads as context for pricing, risk checks, and market-aware agent decisions') and a constraint (not settlement proof), adding 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise at two sentences plus a brief SAP MCP context line. Front-loaded with purpose and filters. Could be more structured but efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with optional filters and existing output schema, the description covers purpose, usage, and behavioral notes. It is complete enough given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 mentions filtering by query or asset type but does not add new meaning beyond what schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and resource 'available Pyth price feeds' with optional filters by query or asset type. It distinguishes from sibling tools like pyth_getPrice and pyth_getPriceHistory which focus on specific price data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit context: 'Use for Pyth oracle price reads and feed discovery' and advises 'do not treat them as settlement proof.' While it doesn't list alternative tools, it gives clear when-to-use guidance and a usage caveat.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true. The description adds behavioral context by mentioning prerequisites (signer policy, configured RPC, active SAP profile) and the effect of reclaiming rent. This is valuable beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences. The first sentence clearly states the core action, but the subsequent sentences about MCP context and read/write tools are somewhat generic and not essential for this tool. Still, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and the presence of an output schema (not shown but exists), the description covers the action, effect, and prerequisites. It could elaborate on what reclaiming rent means, but overall it is sufficient for an experienced agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so schema coverage is 100%. With zero params, baseline is 4. The description does not need to add parameter info, and it correctly avoids doing so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action clearly: 'Close the connected wallet SAP agent and reclaim rent.' It uses a specific verb and resource, and the mention of 'reclaim rent' distinguishes it from similar tools like deactivate agent. The title reinforces this.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when wanting to close the connected wallet's SAP agent, but does not explicitly state when to use it versus alternatives like sap_deactivate_agent. No exclusion criteria or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds valuable context: that it's a write tool requiring specific prerequisites (signer policy, configured RPC, active SAP profile). This goes beyond what annotations provide. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first clearly states the purpose, the second provides necessary context. No superfluous words, and it is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple deactivation tool with one parameter and an output schema, the description covers purpose, prerequisites, and context adequately. No gaps are apparent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'toolName' having a clear description. The tool description does not add any additional meaning or constraints beyond the schema, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Deactivate' and the resource 'SAP tool descriptor by name', making the tool's purpose immediately obvious. It distinguishes from sibling tools like 'sap_reactivate_tool'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides general context about write tools requiring signer policy, configured RPC, and active SAP profile, which implies when to use. However, it does not explicitly state when to use this tool versus alternatives (e.g., reactivate), or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds value beyond annotations by explaining that the tool is a 'hosted-safe unsigned builder' and the output is not submitted or signed. Annotations already indicate destructive hint, but the description clarifies that actual submission happens later. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at 5-6 sentences, covering purpose, usage, and a warning. It is front-loaded but slightly repetitive with 'Hosted-safe unsigned' appearing twice.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of output schema and complete parameter descriptions, the description covers the essential behavioral flow and safety warnings. It could mention error handling or edge cases but is sufficient for a builder tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add significant new meaning about parameters beyond what the schema already provides (e.g., units, derivation of PDA).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds an unsigned withdraw transaction for Escrow V2. It distinguishes from sibling build tools by specifying 'withdraw_escrow_v2' and explains the workflow (preview then finalize).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context that this is a builder and should be followed by finalization using sap_payments_finalize_transaction. Also warns about not creating signing scripts. However, it does not explicitly contrast with other escrow build tools like deposit or settle.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool uses a local signer, does not expose keypair bytes to OOBE, enforces a 0.1 SOL protocol fee, and defines success condition (agent account exists and fee invariant verified). Annotations are minimal (readOnlyHint=false), so description adds significant behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (5 sentences) and front-loads core purpose and usage. It is well-structured with minimal redundancy. Could be slightly more compact, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 covers key aspects: purpose, usage context, differentiation from siblings, fee enforcement, and success condition. It lacks explicit prerequisites (e.g., having a local SAP MCP profile wallet) and error scenarios, but is largely complete for a mutation tool with comprehensive schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, meaning all 11 parameters have descriptions. The description adds no additional parameter-level information beyond the schema; it only mentions the 'confirm' parameter requirement. Baseline is 3 due to high coverage, and description does not significantly enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool registers an on-chain SAP agent with the local signer, distinguishing it from raw sap_register_agent by explicitly mentioning when to use it (after hosted version returns hosted_local_signer_required). It uses specific verbs and resources ('local non-custodial SAP registry write').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance on when to use this tool: after hosted sap_register_agent returns hosted_local_signer_required, or directly instead of raw sap_register_agent. It also notes that no hosted x402 fee is paid. However, it does not provide explicit when-not-to-use scenarios or alternative tools beyond the raw version.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations do not provide read-only or destructive hints (readOnlyHint=false). The description adds that metadata is 'redacted', which is useful, but lacks details like whether it requires authentication or if it has side effects. Minimal behavioral context beyond the action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence with no unnecessary words. Front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters, and an output schema exists. The description is complete for an agent to understand what it does and what it returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist (0 parameters, 100% schema coverage). The description correctly omits parameter details. Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the currently loaded SAP MCP profile and redacted metadata, using a specific verb 'Return' and resource 'profile'. It distinguishes from siblings like sap_profile_list, sap_profile_public_key, and sap_profile_switch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. Usage is implied but no context for when to use or avoid is given. For a simple getter, this is acceptable but still a gap given sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, consistent with publishing. The description adds context about SDK method and registry writes, but doesn't disclose details like overwrite behavior or permission requirements. Still, it adds 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences front-load the purpose and context. The second sentence includes examples that are somewhat verbose but relevant. Overall, it is efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters, full schema coverage, output schema, and annotations, the description provides sufficient context about the tool's role and when to use it. It could mention authorization or side effects, but it is complete enough for a publish operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description does not add new parameter semantics beyond stating 'publish only schemas and descriptions that match actual tool surface,' which is general guidance. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Publish a tool descriptor using SDK ToolsModule.publishByName.' It specifies the resource (tool descriptor) and the action (publish), and provides context about advertising capabilities. Examples of tools (e.g., bridging_bridgeWormhole) help differentiate from siblings like sap_update_tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says to 'use tool registry writes to advertise concrete capabilities,' which guides when to use. It does not explicitly state when not to use or contrast with sap_update_tool, but the context is clear. A small gap in mentioning alternatives prevents a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, so the description adds value by stating that metadata should be kept stable and auditable, implying the revoke action does not destroy associated metadata. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences. The first directly states the purpose, and the second provides contextual guidance. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single input parameter, output schema exists), the description fully covers what the tool does, when to use it, and what to consider. No gaps remaining.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 only parameter 'agentWallet'. The tool description does not add any additional semantic meaning beyond the schema, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Revoke attestation for an agent wallet.' The verb 'revoke' and resource 'attestation' are specific. Among siblings like sap_create_attestation and sap_revoke_feedback, this tool's purpose is distinct and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a usage condition ('Use after verifying the target agent PDA or wallet') and a guideline ('keep hashes/attestation metadata stable and auditable'). However, it does not explicitly describe when to avoid this tool or mention alternatives, which would be helpful for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds 'Returns an unsigned transaction' beyond annotations. Annotations show readOnlyHint=false, not idempotent, openWorldHint=true. The description confirms it creates a new order (not read-only) and hints at non-idempotence. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states core purpose, second adds workflow context. No wasted words. Front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters, output schema present, and annotations, the description is fairly complete. It clearly states the tool's purpose and return type (unsigned transaction), and provides integration context. Somewhat lacking in details about permissions or side effects, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter having a description. The tool description does not add parameter-level detail beyond the schema, which is adequate. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Create a Dollar-Cost Averaging (DCA) recurring order' and notes it returns an unsigned transaction. The verb 'create' and resource 'DCA recurring order' are specific, distinguishing it from other Jupiter tools like swap or limit orders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit context: 'SAP MCP context: Jupiter protocol tools are served as AgentKit ecosystem tools. Use them for quote, route, and swap preparation, then use SAP transaction preview/sign/submit tools when an unsigned transaction must pass MCP signer policy.' This tells the agent when to use this tool and what follow-up steps are needed, though it does not explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=false), the description reveals that the tool returns an unsigned transaction and requires subsequent signing/submission via executeTrigger or SAP tools. This adds valuable behavioral context not present in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no redundancy: first sentence states purpose, second explains return type and next step, third provides broader ecosystem context. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (indicated by 'has output schema: true'), the description appropriately does not detail return values. It covers the unsigned transaction nature and the SAP signer policy context. It could mention prerequisites like order market, but overall sufficient for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description adds no additional parameter meaning beyond the purpose 'Create a limit order'. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and the resource 'limit order', distinguishing it from sibling tools like cancelLimitOrder or getLimitOrders. The name and description unambiguously identify the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use the tool: for preparation of unsigned transactions and then using SAP tools for signing. It mentions executeTrigger as a follow-up, guiding the agent on the next step. However, it lacks explicit 'when not to use' or alternative scenarios beyond the SAP ecosystem.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive. Description adds that it returns an unsigned transaction and is a single call, which is useful beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, no fluff, efficiently communicates the core function and context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema and annotations, the description covers the main purpose and usage context adequately. Could mention slippage handling briefly but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 7 parameters. Description does not add additional semantics beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it gets a quote + unsigned swap transaction in a single call, distinguishes from sibling tools like jupiter_getQuote (only quote) and jupiter_swap (executes swap).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes it as the 'recommended entry-point for swaps' and explains when to use SAP signing tools, providing context for when to use vs. alternatives, though not fully explicit about 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint: false, which contradicts the read-only nature of a 'get' tool. The description does not clarify this or add other behavioral details beyond what annotations already provide. The contradiction is noted but not severe as the tool is inherently safe.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first explains the tool's purpose, the second provides generic ecosystem context. The second sentence could be omitted or shortened, but the description is still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, output schema exists but not shown), the description fully explains what the tool returns. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and schema description coverage is 100%. The description adds no parameter meaning because none exist, which is appropriate. Baseline of 4 applies per guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get a mapping from program ID to human-readable label for all DEX programs', which is a specific verb and resource. It distinguishes itself from sibling Jupiter tools that handle quotes, swaps, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes SAP MCP context and workflow guidance about using Jupiter tools for quote/route/swap preparation before transaction tools, but does not explicitly state when to use this tool versus alternatives. The context is helpful but not tool-specific.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals that the tool only builds an unsigned transaction, not submitting it, and that a builder fee applies. This adds behavioral context beyond the annotations (readOnlyHint=false, destructiveHint=false), which only indicate it is a write operation. The description clarifies the tool's limited scope and dependencies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences, each providing essential information: purpose, workflow, and a warning with fee notice. No unnecessary words, and the most important information about what the tool does is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, 2 required) and the existence of an output schema, the description adequately covers the main use case and workflow. It does not need to explain return values as the output schema handles that. The only minor gap is no mention of default values for optional parameters, but the schema covers those.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% coverage of parameter descriptions, so the baseline is 3. The description does not add any additional meaning about parameters beyond what the schema provides, which is acceptable given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: building an unsigned transaction to deposit SPL tokens into an Ephemeral Rollup. It uses specific verbs and resources, and distinguishes itself from sibling tools like magicblock_withdraw or spl-token_transfer by specifying the target (Ephemeral Rollup).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear workflow: use this tool, then follow up with sap_preview_transaction, sap_sign_transaction, and sap_submit_signed_transaction. It also warns against creating local signing scripts. While it doesn't explicitly list when not to use this tool, the workflow instructions imply the intended usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations, the description adds that write operations require signer mode and policy approval, and it highlights the ordering relative to estimation. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core purpose, followed by essential context. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Provides enough context for usage in the payment and settlement flow, including prerequisites. Output schema exists, so no need to describe return values. Could mention error states but not necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for each parameter. The tool description does not add additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Create a recurring subscription for an agent wallet.' It distinguishes itself from siblings by placing it in the payment and settlement flow and specifying prerequisites like estimation and signer mode.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context on when to use: after estimating/fetching state, and prerequisites like enabled signer mode and MCP policy approval. However, it does not explicitly list alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true, and description confirms it is a write tool with prerequisites. No contradiction. However, it lacks details on what deactivation entails (e.g., state changes, reversibility).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states the action, second provides MCP context. Concise, front-loaded, no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and existence of an output schema, the description adequately covers prerequisites. Could benefit from a brief note on the output, but not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters are defined; schema coverage is 100%. Description has no param info to add, but baseline for 0 param tools is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Deactivate the connected wallet SAP agent' with a specific verb (deactivate) and resource (SAP agent). It distinguishes from sibling tools like sap_reactivate_agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context that deactivate is a write tool requiring signer policy, configured RPC, and active SAP profile. Does not explicitly state when to use versus alternatives like reactivate, but the purpose is straightforward.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate write behavior (readOnlyHint=false) and non-idempotence. The description adds a caution about confirming before writes, which is useful context for a deposit action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences, immediately stating purpose and then adding context. There is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a clear purpose, two well-defined parameters, and an output schema (present but not shown), the description adequately covers purpose, usage guidance, and behavioral notes. It is complete for a deposit tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters are documented clearly. The description does not add additional meaning beyond what the schema provides, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action 'Deposit additional stake for an agent wallet' with a specific verb and resource. It distinguishes from sibling tools by noting it is distinct from external AgentKit staking protocol tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance to confirm agent wallet, amount, and unstake timing before writes, and distinguishes from external tools. However, it does not explicitly exclude other scenarios like initial staking.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false and destructiveHint=true. The description adds valuable behavioral context: it is a builder (not executable), the agent wallet signs locally, DisputeWindow escrows create a pending PDA, CoSigned escrows may need coSigner. This goes beyond annotations, though some details (e.g., whether the tool itself affects state) could be clearer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loading the core purpose. Every sentence adds value: builder identity, local signing, escrow type differences, and finalization instructions. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 fully-described parameters, output schema present, and detailed workflow instructions (preview, finalize with flags), the description covers essential usage. It lacks details on error scenarios or expected output format, but given the output schema exists, completeness is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions, so baseline is 3. The description adds contextual meaning for coSigner ('when the escrow account requires it') but otherwise does not significantly enhance parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it builds an unsigned settlement transaction for escrow V2 ('Hosted-safe unsigned builder for settle_calls_v2'). It distinguishes between DisputeWindow and CoSigned escrows and provides context about the output not being submitted. Purpose 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit instructions: preview, then call local sap_payments_finalize_transaction with submit:true and confirm:true. It warns against creating signing scripts or reading keypair JSON. However, it lacks explicit comparisons to sibling escrow builders (e.g., build_deposit, build_withdraw) or mention of when to choose settlement over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds value by stating it is a 'Read-only SAP SDK wrapper against the configured Solana RPC and SAP program' and clarifying its use for inspecting state before mutations. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. The first sentence states the core action, and the second provides valuable context. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter and an output schema, the description is fairly complete. It explains the broader SAP MCP context and the use case. It could mention the expected output format, but the output schema likely covers that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema fully describes the single parameter. The description merely repeats 'by agent PDA' without adding extra semantic detail. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Fetch a memory vault by agent PDA.' It uses a specific verb-resource pair and distinguishes it from sibling fetch tools by naming the resource type 'memory vault'. The broader SAP MCP context further clarifies its role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: 'Use these reads to inspect current chain state before mutating...' This implies it's for pre-mutation inspection. However, it does not explicitly contrast with other sap_fetch_* tools among siblings, which would strengthen guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds valuable context about requiring signer mode and policy approval, and places the tool within the payment and settlement flow, going beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is three short sentences: first clearly states purpose, second adds context, third states prerequisites. No wasted words, front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 does not need to explain return values. It covers purpose, usage context, and prerequisites. Could be slightly more explicit about the effect (e.g., funds added to subscription) but is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. The tool description does not add new parameter-level insights beyond the schema, but it provides overall context. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Fund a recurring subscription' with specific verb and resource. It distinguishes from sibling tools like sap_create_subscription or sap_cancel_subscription by focusing on the funding action, and provides SAP MCP context to situate the tool in the payment and settlement flow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description advises to 'Estimate or fetch state before creating escrows or settling calls' and notes prerequisites (enabled signer mode, MCP policy approval). It gives clear context for when to use, though it does not explicitly mention alternative tools 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds context that it is a 'paid hosted global SAP agent directory read,' implying a cost and global scope, which goes beyond the annotations 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loaded with the tool's purpose, and avoids unnecessary details. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (15 parameters, pagination, filtering), the description covers the main functionality and its role in the SAP MCP context. It mentions all key features and aligns with the annotations and schema. Could be slightly more detailed about pagination, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 15 parameters have descriptions in the schema (100% coverage). The description summarizes the filtering capabilities but does not significantly add meaning beyond the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool enumerates current on-chain AgentAccount PDAs and supports various filtering, compact/full views, and cursor pagination. It specifies the action (list all) and the resource (SAP agents), distinguishing it from other tools by its global read-only nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context: 'Use these reads to inspect current chain state before mutating registry, payment, reputation, memory, or tool accounts.' This indicates when to use the tool (before mutations) but does not explicitly mention when not to use it or compare it to similar tools like sap_discover_agents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and destructiveHint=false. The description adds value by disclosing that signer metadata is redacted and no wallet paths are included, which are important behavioral details beyond what annotations capture.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no fluff. All information is front-loaded and relevant. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with no parameters and an output schema (not provided but assumed), the description is sufficient. It could mention that it returns a list of profiles, but 'List available' implies that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. The description does not need to explain parameters. Baseline score of 4 for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'available SAP MCP profiles', with additional specifics like 'redacted signer metadata and no wallet paths'. This distinguishes it from sibling tools like sap_profile_current or sap_profile_switch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (listing all profiles) but does not explicitly state when to use this tool vs alternatives (e.g., sap_profile_current). No when-not-to-use or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses deprecation, raw SDK nature, and that Hosted accountless SAP MCP rejects direct writes before x402 payment, adding context beyond annotations. Annotations provide readOnlyHint=false and openWorldHint=true, consistent with the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is repetitive, restating the deprecation and alternative multiple times. It could be trimmed to be more front-loaded; the first sentence is good but subsequent sentences add redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (deprecated, with alternative, 9 parameters), the description is fairly complete. It provides reasoning for deprecation and context about Hosted SAP MCP. Output schema exists, so return values are not needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description does not need to add parameter details. Baseline 3 is appropriate; the description does not significantly enhance parameter meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a deprecated raw SDK wrapper for SAP agent registration, and distinguishes it from the canonical sap_payments_register_agent. The verb 'register' and resource 'agent' are explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises against using this tool for production and directs to sap_payments_register_agent. It also mentions to use sap_agent_identity_plan first, providing clear when-not and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses beyond annotations: builds unsigned transaction, requires subsequent steps, null value special behavior, SOL record limitation. Annotations already indicate not read-only, not idempotent, not destructive, so description adds useful context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with the primary action. No redundant information, each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main operation, post-processing, null deletion, and unsupported SOL record. Could mention the output (unsigned transaction object) but output schema exists to handle that. Adequate for a 4-parameter tool with no required parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 4 parameters with descriptions (100% coverage). Description adds little beyond schema: the null value hint is already in schema. The note about SOL record gives domain-specific constraint but not deeply about parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it builds an unsigned SNS record create/update/delete transaction using Bonfida SDK. Differentiates from sibling tools like sap_sns_get_record or sap_sns_build_set_primary_domain_transaction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains two modes (hosted vs local) and how to chain with sap_payments_finalize_transaction or sap_sign_transaction. Also mentions using null to delete and that SOL record is not supported. Lacks explicit alternatives for unsupported operations but is clear in context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate the tool is not read-only (readOnlyHint=false) and not destructive (destructiveHint=false), which aligns with the 'Update' action. The description adds context about the reputation and trust flow and the need for stable metadata, providing useful behavioral insight 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences, each providing essential information: what the tool does, its context, and usage guidance. No filler or redundant information, front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the tool's role in the reputation system and references the SAP MCP context. With good schema and annotation coverage, plus an output schema, the description is mostly complete. A minor gap is the lack of detail on post-update effects or persistence, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with clear descriptions for both parameters (avgLatencyMs and uptimePercent). The tool description does not add any additional meaning beyond what the schema already provides, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and the specific resource 'self-reported latency and uptime metrics' for the connected wallet SAP agent. It distinguishes from sibling tools by focusing on reputation metrics, not other actions like fetching or creating attestations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises to use the tool after verifying the target agent PDA or wallet and emphasizes keeping hashes/attestation metadata stable and auditable. This provides practical guidance, though it does not explicitly list when not to use it or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false (write operation) and destructiveHint=false. The description adds 'operation class write' and warns about verifying terms, providing useful behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences plus a differentiation sentence, front-loaded with the main action, and every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, output schema present), the description covers the operation, warnings, and protocol context adequately. Missing details like error handling are not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The description does not add additional 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Unstake jupSOL back to SOL', providing a specific verb and resource. It distinguishes from siblings like staking_unstakeSOL and staking_unstakeSolayer by focusing on jupSOL.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool ('Use for SOL and liquid staking flows') and includes warnings about confirming details. It differentiates from SAP and AgentKit staking tools, but does not explicitly contrast with all sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnly, idempotent, and non-destructive behavior. The description adds that it reads an on-chain account and returns specific data (fulfilled status, random bytes, metadata). It does not mention error handling or behavior for missing requests, but the combination is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, succinct sentence that front-loads the core action. No unnecessary words; every part serves a purpose. Minor typo (double period) does not detract.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with an output schema and clear purpose, the description covers the necessary context. It mentions the return fields, and the schema details the parameters. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described. The description adds no additional meaning beyond what the schema provides, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Check whether a VRF request has been fulfilled by reading the RandomnessRequest account on-chain.' This is a specific verb-resource pair that distinguishes it from the sibling magicblock_requestRandomness tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context implies usage after a VRF request, and the sibling tools include magicblock_requestRandomness, making the intended workflow clear. However, it does not explicitly state when to use this tool versus alternatives or provide 'do not use' conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is not read-only (readOnlyHint=false), not destructive (destructiveHint=false), and may interact with external systems (openWorldHint=true). The description adds meaningful context: it returns a bearer token and is part of an authentication flow. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, no fluff. The first sentence front-loads the core action and flow step; the second adds token usage context. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 and complete parameter descriptions, the description adequately explains its role in the auth flow and token usage. It is complete 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all parameters have descriptions). The description does not add significant meaning beyond the schema, as it only mentions 'signed challenge' and 'bearer token' without detailing 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool exchanges a signed challenge for a bearer token, identifies it as step 2 of the PER auth flow, and notes its use for private-balance and private transfers. This distinguishes it from sibling tools like magicblock_challenge (step 1) and magicblock_privateBalance (which uses the token).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly positions this tool as step 2 of an auth flow, implying it should be used after obtaining a challenge via magicblock_challenge. It also states the token's purpose for private-balance and private transfers, giving context for when to use this tool. However, it does not explicitly mention when not to use it or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint), description adds that data is historical and a warning about not being settlement proof. Consistently reinforces read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: three sentences, no wasted words, front-loaded with main purpose and context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given presence of output schema and simple data retrieval, the description provides sufficient context: purpose, use cases, and a caveat. No gaps for a read-only historical query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so description doesn't need to add much. However, description does not elaborate on parameter usage or format beyond what schema provides, leaving baseline at 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets historical price data from Pyth oracle, using specific verb and resource. It distinguishes from siblings like pyth_getPrice (current price) and pyth_listPriceFeeds (feed listing) by specifying 'historical'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides usage context for pricing, risk checks, and market-aware decisions, plus a warning not to treat as settlement proof. However, lacks explicit comparison with alternative Pyth tools, though historical nature implies distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive behavior. Description adds context about purpose and usage triggers but does not contradict annotations. Behavioral traits are well disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences front-load the core purpose and usage conditions. Every sentence adds value with zero waste. Ideal conciseness for a startup action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple read-only nature, presence of output schema, and full schema coverage, the description is complete. It covers what the tool returns and when to call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'goal' is fully described in the input schema (100% coverage). The description adds minimal additional meaning beyond what 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns a startup playbook for agents. It lists specific trigger phrases, distinguishing it from sibling sap_* tools that perform other actions. The verb 'Return' and resource 'startup playbook' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly says 'Call this when the user says...' with enumerated phrases. While it doesn't mention when not to use or alternatives, the context is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (destructiveHint=true), the description adds that the builder refuses to close until balance and pendingAmount are zero, and that it is unsigned and not submitted. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences plus a warning. Every sentence is purposeful and front-loaded with the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present, the description explains key behaviors (refusal condition, unsigned nature) and next steps, making it complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with decent descriptions; the description only adds context that the depositor signs locally. This provides marginal additional meaning over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a 'Hosted-safe unsigned builder for close_escrow_v2' and explains the builder's refusal condition, distinguishing it from other escrow builders in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit next steps: 'Preview it, then call local sap_payments_finalize_transaction' and warnings about not creating signing scripts. Lacks explicit when-not-to-use compared to siblings, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. Description reinforces this by stating 'Read-only SAP SDK wrapper' but adds little extra beyond that. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: core purpose, context, usage guidance. No redundant information. Front-loaded with the most critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a complete output schema and clear annotations, the description sufficiently covers the tool's behavior and usage. It explains the fetch modes and the read-only nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers all 4 parameters with individual descriptions. The description adds value by explaining the two valid parameter combinations (escrowPda alone or agentPda+depositor+nonce), which is not apparent from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool fetches a V2 escrow, specifying two lookup modes (by escrow PDA or by agent/depositor/nonce). This distinguishes it from sibling tools like sap_fetch_escrow (V1) and other fetch tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides context: it is read-only and should be used to inspect chain state before mutations. However, it does not explicitly mention when not to use it or provide alternatives for different escrow types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds context about being a SDK wrapper against configured Solana RPC and SAP program, reinforcing the read-only nature and purpose. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and provides additional context efficiently. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and an output schema. The description, combined with annotations and schema, provides complete context for a read-only fetch operation. No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the parameter 'protocolId' is well-described with examples in the schema. The description does not add additional 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetch a SAP protocol index by protocol ID' using a specific verb and resource. It distinguishes itself from sibling tools by emphasizing its read-only nature and role in inspecting chain state before mutations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context on when to use this tool: 'Use these reads to inspect current chain state before mutating registry, payment, reputation, memory, or tool accounts.' It does not explicitly exclude usage or name alternatives, but the guidance is clear and helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds context about being a 'Read-only SAP SDK wrapper against the configured Solana RPC and SAP program' and the purpose of inspecting chain state. This adds value 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, with the first sentence stating the core purpose and the second providing usage context. Every word is earned; there is no redundancy or unnecessary detail. Front-loaded with the most critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema (indicated by context), so the description does not need to explain return values. The description covers purpose, usage guidelines, and parameter sufficiently for a simple read-only fetch tool. No gaps are apparent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the sessionPda parameter already fully described as 'Session PDA (base58) to fetch the ledger for'. The description does not add additional meaning or format details beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches a session ledger by session PDA (specific verb and resource). It adds context about being a read-only SDK wrapper, but does not explicitly differentiate from sibling tools like sap_fetch_escrow or sap_fetch_stake. The mention of 'session ledger' and 'session PDA' is specific enough to imply uniqueness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'Use these reads to inspect current chain state before mutating...' This provides clear guidance on the appropriate context (pre-mutation inspection) and implicitly tells the agent not to use it for mutation. No alternatives are listed, but the usage context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds context: 'Read-only SAP SDK wrapper against the configured Solana RPC and SAP program' and 'Use these reads to inspect current chain state before mutating...', which reinforces the read-only nature and provides background on how the tool fits into workflows.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded with the core functionality, and contains no wasted words. Every sentence adds value, making it easy for an AI agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 comprehensive annotations, the description is complete. It mentions the read-only nature, the workflow position (after other agent tools), and the broader context of inspecting chain state before mutations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (agentPda is described). The description does not add extra semantics beyond what the schema provides; it only restates 'by agent PDA'. Baseline is 3 as schema already covers the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Free exact SAP agent stats read by agent PDA', clearly indicating the verb (read) and resource (SAP agent stats). It also distinguishes from siblings by stating 'Use after sap_get_agent or sap_get_agent_profile when stats are needed', providing specific context for when to use this tool over others.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Use after sap_get_agent or sap_get_agent_profile when stats are needed'. It does not mention when not to use it, but the context is clear enough for an AI agent to select the tool correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description adds value by specifying it is a 'free local' check that 'verifies...without exposing keypair bytes' and lists what it checks, enhancing safety understanding. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences: first states purpose, second lists checks and usage guidance. No wasted words; front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple readiness check tool with output schema present, the description covers all needed context: what it checks, when to call, and safety guarantees. Complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters with descriptions (endpoint default, profile optional). The description does not add parameter-specific details beyond schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool as a 'free local readiness check for hosted SAP MCP paid/write workflows' and lists specific verifications (bridge, profile, key, balances, limits) without exposing keypair bytes. It distinguishes from siblings by stating it should be called before paid tools, swaps, SNS registration, Metaplex minting, or SAP registry writes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Agents should call this before paid tools, swaps, SNS registration, Metaplex minting, or SAP registry writes,' providing clear context for use. Missing explicit exclusions or alternatives, but the positive guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds that it's free and generated from a registry, but doesn't disclose additional traits like performance or error handling. With annotations covering safety, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with key purpose. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read tool with output schema, the description sufficiently explains what it returns and when to use it. No gaps given the low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in input schema, so baseline 4. Description does not need to add parameter info, and coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it returns a pricing catalog, specifying it's free, machine-readable, and from the SAP MCP pricing registry. Distinguishes itself by mentioning 'Use before paid calls' and listing tiers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use before paid calls to understand tiers, providing clear context. Does not specify when not to use, but the single-purpose read-only nature makes alternatives obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive. Description adds value by mentioning free helper, return of plan, and workflow linking to installation. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no waste, front-loaded purpose. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 optional params, output schema exists, annotations rich), the description covers core behavior, modes, and relationship to sibling tool. Output schema handles return details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters. The description does not add extra 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns exact latest-release commands and target directories for upgrading SAP MCP skills, distinguishing it from siblings like sap_skills_install. Verb 'returns' and specific resource are provided.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains two modes (hosted vs local) and relates to sap_skills_install for file writing, giving clear context. It could explicitly state when not to use, but still strong guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a write operation (readOnlyHint=false). Description adds that it creates a stake account and delegates, and warns about confirming terms. Provides behavioral context beyond 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
First sentence immediately states the core action. Paragraph is relatively concise, though some phrases like 'SAP MCP context' and 'operation class write' are slightly redundant given the later guidance. Could be tightened but still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main action, usage guidance, and important preconditions. Does not detail error handling or edge cases, but given the presence of an output schema and annotations, the description is fairly complete for a staking write tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all parameters documented). Description adds value by emphasizing confirmation of 'validator or provider, amount, lockup/unstake terms, and account ownership' before writes, giving real-world context to the amount and validator parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool stakes native SOL to a validator, creates a stake account, and delegates. Distinguishes from sibling staking tools (e.g., JupSOL, Solayer) by specifying 'SOL and liquid staking flows' and referencing SAP vs AgentKit staking tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use for SOL and liquid staking flows, and provides alternative tool groups: 'Use SAP staking tools for SAP protocol stake accounts; use AgentKit staking tools for external staking protocols.' Does not explicitly state when not to use, but guidance is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that it returns 'full route plan details' and uses the 'Metis engine', providing some behavioral context beyond schema. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences. The first delivers the core purpose immediately. The second adds essential workflow context (SAP MCP integration) without verbosity. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 parameters, output schema exists), the description is complete enough. It covers purpose, workflow, and hints at output details. The output schema handles return value documentation, so no further detail is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 fully describes all parameters. The description does not add additional semantics beyond the schema, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get an optimally-routed swap quote with full route plan details'. The verb 'Get' and resource 'swap quote' are specific. It distinguishes from sibling tools like jupiter_swap (execution) and jupiter_getPrice (simple price) by mentioning 'full route plan' and the Metis engine.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'Use them for quote, route, and swap preparation, then use SAP transaction preview/sign/submit tools when an unsigned transaction must pass MCP signer policy.' This tells when to use this tool (for quoting) and when to switch to SAP tools for execution, clarifying the workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not contradict annotations. It adds context about composing and SAP integration. While it doesn't elaborate on side effects, the destructiveHint is implied by 'swap instructions'. No annotation contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with purpose. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description mentions composition and SAP MCP workflow. While it doesn't explicitly state the dependency on jupiter_getQuote, the schema's parameter description for quoteResponse covers that. Given the output schema exists and parameters are well-documented, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameters are described in the schema. The tool description adds no additional parameter meaning beyond what's in the schema, meeting the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 'individual swap instructions', distinguishing it from a full transaction. It also implicitly separates from siblings like jupiter_swap by focusing on instruction composition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Useful for composing with other instructions' and provides SAP MCP context with guidance on when to use this tool versus SAP transaction tools for signing. This gives clear decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds that it's for empty escrows only and requires local signing. While it doesn't detail failure modes or side effects, the context about write operations requiring signer mode and policy approval adds transparency. Could be slightly improved but is good overall.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: three sentences that cover purpose, alternative for hosted users, and general context. It is front-loaded with the core function and wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema (present but not shown) and annotations covering destructive nature, the description provides sufficient context for using this tool among many escrow siblings. It mentions empty escrow requirement, local signing, and setup prerequisites. Could mention reversibility or error states, but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 does not add any additional meaning beyond what the schema provides. Given high coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('direct close'), the resource ('empty V2 escrow'), and the constraint ('local-signer-only'). It distinguishes from the sibling tool sap_escrow_build_close_transaction, which is for hosted users, 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.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (local signer, empty escrow) and when not to use (hosted users directed to another tool). Also provides prerequisites: estimate/fetch state, enabled signer mode, and MCP policy approval. This is comprehensive guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that it's a write operation (non-readOnly), requires local signing, and has preconditions. Annotations already show it's not destructive nor idempotent. Does not detail return value but output schema exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: function+constraint, alternative, and broader context. No unnecessary words, well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage distinction, preconditions, and context. Output schema exists. Could elaborate on nonce or escrow V2 concept, but adequate given sibling tools and annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are well-documented in the schema. Description adds no additional detail beyond what's already in the parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool's function: direct deposit into a V2 escrow for local-signers only. Distinguishes from the sibling sap_escrow_build_deposit_transaction for hosted users.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly specifies when to use this tool (local-signer) and when to use the alternative (hosted users). Also provides broader context: payment/settlement flow, prerequisites like estimating state and requiring signer mode and MCP policy approval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond annotations: it is a hosted-safe unsigned builder, output is not submitted or signed by hosted SAP MCP, keypair bytes never leave the user machine, and it defaults to DisputeWindow settlementSecurity=2 while rejecting SelfReport/0. This provides essential security and workflow transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat repetitive (e.g., the phrase 'Hosted-safe unsigned builder for create_escrow_v2' appears twice). While it is front-loaded with key info, it could be more concise by removing redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (13 parameters, 0 required) and presence of an output schema, the description covers the workflow, security model, and defaults. However, it does not summarize the output schema or return value, which would be helpful for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the baseline is 3. The description adds value by stating defaults (e.g., settlementSecurity defaults to 2) and emphasizing security aspects (depositorWallet signs locally). It provides context not captured in the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it's a 'Hosted-safe unsigned builder for create_escrow_v2', with the specific verb 'build' and resource 'create transaction'. It distinguishes from siblings like sap_create_escrow_v2 by emphasizing the preview-and-finalize workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to use this tool from hosted SAP MCP, preview the result, then call local sap_payments_finalize_transaction with submit:true. It also warns against creating temporary signing scripts or reading keypair JSON. However, it does not explicitly list 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=false, destructiveHint=false) are present. Description adds that it requires confirm: true and maxPriceUsd, returns a one-time header, and that the payment header is not surfaced when using the sibling. It does not elaborate on side effects beyond signing, but the annotations already cover the non-destructive nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with purpose, then usage guidance. No wasted words. Alternative tool named explicitly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-level helper with 6 parameters, annotations, and an output schema, the description covers purpose, usage constraints, and alternative. Could mention that it's local (already 'local helper') but otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter having a description. The description adds no further meaning beyond the schema; it only states the overall tool purpose and constraints. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('signs a parsed x402 PaymentRequired challenge') and the resource ('returns a one-time Payment-Signature header'). It also distinguishes from the sibling tool sap_payments_call_paid_tool by noting that normal agents should prefer it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use only when building a custom client; normal agents should prefer sap_payments_call_paid_tool' which provides clear when-to-use and when-not-to-use guidance. Also mentions requirements: 'Requires confirm: true and maxPriceUsd.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds context about the configured SAP MCP signer and the non-custodial security model beyond annotations. Does not mention output format or side effects, but annotations already cover readOnlyHint and destructiveHint accurately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, no filler. The first sentence states the core action and prerequisite, the second adds critical security guidance. Efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a signing tool with annotations and output schema present, the description covers the action, prerequisite, and security context. Could benefit from mentioning the output is a signed transaction ready for submission, but output schema likely provides that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds only that the transaction is 'serialized Solana transaction', which is implied by the schema. No additional detail on encoding differences or transaction format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Sign' and the resource 'serialized Solana transaction', and distinguishes it from related tools like sap_preview_transaction and unsafe signing methods. It specifies it's the supported non-custodial path.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'after sap_preview_transaction' (when to use) and warns not to read keypair JSON or sign raw bytes (when not to use), providing clear guidance and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a non-readonly, non-destructive mutation. The description adds behavioral context by specifying it updates 'on-chain feedback' for an agent wallet and advises on maintaining hash stability, which complements the annotations 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences precisely deliver purpose and usage guidance without extraneous details. Every sentence contributes meaning, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema and annotations, the description covers purpose, usage context, and parameter considerations sufficiently. It lacks explicit return value explanation but is complete enough for a mutation tool with good supporting metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds value by emphasizing the need to keep hashes/attestation metadata stable, which subtly relates to the commentHash parameter. This goes beyond basic schema descriptions, earning a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update existing on-chain feedback for an agent wallet' with a specific verb and resource. It distinguishes from sibling tools like sap_revoke_feedback and sap_give_feedback, making the tool's role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context ('SAP MCP context: Reputation and trust flow') and a precondition ('Use after verifying the target agent PDA or wallet and keep hashes/attestation metadata stable and auditable'). While not exhaustive, it gives clear guidance for when to use and what to ensure.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructive action; description adds specific behavioral constraints (local-signer-only, requires signer mode and policy approval) and context about write operations. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that are concise, front-loaded with the core action, and include necessary context without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage guidelines, prerequisites, and differentiates from sibling. Output schema exists so return values are covered elsewhere. Minor missing: no explanation of nonce default usage, but schema covers it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema already describes all parameters with 100% coverage. Description does not add additional information about parameters beyond what is in the schema, so baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it is a direct withdrawal from a V2 escrow for local-signer-only, distinguishing it from the hosted user alternative sap_escrow_build_withdraw_transaction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when not to use (hosted users) and names the alternative tool. Also provides prerequisites and requirements (enabled signer mode, MCP policy approval).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are minimal (readOnlyHint=false, etc.), and the description adds valuable behavioral details: it initializes session, signs payment, retries, settles, returns result+receipt. However, it does not fully disclose potential side effects (e.g., partial payment on failure, funds deducted only on success) or retry behavior in failure scenarios, which would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise—four sentences front-loading the core purpose, with no wasted words. Every sentence adds essential information about the tool's flow and usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters (some nested), an output schema, and is complex (payment bridge), the description covers the overall flow adequately. It explains the sequence (init, obtain challenge, sign, retry, settle, return) but could benefit from clarifying error handling and the guarantee of payment deduction only on success.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds limited new information beyond the schema. It reinforces defaults and constraints (e.g., 'Must be true' for confirm, 'Defaults to 3; max 5' for maxAttempts) but does not significantly enhance understanding beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool as a 'high-level local payment bridge' that handles x402 challenge signing, retries, and settlement for hosted SAP MCP calls. It explicitly distinguishes itself from alternatives by stating 'prefer this tool for hosted paid/write SAP MCP calls when the runtime cannot natively replay x402 challenges.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use the tool (for paid/write calls when runtime cannot natively replay) and specifies prerequisites ('Requires confirm: true and maxPriceUsd'). This helps the agent choose this tool over siblings like sap_payments_call_paid_tool or native approaches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is clear. The description adds that the result is an owner wallet address, which is useful behavioral context. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. The first sentence states the core purpose, and the second provides context and an alternative. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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, has output schema), the description is complete enough. It covers what the tool does, when to use it, and when not to. No missing critical details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the 'domain' parameter described as 'Full domain name (e.g. "myname.sol")'. The description does not add any additional 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Resolve a .sol domain to its owner wallet address' with a specific verb and resource. It distinguishes from sibling tools like sap_sns_resolve_domain and alldomains_resolveDomain by mentioning the SAP MCP context and suggesting an alternative for SAP-linked domains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use to resolve a .sol domain through AgentKit SNS helpers' and provides a when-not-to-use condition: 'For SAP-linked domains, prefer sap_sns_resolve_domain because it returns SAP MCP-shaped context.' This gives clear usage context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=false and destructiveHint=false. Description adds that it's a write operation (operation class write) and warns to confirm details before writes, which is useful behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the main action, and includes necessary context without redundancy. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 covers the tool's purpose, usage, and safety notes adequately. It could include more about return values, but output schema compensates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters (amount in lamports, wallet as base58 public key). Description does not add extra meaning beyond mentioning 'amount' and 'wallet' implicitly; baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Stake SOL for jupSOL' and explains the benefits (instant liquidity, auto-compounding). It distinguishes from sibling tools like staking stakeSOL by specifying liquid staking and contrasting with SAP vs AgentKit tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: 'Use for SOL and liquid staking flows' and advises to confirm terms before writes. It also differentiates SAP protocol tools from external AgentKit tools, aiding appropriate selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, and the description discloses that the tool returns an unsigned transaction (not submitting it), which matches the non-readOnly nature. It adds context about the signature workflow, though it could mention potential side effects like fee deduction or state changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences), front-loaded with the core action, and includes essential workflow context without redundancy. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (12 parameters, output schema) and the presence of sibling Jupiter tools, the description is complete: it defines the input (quote response), output (unsigned transaction), and downstream process (signing with SAP tools), enabling correct tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are described in the schema. However, some parameter descriptions are vague (e.g., 'Use Token Ledger mint...'), and the tool description does not add clarification or group parameters meaningfully beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's primary function: building an unsigned swap transaction from a quote response. It specifies the resource (swap transaction) and the action (build), and distinguishes itself from siblings by placing it in a workflow with quote, route, and SAP signing tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool: after obtaining a quote via jupiter_getQuote, and it directs the agent to use SAP preview/sign/submit tools for signing, thus providing clear usage context and excluding alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, idempotentHint=false, openWorldHint=true, and destructiveHint=false. The description adds that it builds an unsigned transaction (not executing it), references the VRF oracle address, and mentions builder fee. This provides useful context beyond the annotations, such as the transaction-building nature and oracle queue defaults.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused paragraph that front-loads the core purpose, then covers workflow, queue defaults, and fee. Every sentence adds value without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (so return values are not needed), the description covers all essential aspects: what the tool does, how to use it with SAP tools, key parameters, and the builder fee. It is sufficient for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 7 parameters are documented in the input schema (100% coverage). The description adds value by explaining that 'callerSeed' is committed before randomness production, and that 'ephemeral=true' switches to the ER queue. This context goes beyond the schema's descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool requests provably fair on-chain randomness from the MagicBlock VRF oracle, building an unsigned transaction. It uses a specific verb ('request') and resource ('randomness'), and distinguishes it from sibling tools like magicblock_getRandomnessResult by focusing on the request action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to use sap_preview_transaction, sap_sign_transaction, and sap_submit_signed_transaction, and warns against creating local signing scripts. It also mentions the oracle queue default and ephemeral option. However, it does not explicitly compare with alternatives or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (destructiveHint=true, etc.), the description adds crucial behavioral context: the transaction is unsigned, private mode has stuck-fund risk with wSOL, and the tool applies a value-action fee. It also warns against insecure practices, providing comprehensive transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose. It packs essential information in four sentences without fluff, though it could arguably be slightly more streamlined by separating workflow instructions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 parameters, nested objects, output schema), the description adequately covers modes, risks, and workflow. It does not detail the output schema, but that is provided separately, and the description fulfills its role of adding contextual completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so all parameters have descriptions. The tool description adds high-level context (e.g., mode explanation) but does not significantly enhance parameter semantics beyond what the schema already provides, meriting a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds an unsigned swap transaction from a quote, distinguishes between public and private modes, and explicitly instructs agents on the required follow-up steps, differentiating it from sibling tools like jupiter_swap and magicblock_swapQuote.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use (building from quote), mode selection (public vs private), and what not to do (never write temporary signing scripts or read keypair JSON). Also lists required continuation tools (sap_preview_transaction, etc.) and mentions the value-action fee.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and idempotentHint=true, so the description does not need to repeat these. The description adds that it is 'free' and 'machine-readable', which are useful behavioral traits 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that are front-loaded with the core purpose and then detailed use cases. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, presence of output schema, and robust annotations, the description covers all necessary context: readiness, routing, cost, and use cases. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the intent parameter with enum and description, so the description doesn't need to add much. The description mentions routing summary but does not explicitly tie it to the parameter. Baseline 3 applies due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it's a 'readyness and routing summary' and lists specific use cases like 'are you connected?' and paid/write readiness. It distinguishes from other tools by saying 'without dumping the whole tool catalog', which helps differentiate from sap_agent_next_action or similar tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: for checking connectivity, paid/write readiness, local profile visibility, and next actions. Implicitly tells when not to use (when you need full catalog), providing clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false. Description adds behavioral context: 'Defaults to DisputeWindow settlementSecurity=2', 'SelfReport/0 is rejected', 'local-signer-only', and rejection for hosted accountless before payment. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph but packs necessary information efficiently. It front-loads the core purpose and usage constraints. Could be better structured with line breaks, but every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 12 parameters, schema coverage, output schema existence, and annotations, the description provides sufficient context for correct tool invocation. It explains hosted vs local, prerequisites, and rejection conditions. Minor gap: does not explain output schema structure, but that's covered by output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds value by stating defaults (settlementSecurity=2, disputeWindowSlots defaults to 2160) and rejecting SelfReport/0, which is not in schema. This enriches parameter understanding beyond basic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Local-signer-only direct V2 escrow creation' using a specific SDK method. It distinguishes from sibling tools like sap_escrow_build_create_transaction by specifying when to use each (hosted accountless vs local). The verb-resource pair is explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance on when not to use (hosted accountless SAP MCP before x402 payment) and alternative tool (sap_escrow_build_create_transaction). Also mentions prerequisites: enabled signer mode and MCP policy approval. No ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description discloses that the output is unsigned and not submitted by the MCP, and that the transaction needs local signing. Annotations show readOnlyHint=false, idempotentHint=false, destructiveHint=false. The description adds context about the workflow and security precautions (no signing scripts, no keypair reading). However, it doesn't explicitly state the effect on state (the eventual finalization will modify on-chain state).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
4-5 sentences, each adds value: core purpose, usage condition, behavioral note, and security warning. No fluff, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no required ones, and existing output schema, the description covers purpose, usage conditions, behavioral transparency, and links to next step tool. It is self-contained and sufficient for an agent to understand when and how to use this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter having a description. The description does not add per-parameter detail beyond the schema, but provides overall context (e.g., purpose of each wallet). Baseline 3 is appropriate as schema already defines parameters clearly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'build' and resource 'finalize_settlement' for SAP Escrow V2. It distinguishes from sibling tools like sap_escrow_build_deposit_transaction, sap_escrow_build_settle_transaction, etc., by specifying it's for finalization after dispute window.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use: 'after the dispute window has elapsed and a pending settlement exists'. Provides clear next steps: 'Preview it, then call local sap_payments_finalize_transaction with submit:true and confirm:true'. Also warns against creating signing scripts or reading keypair JSON.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true; description adds that it's a read-only wrapper for Solana RPC and SAP program, reinforcing safety 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences covering purpose and usage context, with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 adequately covers purpose and usage context, including system dependencies and recommended use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters; description provides full schema coverage and no additional documentation needed. Baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it fetches an SDK discovery summary across SAP tool categories, distinguishing it from other sap_* tools that fetch specific entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use reads to inspect chain state before mutating accounts, providing clear context for its use within the SAP MCP workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details the entire flow: initialization, x402 challenge, signing with user wallet, retries, payment settlement, and result+receipt return. It also notes required fields (confirm, maxPriceUsd). Annotations provide readOnlyHint=false, etc., but the description adds significant behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that starts with the core purpose, then explains the process, and ends with usage guidance. No unnecessary words; every sentence adds value. It is appropriately front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, nested objects, and an output schema, the description covers the essential workflow and constraints (requires confirm and maxPriceUsd). The output schema exists, so return values need no description. The tool is complex but the description is complete for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions. The description highlights that 'confirm: true' and 'maxPriceUsd' are required, which adds value, but does not elaborate on other parameters. With full schema coverage, baseline is 3; the description provides marginal addition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a 'High-level local payment bridge' that initializes session, signs x402, retries tool call, settles payment, and returns result+receipt. The title 'Pay And Call Hosted SAP MCP Tool' aligns perfectly. It distinguishes itself from siblings (many sap_ tools are read-only or non-payment).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Prefer this tool for hosted paid/write SAP MCP calls when the runtime cannot natively replay x402 challenges.' This gives clear when-to-use guidance. It does not explicitly list exclusions or alternatives, but the context of siblings and the specific nature of the tool make this sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds key behavioral details: it is free, calls the target tool without payment, and returns a challenge without signing. It doesn't mention any side effects, but given readOnlyHint, the description is consistent and adds value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences, front-loads the key information, and avoids unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only helper tool with annotations and an output schema, the description sufficiently covers purpose, usage scenarios, and behavioral context, leaving no critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with individual parameter descriptions. The tool description provides context for the parameters as a whole (e.g., initializing hosted SAP MCP and calling a paid tool), but does not add meaning beyond what the schema already provides, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a low-level free helper that initializes hosted SAP MCP, calls a target paid tool without payment, and returns the parsed x402 challenge without signing. It distinguishes itself from sibling tools like sap_payments_call_paid_tool by specifying its limited use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool ('for inspection, policy review, or custom x402 clients') and advises that normal agents should prefer sap_payments_call_paid_tool, providing clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as read-only and idempotent; description adds that it is a local helper and does not determine finality, enhancing transparency beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-loaded with core purpose and a key caveat, no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present, description covers the decoding purpose, limitations, and parameter nuances adequately for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and description adds meaning by specifying that receiptHeader can be Base64 JSON or raw JSON, and that paymentResponse is an alias, clarifying format expectations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it decodes a specific receipt header (PAYMENT-RESPONSE or X-PAYMENT-RESPONSE) into JSON, distinguishing it from other payment tools like sap_x402_* that handle payment creation or settlement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly frames itself as a 'local inspection helper' and clarifies that on-chain finality comes from other sources, giving clear context for when to use it and what it does not replace.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, so the description isn't required to repeat that. It adds context about policy, retries, and audit staying inside SAP MCP, which informs the agent of additional behavioral guarantees. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the core purpose and usage guidance without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given high schema coverage, annotations, and presence of an output schema, the description is complete. It covers the tool's purpose, when to use it, and ties into the broader workflow (with sap_sign_transaction).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 9 parameters have descriptions in the schema (100% coverage), so the description does not need to add parameter details. It adds value by linking the signedTransaction parameter to the sign tool, but beyond that, the schema carries the burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool submits a signed Solana transaction, specifically one produced by sap_sign_transaction, via the configured RPC endpoint. It distinguishes itself from custom sendRawTransaction scripts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool: 'Use this instead of custom sendRawTransaction scripts' and provides the reasons (policy, retries, audit). This also implies alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a write operation (readOnlyHint=false) and not destructive (destructiveHint=false). The description adds critical behavioral context: 'OOBE never receives keypair bytes' and 'no hosted x402 fee is charged', indicating security and cost implications. It also states the update is local and non-custodial. However, it doesn't fully clarify whether update replaces or merges fields (schema suggests full replacement for arrays like pricing, but description says 'updates' which could be ambiguous). Still, it provides substantial 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph of concise, front-loaded sentences. The first two sentences state the purpose and usage condition. Subsequent sentences detail what is updated and key behavioral notes. Every sentence adds value without redundancy, making it efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 parameters, output schema exists), the description covers the trigger condition, update scope, security, and confirmation requirement. It does not describe the return value, but the output schema handles that. Missing: what happens if confirm is false or if the transaction fails? Nevertheless, the description provides sufficient context for an agent to decide when and how to invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The tool description adds meaning beyond the schema by explaining the context for certain parameters: 'metadataUri' is an alias for 'agentUri' and warns against using desktop file paths; 'confirm' must be true; 'pricing' and 'capabilities' are full replacement arrays. These additions help the agent understand parameter usage, justifying a score of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it updates a SAP agent with a local signer, specifically for hosted users when the hosted update returns 'hosted_local_signer_required'. It enumerates the updatable fields (name, description, capabilities, protocols, pricing, agentUri/metadataUri, x402Endpoint), distinguishing it from the hosted counterpart (sap_update_agent). The verb 'update' combined with 'local signer' and resource 'SAP agent' provides a specific purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool: 'Use this when hosted sap_update_agent returns hosted_local_signer_required.' This directly contrasts with the hosted sibling tool and provides a clear condition. It also implies not to use it otherwise, offering strong usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive. Description adds that execution status is returned, but does not detail side effects beyond execution.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded, no waste. First sentence defines tool, second provides context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists; description mentions execution status. Sufficient for a simple two-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
100% schema coverage, so baseline 3. Description adds context: signedTransaction is Base64-encoded and from getOrder, requestId from getOrder response.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Execute' and resource 'signed swap transaction from getOrder'. Distinguishes from siblings by mentioning Jupiter protocol and contrasting with SAP tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance: use for quote, route, and swap preparation; use SAP tools for unsigned transactions needing signer policy. Also ties to getOrder.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the builder is unsigned, does not submit, and is not signed by hosted SAP MCP. Advises to preview before finalizing. No contradiction with annotations (readOnlyHint=false is consistent). Adds context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, front-loaded with purpose, then usage, then warning. Every sentence is meaningful without redundancy. Well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 100% parameter schema coverage, the description covers all necessary aspects: what the tool does, how to use it, and the expected next step. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 additional meaning beyond the schema definitions for the four parameters. No extra semantic enrichment.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a 'hosted-safe unsigned builder for deposit_escrow_v2' and explains it adds funds to an existing V2 escrow. It distinguishes from sibling builders by specifying the use case: adding funds and then finalizing locally with sap_payments_finalize_transaction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance on when to use ('when a hosted workflow needs to add funds to an existing V2 escrow') and what to do after ('finalize locally with sap_payments_finalize_transaction'). Also includes a clear warning against creating temporary signing scripts or reading keypair JSON.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds further behavioral context: it is a 'direct finalization,' requires a local signer, and notes that write operations need enabled signer mode and MCP policy approval. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus a contextual note. It front-loads the core purpose and immediately provides usage guidance. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, destructive nature, and an existing output schema, the description is complete. It covers who should use it, prerequisites, and its role in the broader payment flow. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all 4 parameters, so the schema already provides meaning. The description does not add further parameter-level semantics beyond the schema, placing it at the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Local-signer-only direct finalization of a V2 pending settlement.' It distinguishes from the sibling tool sap_escrow_build_finalize_transaction by specifying that hosted users should use that alternative, clarifying exactly when this tool is applicable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool (local-signer-only) and when not (hosted users should use sap_escrow_build_finalize_transaction). It also provides context on the payment and settlement flow and prerequisites like estimating state and having enabled signer mode and MCP policy approval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: it explains the two-step x402 protocol (send once, sign, retry), signing with local wallet, and return of response plus receipt. No contradictions with annotations (readOnlyHint: false, destructiveHint: false).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences plus usage note. No unnecessary words. Front-loaded with purpose and process. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, output schema), the description covers the core protocol, distinguishes from alternatives, and notes requirements. The output schema exists and doesn't need explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 explains the overall workflow but does not add new semantics for individual parameters beyond what the schema already provides. It mentions required parameters but no additional detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'High-level local payment bridge for generic HTTP x402 endpoints outside hosted SAP MCP'. It uses specific verbs ('call', 'sign', 'retry') and identifies the resource (external x402 endpoints). It distinguishes from the sibling tool 'sap_payments_call_paid_tool' by specifying external vs. hosted use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'Use sap_payments_call_paid_tool for hosted SAP MCP tools; use this only for external HTTP x402 providers.' Additionally, it notes required parameters ('confirm: true and maxPriceUsd'), giving clear when-to-use and prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description does not need to restate safety. However, it adds context about the tool's role in the sap_payments bridge for x402 paid/write calls and clarifies that keypair bytes are never returned, which is useful beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the core purpose and key guidance. Every sentence adds unique value: purpose, usage guidance, and a warning. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and the presence of an output schema (not shown but noted), the description sufficiently explains the tool's context (sap_payments bridge, x402 calls), what it returns (specific fields), and how to choose it over a sibling. For a simple read tool, this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so schema coverage is 100% by default. The description adds no parameter info, but it does list what the profile contains (caller wallet, signer, etc.), aiding understanding of what the tool provides without parameters. Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'Return' and resource 'local SAP MCP profile', and explicitly distinguishes from the sibling tool sap_profile_current by noting it is the local version. The description also lists specific use cases (caller wallet, signer, active profile, local payment readiness), making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Directly advises when to use this tool: 'Use this instead of the remote sap_profile_current when checking...' This provides explicit usage guidance and names the alternative. Additionally, it warns about what not to expect ('Never returns keypair bytes').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds that it is 'local-signer-only' and requires signer mode and policy approval, providing context 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no wasted words. Core purpose is first, then alternative usage, then context. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema presence, annotations, and sibling tools, the description covers purpose, usage boundaries, prerequisites, and authorization. It is complete for an agent to correctly select and invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add parameter-specific details beyond the schema, but the high coverage ensures adequate documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Local-signer-only direct settlement against a V2 escrow.' It differentiates from the sibling tool 'sap_escrow_build_settle_transaction' for hosted users, ensuring the agent understands the specific use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs hosted users to use an alternative tool ('sap_escrow_build_settle_transaction') and provides prerequisites ('Estimate or fetch state before...', 'write operations require an enabled signer mode and MCP policy approval').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnly=false, destructive=false. Description adds valuable context: it builds/signs/submits transactions, pays fees in USDC+SOL, does NOT set SOL record, and requires separate signature. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with key information, and every sentence adds value. No filler or redundancies.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 params, nested objects, output schema present), the description covers registration process, signer requirements, fee details, and limitations. It is complete and well-paired with the existing annotations and output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 detailed parameter semantics beyond the schema, though it provides context about the SOL record being skipped. Overall, adequate but not exceptional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool registers a .sol domain for the SAP agent wallet using SAP SDK SnsModule, with specific verb 'register' and resource 'domain'. It distinguishes from sibling tools like sap_sns_build_manage_record_transaction by noting that SOL record is not set here.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states it's a local-signer-only tool and that hosted accountless SAP MCP rejects it before x402 payment. Provides clear when-not-to-use guidance and directs to use sap_sns_build_manage_record_transaction for setting the SOL record afterwards.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses local-signer requirement and SDK method. Annotations already indicate readOnlyHint=false and destructiveHint=false, but description adds context about rejection for hosted users. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Five sentences, front-loaded with critical context (local-signer-only, alternative), no redundancy, every sentence provides essential guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 optional parameters and output schema, description covers main use cases, prerequisites, alternatives, and parameter tips. Output schema reduces need to explain return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds value by listing updatable fields, providing usage tips (e.g., NFT identity workflow, warning about replacing entire lists).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'update the connected wallet SAP agent' with specific verb+resource. Distinguishes from sibling sap_payments_update_agent by specifying 'Local-signer-only' provides alternative for hosted users.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (after sap_register_agent), when not to use (hosted accountless MCP rejects direct write), and directs to alternative sap_payments_update_agent. Also provides prerequisite for NFT-backed identity changes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond annotations: it previews, signs with active local profile, optionally submits via relay, and clarifies relay security ('never receives keypair material'). No contradiction with annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single paragraph of 5 sentences, front-loaded with purpose, followed by usage and warnings. Every sentence contributes essential information with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite 12 parameters and complex workflow, the description covers input scenarios, signing process, submission options, security guarantees, and required confirm flag. Output schema exists (not shown) but is not needed for completeness here. Sufficient for correct agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and parameters are well-documented in the schema. The description adds value by highlighting key usage constraints (confirm: true, submit relay defaults) without repeating schema details. While not exhaustive, it integrates parameter context into the workflow.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as a local non-custodial transaction finalizer for hosted SAP MCP builders, specifying inputs (transactionBase64, transaction, unsigned Solana transaction) and actions (preview, sign, optionally submit). It distinguishes from siblings like sap_sign_transaction and sap_submit_signed_transaction by emphasizing local signing and relay submission.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: when a hosted tool returns transactionBase64, transaction, or unsigned Solana transaction. Provides clear when-not-to-use guidance: 'Never create temporary signing scripts, read keypair JSON, or call hosted sap_sign_transaction for user-owned signatures.' This offers effective alternative disambiguation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![sap-mcp MCP server](https://glama.ai/mcp/servers/OOBE-PROTOCOL/sap-mcp/badges/card.svg)](https://glama.ai/mcp/servers/OOBE-PROTOCOL/sap-mcp)

Score Badge

Copy to your README.md:

[![sap-mcp MCP server](https://glama.ai/mcp/servers/OOBE-PROTOCOL/sap-mcp/badges/score.svg)](https://glama.ai/mcp/servers/OOBE-PROTOCOL/sap-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/OOBE-PROTOCOL/sap-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server