AgentWallet MCP Server

Server Quality Checklist

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

Latest release: v1.7.3
Disambiguation4/5
Most tools have distinct purposes, but some overlap exists: 'transfer' and 'transfer_token' both handle token transfers but for different token types, and 'send_transaction' and 'sign_transaction' are closely related but differentiated by broadcasting. Descriptions clarify these boundaries, reducing confusion.
Naming Consistency5/5
Tool names follow a consistent snake_case pattern with clear verb_noun structures (e.g., 'create_wallet', 'get_balance', 'update_paywall'). There are no deviations in naming style, making the set predictable and easy to navigate.
Tool Count3/5
With 29 tools, the count is borderline high for a wallet and payment server, potentially overwhelming. While many tools are justified for covering EVM, Solana, and x402 paywall functionalities, it feels heavy and could benefit from consolidation or better scoping.
Completeness5/5
The tool set provides comprehensive coverage for wallet management (CRUD, pause/unpause), token operations (approvals, transfers, wrapping), contract interactions, and x402 paywall lifecycle (create, update, delete, payments). No obvious gaps exist for the stated domain, supporting full agent workflows.
Average 3.8/5 across 29 of 29 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 3 community issues answered or closed in the last 6 months
- 6 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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.
This repository includes a glama.json configuration file.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is an update operation but doesn't mention required permissions, whether changes are reversible, potential side effects, or error conditions. The phrase 'any other field' is vague about scope. For a mutation tool with zero annotation coverage, this leaves significant behavioral 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 a single, efficient sentence that gets straight to the point. It's appropriately sized for the tool's complexity, though it could be slightly more structured by separating core functionality from examples. No wasted words or redundancy.
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 mutation tool with 8 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what happens on success/failure, return values, or important behavioral aspects like validation rules or idempotency. The description alone doesn't provide enough context for safe and effective 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 description coverage is 100%, so all parameters are documented in the schema. The description adds minimal value beyond the schema by mentioning price, resource URL, and active status as examples of updatable fields, but doesn't provide additional semantic context like dependencies (e.g., token_decimals needed when changing amount) or constraints. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 as updating a paywall configuration with specific fields mentioned (price, resource URL, active status). It distinguishes from siblings like create_paywall and delete_paywall by focusing on modification rather than creation or deletion. However, it doesn't explicitly differentiate from other update-like operations 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 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 doesn't mention prerequisites like needing a paywall_id, nor does it compare with sibling tools like get_paywall for checking current configuration or create_paywall for initial setup. 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns 'pricing, access URL, payment stats, and configuration,' which adds some context about output content. However, it doesn't cover critical aspects like error handling (e.g., what happens with an invalid ID), authentication requirements, rate limits, or whether it's a read-only operation. For a tool with zero annotation coverage, this is insufficient.
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 highly concise and well-structured, consisting of two sentences that efficiently convey the tool's purpose and return values. Every sentence earns its place: the first defines the action and input, and the second lists the output details. There is no wasted verbiage, making it easy to parse and understand.
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 low complexity (single parameter, no nested objects) and high schema coverage, the description is adequate but has clear gaps. It lacks an output schema, so the description's mention of return values ('pricing, access URL, payment stats, and configuration') is helpful. However, without annotations, it misses behavioral details like error handling or auth needs, making it incomplete for optimal agent 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?
The input schema has 100% description coverage, with the single parameter 'paywall_id' documented as 'Paywall ID' of type integer. The description adds value by specifying that this ID is used to get details for a 'specific' paywall, reinforcing its purpose. However, it doesn't provide additional semantics beyond what the schema already covers, such as format examples or constraints, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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: 'Get details for a specific x402 paywall by ID.' It specifies the verb ('Get details'), resource ('x402 paywall'), and scope ('by ID'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'list_paywalls' or 'get_paywall_payments', which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 retrieving details for a 'specific' paywall by ID, but doesn't clarify prerequisites (e.g., needing a valid paywall ID) or contrast it with similar tools like 'list_paywalls' (for multiple paywalls) or 'get_paywall_payments' (for payment data). This lack of explicit usage context leaves gaps 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?
No annotations are provided, so the description carries the full burden. It discloses the return format (verified payments with TX hashes, payer addresses, amounts, timestamps) and implies read-only behavior, but lacks critical details: it doesn't mention pagination behavior (implied by page/per_page parameters but not explained), rate limits, authentication requirements, or error conditions. For a tool with no annotation coverage, this is a significant gap.
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, efficient sentence that front-loads the core purpose ('Get payment history for a specific x402 paywall') and adds value with return details. Every word earns its place, with no redundancy or fluff.
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 annotations and no output schema, the description is moderately complete: it covers the purpose and return format, but lacks behavioral context (e.g., pagination, auth, errors). For a read-only tool with 3 parameters and 100% schema coverage, it's adequate but has clear gaps in usage guidelines and transparency.
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 all three parameters (paywall_id, page, per_page). The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't explain paywall_id format or pagination context). Baseline 3 is appropriate when the schema does the heavy lifting.
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 'Get' and resource 'payment history for a specific x402 paywall', making the purpose unambiguous. It distinguishes from siblings like 'get_paywall' (which likely returns paywall metadata) and 'list_paywalls' (which lists multiple paywalls). However, it doesn't explicitly contrast with 'get_x402_revenue' (which might return aggregated revenue data), leaving slight room for improvement.
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 doesn't mention prerequisites (e.g., needing a valid paywall_id), nor does it compare with siblings like 'get_x402_revenue' for revenue data or 'list_paywalls' for paywall listings. Usage is implied only by the description's focus on payment history.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the return fields (address, label, etc.) but lacks critical details like whether this is a read-only operation, authentication requirements, error handling, or rate limits. For a tool with zero annotation coverage, this is insufficient.
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, efficient sentence that front-loads the core action ('Get details for a specific wallet by ID') and adds useful return field information. Every word serves a purpose with no wasted text.
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 input schema (1 parameter, 100% coverage) and no output schema, the description adequately covers the basic purpose and return fields. However, as a read operation with no annotations, it should ideally mention safety (e.g., read-only) or authentication context to 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?
The schema description coverage is 100%, with the single parameter 'wallet_id' documented as 'Wallet ID'. The description adds no additional meaning beyond this, such as format examples or constraints, so it meets the baseline score when schema coverage is high.
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 'Get details' and resource 'specific wallet by ID', making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_wallets' or 'get_balance', which would require more specific language about scope or data returned.
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 'list_wallets' (for multiple wallets) or 'get_balance' (for balance-specific info). It states what it does but offers no context about appropriate use cases or 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the outcome ('access URL will return 404 after deletion'), which is useful, but fails to mention critical aspects like whether deletion is permanent, requires specific permissions, has rate limits, or what happens to associated data (e.g., payments). This leaves significant gaps 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences with zero wasted words. It front-loads the core action and immediately follows with a key behavioral consequence, making it easy to parse and 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?
For a destructive tool with no annotations and no output schema, the description is incomplete. It omits details on permissions, irreversibility, error handling, and response format, which are critical for safe and effective use. The provided context is insufficient given the tool's complexity and lack of structured data.
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 'paywall_id' fully documented in the schema. The description does not add any meaning beyond the schema (e.g., format examples or constraints), so it meets the baseline of 3 where the schema does the heavy lifting.
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 ('Delete') and target resource ('an x402 paywall'), distinguishing it from sibling tools like 'create_paywall', 'update_paywall', 'get_paywall', and 'list_paywalls'. It precisely communicates the tool's function without 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 like 'update_paywall' or 'pause_wallet', nor does it mention prerequisites (e.g., needing the paywall ID) or warn about irreversible deletion. It lacks explicit 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions what data is returned (operations count, tier info, remaining quota, fees) but doesn't cover important aspects like whether this is a read-only operation (implied but not stated), authentication requirements, rate limits, error conditions, or data freshness. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
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 perfectly concise: two sentences that efficiently communicate the tool's purpose and return values. Every word earns its place - the first sentence states what it does, the second specifies the returned data. No wasted verbiage or redundancy.
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 0 parameters, no output schema, and no annotations, the description provides adequate basic information about what the tool returns. However, for a usage statistics tool, additional context about data scope (current month only), update frequency, or relationship to billing cycles would be helpful. The description meets minimum requirements but 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 tool has 0 parameters with 100% schema description coverage. The description appropriately doesn't waste space discussing non-existent parameters. Baseline for 0 parameters is 4, as there's nothing to document and the description correctly focuses on what the tool does rather than inputs.
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: 'Get the current month's usage statistics' specifies the verb (get) and resource (usage statistics). It distinguishes from siblings like 'get_balance' or 'get_x402_revenue' by focusing on usage metrics rather than financial balances or revenue data. However, it doesn't explicitly contrast with all siblings, keeping it at 4 rather than 5.
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 doesn't mention prerequisites, frequency recommendations, or contrast with similar tools like 'get_allowance' or 'get_token_info'. The agent must infer usage context from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool resumes a paused wallet, implying a state change, but doesn't cover permissions required, whether the operation is reversible, error conditions, or rate limits. This leaves significant gaps for a mutation tool.
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, efficient sentence that front-loads the core action and purpose without unnecessary words. Every part of the sentence contributes directly to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a mutation (resuming a wallet) with no annotations and no output schema, the description is incomplete. It lacks details on behavioral aspects like side effects, response format, or error handling, which are critical for safe and effective 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?
The input schema has 100% description coverage, with 'wallet_id' clearly documented. The description doesn't add any parameter-specific details beyond what the schema provides, such as format constraints or examples, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Resume') and resource ('a paused wallet'), with the specific outcome ('so transactions can be signed again'). It distinguishes from siblings like 'pause_wallet' by indicating the opposite operation, though it doesn't explicitly name 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 implies usage when a wallet is paused and needs to resume signing transactions, but it doesn't provide explicit guidance on when to use this tool versus alternatives like 'create_wallet' or 'get_wallet', 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool lists paywalls and describes return fields (IDs, names, pricing, etc.), which adds context beyond basic functionality. However, it lacks details on permissions, rate limits, or error handling, leaving gaps in behavioral understanding for a tool with no annotation support.
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, efficient sentence that front-loads the core action ('List all your x402 paywalls') and immediately specifies return details. There is no wasted text, and every part of the sentence contributes directly to understanding the tool's function and output.
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 moderate complexity (listing with pagination), no annotations, and no output schema, the description is partially complete. It covers the purpose and return fields but lacks details on pagination behavior, error cases, or authentication needs, which are important for a tool with no structured support in annotations or 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 description coverage is 100%, with both parameters ('page' and 'per_page') fully documented in the schema. The description does not add any parameter-specific information beyond what the schema provides, such as default behaviors or constraints, so it meets the baseline for high schema coverage without compensating with extra details.
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 ('your x402 paywalls'), specifying what the tool does. It distinguishes from siblings like 'get_paywall' (singular retrieval) and 'create_paywall' (creation) by indicating it returns multiple paywalls with comprehensive details, making the purpose specific and well-differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, compare with similar tools like 'get_paywall' for single paywall retrieval, or specify contexts where listing is preferred over other operations, leaving the agent without usage direction.
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?
With no annotations provided, the description carries full burden and adds valuable behavioral context: it specifies that private keys are encrypted server-side and never exposed, which is critical security information. However, it lacks details on error conditions, rate limits, or authentication requirements, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/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, followed by a concise security detail. Both sentences earn their place by providing essential information without redundancy, making it efficiently structured and appropriately sized.
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 annotations and no output schema, the description is moderately complete: it covers the creation action and security aspect but misses details like return format (beyond mentioning ID and address), error handling, or dependencies. For a tool with 2 parameters and no structured safety hints, it should do more to 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 fully documents the two parameters (label and chain_id). The description adds no additional parameter semantics beyond what's in the schema, meeting the baseline of 3 for high coverage without 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 action ('Create') and resource ('new EVM or Solana wallet'), specifying it generates wallet ID and address. It distinguishes from siblings like 'get_wallet' or 'list_wallets' by being a creation tool, though it doesn't explicitly contrast with other creation tools (e.g., 'create_paywall').
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?
Usage is implied through context: it's for creating wallets when needed, with no explicit guidance on when to use it versus alternatives like importing or retrieving existing wallets. It doesn't mention prerequisites (e.g., authentication) or exclusions, leaving usage decisions to inference.
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?
With no annotations provided, the description carries the full burden. It discloses the return format (balance in wei/lamports and human-readable), which is valuable behavioral context. However, it doesn't mention potential errors, rate limits, or authentication requirements, leaving gaps for a tool that queries financial data.
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, efficient sentence that front-loads the core purpose and includes essential behavioral details about return formats. Every word earns its place with zero waste or redundancy.
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 no annotations and no output schema, the description provides good purpose and return format clarity but lacks details on error handling, chain compatibility, or authentication. Given the complexity of blockchain operations, it's adequate but has clear gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 fully. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't explain wallet_id or chain_id formats or defaults in more detail). Baseline 3 is appropriate when the schema does the heavy lifting.
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 with a specific verb ('Get') and resource ('native token balance for a wallet on a specific chain'), and distinguishes it from sibling tools like 'get_token_balance' by specifying it's for native tokens only. This provides precise 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 implies usage by specifying the resource (wallet balance on a chain), but doesn't explicitly state when to use this tool versus alternatives like 'get_token_balance' or 'get_wallet'. It provides some context but lacks explicit guidance on exclusions or prerequisites.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it mentions the conversion action and amount format, it lacks critical information such as whether this requires gas fees, what permissions are needed, whether it's reversible, potential rate limits, or what the expected output looks like. For a financial transaction tool with zero annotation coverage, this is a significant gap.
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 efficiently structured in two sentences: the first states the purpose and scope, the second provides specific parameter guidance. Every sentence adds clear value with no wasted words, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a financial conversion tool with no annotations and no output schema, the description is incomplete. It covers the basic purpose and parameter format but misses critical behavioral details (e.g., transaction costs, success/failure responses, error conditions). However, it does adequately explain the core functionality for a user familiar with blockchain concepts.
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 three parameters (wallet_id, amount, chain_id) with descriptions. The description adds value by clarifying the amount format with an example ('0.5' for 0.5 WETH), but doesn't provide additional context for wallet_id or chain_id beyond what the schema states. Baseline 3 is appropriate when schema does most of 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 specific action ('Unwrap wrapped tokens') and resources involved (WETH, WAVAX, WBNB, etc. back to native tokens). It distinguishes from sibling tools like 'wrap_eth' by specifying the opposite operation, and from other tools like 'transfer' or 'send_transaction' by focusing on token conversion rather than movement.
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 implicitly indicates when to use this tool (to convert wrapped tokens to native tokens) and provides an example format for the amount parameter. However, it doesn't explicitly state when NOT to use it or name specific alternatives (e.g., when to use 'transfer_token' instead for moving wrapped tokens without conversion).
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?
With no annotations provided, the description carries the full burden. It discloses the behavioral effect ('No transactions can be signed while paused'), which is useful. However, it lacks details on permissions required, reversibility, or rate limits, leaving gaps for a mutation tool.
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 zero waste, front-loading the key action and effect. Every word earns its place, making it highly efficient and easy to understand.
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 mutation tool with no annotations and no output schema, the description is adequate but incomplete. It covers the purpose and effect but lacks details on permissions, error cases, or return values, which are important for 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 description coverage is 100%, so the schema already documents the 'wallet_id' parameter fully. The description does not add any additional meaning or context about the parameter beyond what the schema provides, 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 specific action ('Emergency pause a wallet') and the resource ('wallet'), distinguishing it from sibling tools like 'unpause_wallet' and 'get_wallet'. It explicitly mentions the effect ('No transactions can be signed while paused'), which adds clarity beyond just the verb.
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 in emergency situations ('Emergency pause'), providing clear context for when to use it. However, it does not explicitly state when not to use it or name alternatives (e.g., 'unpause_wallet' for reversing the action), which prevents a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: server-side signing, RPC broadcasting, and different return values for EVM (transaction hash) versus Solana (signature). It doesn't mention error conditions, rate limits, or authentication requirements, keeping it from a perfect score.
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 efficiently structured in two sentences: the first states the core action and return values, the second adds crucial behavioral context about signing and broadcasting. Every word earns its place with zero redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex transaction tool with 10 parameters, no annotations, and no output schema, the description is adequate but incomplete. It covers the basic operation and return types but lacks information about error responses, side effects, or security considerations that would be important for such a sensitive 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 the baseline is 3. The description adds no additional parameter semantics beyond what's already documented in the schema (e.g., it doesn't clarify parameter interactions or provide examples). It mentions EVM/Solana contexts which relate to parameters but doesn't explicitly map them.
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 ('Sign and broadcast a transaction') and distinguishes it from sibling tools like 'sign_transaction' (which likely only signs) and 'transfer' (which might be simpler). It explicitly mentions both EVM and Solana contexts, providing clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for sending transactions but doesn't explicitly state when to use this tool versus alternatives like 'transfer', 'transfer_token', or 'call_contract'. It mentions server-side signing and RPC broadcasting, which provides some context but lacks explicit guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it 'Signs and broadcasts the transaction' (indicating a write operation with network interaction) and mentions the human-readable amount format. However, it lacks details on permissions needed, rate limits, error conditions, or 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by key usage details and a helper reference. Every sentence earns its place with no wasted words, making it efficient and easy 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?
For a complex write operation (token transfer) with no annotations and no output schema, the description is moderately complete. It covers the action, key behavioral aspects (signing/broadcasting), and parameter hints, but lacks details on return values, error handling, or security prerequisites, which are important for such a 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 thoroughly. The description adds minimal value by reiterating the human-readable amount format and hinting at token address formats, but does not provide additional semantic context 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 description clearly states the specific action ('Send ERC-20 tokens (EVM) or SPL tokens (Solana) to an address'), identifies the resource (tokens), and distinguishes from siblings like 'transfer' (which might be generic) or 'send_transaction' (which might be for native currency) by specifying token types and formats.
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 (sending tokens, not native currency) and references 'get_chains' as a helper for finding addresses, but does not explicitly state when not to use it or name specific alternatives like 'send_transaction' for ETH transfers.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the action (wrapping tokens) and mentions the requirement for DeFi protocols, but does not cover other behavioral traits such as transaction costs, confirmation times, error conditions, or what happens on failure. It adds some context but is incomplete for a mutation tool with zero 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?
The description is appropriately sized and front-loaded, with three sentences that each earn their place: the first states the purpose, the second provides usage context, and the third clarifies parameter formatting. There is zero waste, and the structure is 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?
Given the complexity (a mutation tool with no annotations and no output schema), the description is partially complete. It covers the purpose, usage context, and parameter formatting, but lacks details on behavioral aspects (e.g., transaction outcomes, errors) and does not explain return values. It is adequate but has clear gaps for a tool that modifies blockchain state.
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 (wallet_id, amount, chain_id). The description adds meaning for 'amount' by specifying the format ('human-readable format') and providing an example ('0.5' for 0.5 ETH), but does not add semantics beyond what the schema provides for 'wallet_id' or 'chain_id'. Baseline 3 is appropriate as the schema does the heavy lifting.
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 ('Wrap native tokens') and resources involved (ETH, AVAX, BNB, POL, PLS into WETH, WAVAX, etc.). It distinguishes from sibling tools like 'unwrap_eth' by specifying the conversion direction and mentions the purpose ('Required for most DeFi protocols that use ERC-20 tokens instead of raw native tokens'), making it highly specific and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool ('Required for most DeFi protocols that use ERC-20 tokens instead of raw native tokens'), but does not explicitly state when not to use it or name alternatives (e.g., 'unwrap_eth' for the reverse operation). It implies usage for DeFi compatibility but lacks explicit exclusions or comparisons to 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior: creating a paywall that returns a URL, which returns HTTP 402 until payment is made, and then serves the protected resource after verification. It covers the payment flow and outcome, though it could add more about error conditions 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in two sentences that directly explain the tool's purpose and workflow. Every word earns its place, with no redundant or vague language, making it easy to understand at a glance.
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 creation tool with 11 parameters and no annotations or output schema, the description provides a solid overview of what the tool does and its behavioral flow. It covers the core functionality and outcome, though it could be more complete by mentioning potential errors, the format of the returned URL, or how the proof mechanism works in 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 schema already documents all 11 parameters thoroughly. The description doesn't add any parameter-specific semantics beyond what the schema provides, such as explaining interactions between parameters like 'token_type' and 'token_address'. Baseline 3 is appropriate when the schema does the heavy lifting.
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 ('Create an x402 paywall'), the target resource ('that charges agents/clients for accessing a resource'), and the outcome ('Returns a public access URL that returns HTTP 402 until paid'). It distinguishes this tool from siblings like 'update_paywall' or 'delete_paywall' by focusing on creation rather than modification or removal.
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 context by mentioning that agents pay on-chain and retry with proof, but it doesn't explicitly state when to use this tool versus alternatives like 'update_paywall' or 'pay_x402'. It provides some operational guidance but lacks explicit comparisons or exclusions relative to 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?
With no annotations provided, the description carries full burden. It discloses the return format (raw and human-readable balance) which is valuable behavioral information. However, it doesn't mention error conditions, rate limits, authentication requirements, or whether this is a read-only operation (though 'Get' implies it).
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. The first sentence covers what the tool does and returns, the second provides practical guidance. Zero wasted words or 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?
For a read operation with no annotations and no output schema, the description provides adequate context about what it returns. However, it could benefit from mentioning that this is a read-only operation and clarifying error scenarios or limitations.
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 good parameter documentation. The description adds minimal value beyond the schema - it mentions ERC-20/SPL tokens and references get_chains for addresses, but doesn't explain parameter relationships or provide additional semantic context.
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 ('Get'), resource ('ERC-20 or SPL token balance'), and target ('for a wallet on a specific chain'). It distinguishes from siblings like get_balance (likely native token) and get_token_info (metadata rather than balance).
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 (to get token balances) and mentions get_chains as a related tool for finding token addresses. However, it doesn't explicitly state when NOT to use it or provide alternatives for similar operations.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively communicates that this is a read-only operation for token metadata discovery, but doesn't mention potential limitations like rate limits, error conditions, or whether it requires authentication. The description adds useful context about the tool's purpose but lacks operational 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?
The description is perfectly concise with two sentences that each earn their place: the first states exactly what the tool does, and the second provides valuable usage context. No wasted words, and the information is front-loaded with the core functionality.
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 read-only metadata tool with no annotations and no output schema, the description provides adequate context about what information is returned and when to use it. However, it doesn't describe the return format or structure, which would be helpful given the absence of an output schema. The description covers the essentials but leaves some implementation details unspecified.
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?
With 100% schema description coverage, the input schema already fully documents both parameters (token address and chain ID). The description doesn't add any additional parameter semantics beyond what's in the schema, such as explaining why chain_id matters or providing examples. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 ('Get'), resource ('ERC-20 token'), and exact data returned ('name, symbol, and decimals'), distinguishing it from sibling tools like get_balance or get_token_balance which focus on different token attributes. The verb+resource combination is precise 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 provides clear context about when to use this tool ('before transfers or approvals'), which helps differentiate it from other token-related tools. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools, though the context implies it's for metadata rather than balance or allowance checks.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively indicates this is a read-only operation ('Get') and describes the return format ('total payments and revenue broken down by chain and token'), which is helpful. However, it lacks details on potential rate limits, authentication requirements, or data freshness, which are important for a revenue reporting tool.
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 efficiently conveys the tool's purpose, scope, and output format without any redundant or unnecessary information. It is front-loaded with the core action and maintains clarity throughout, making it highly concise and effective.
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 (0 parameters, no output schema, no annotations), the description is reasonably complete. It covers the purpose, scope, and output structure, which are essential for understanding. However, without an output schema, it could benefit from more detail on the exact format of the returned data (e.g., JSON structure), slightly limiting completeness for integration purposes.
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 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description adds value by clarifying the scope ('across all your paywalls') and output breakdown ('by chain and token'), which provides semantic context beyond the empty schema. This compensates adequately, though it's not a complex parameter scenario.
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 ('Get aggregate x402 revenue statistics'), identifies the target resource ('across all your paywalls'), and distinguishes from siblings like 'get_paywall_payments' (individual payments) or 'get_usage' (general usage). It provides a precise verb+resource combination that leaves no ambiguity about 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying 'across all your paywalls,' suggesting this tool should be used for aggregate revenue analysis rather than per-paywall details. However, it does not explicitly state when to use this tool versus alternatives like 'get_paywall_payments' or 'get_usage,' nor does it mention any prerequisites or exclusions, leaving some guidance gaps.
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?
No annotations are provided, so the description carries the full burden. It discloses that it returns specific data fields (wallet IDs, addresses, labels, chain IDs, status), which adds useful context about output format. However, it does not mention behavioral traits like pagination, rate limits, error conditions, or whether it's read-only (implied by 'List' but not explicit).
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 purpose and followed by return details. Every sentence adds value: the first defines the action and scope, the second specifies the output fields. There is no wasted text or 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 (0 parameters, no output schema, no annotations), the description is complete enough for a list operation. It explains what it does and what it returns. However, without annotations, it could benefit from mentioning it's a read-only operation or any limitations, but the output details compensate partially.
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 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description does not add parameter semantics, but with no parameters, the baseline is 4 as it adequately addresses the lack of inputs.
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 all wallets') and the resource ('owned by the authenticated user'), specifying verb and resource. It distinguishes from siblings like 'get_wallet' (which retrieves a single wallet) by indicating it returns multiple wallets, and from 'create_wallet' or 'delete_wallet' by being a read 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 usage context by stating 'owned by the authenticated user', suggesting it should be used when the user wants to see all their wallets. However, it does not explicitly state when to use this tool versus alternatives like 'get_wallet' for a specific wallet, or provide exclusions or prerequisites beyond authentication.
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?
With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: it specifies the action signs and broadcasts transactions (indicating a write/mutation operation), mentions automatic conversion to wei/lamports, and lists supported tokens. However, it doesn't mention potential side effects like gas fees, confirmation times, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly front-loaded with the core purpose in the first clause, followed by essential usage details. Every sentence earns its place: the first states what it does, the second specifies format, and the third reveals key implementation behavior. Zero 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?
For a mutation tool with no annotations and no output schema, the description does reasonably well by explaining the core operation, supported tokens, and transaction behavior. However, it lacks information about return values (transaction hash? confirmation?), error cases, or prerequisites (wallet must be funded/unlocked). Given the complexity of blockchain transactions, some 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?
Schema description coverage is 100%, so the schema already documents all four parameters thoroughly. The description adds minimal value beyond the schema by reinforcing the 'amount' parameter format example, but doesn't provide additional semantic context about parameter interactions 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 the specific action ('Send native tokens') and resources (ETH, AVAX, BNB, POL, PLS, SOL), distinguishing it from sibling tools like 'transfer_token' (which presumably handles non-native tokens) and 'send_transaction' (which may be more generic). It provides a precise verb+resource combination with explicit token examples.
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 sending native tokens, but doesn't explicitly state when to use this versus alternatives like 'transfer_token' or 'send_transaction'. It provides some context about format conversion, but lacks explicit guidance on tool selection among siblings or 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the output content (chain attributes) but doesn't mention behavioral traits like whether this is a read-only operation (implied by 'List'), potential rate limits, authentication requirements, or response format. The description adds value by specifying what data is returned but lacks operational 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 a single, dense sentence that efficiently packs all necessary information: action, resource, scope, and specific output attributes. There's no wasted wording, and it's front-loaded with the core purpose, 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.
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 (0 parameters, no annotations, no output schema), the description is reasonably complete for a read-only listing operation. It specifies what data is returned, but lacks details on format (e.g., structured list vs. raw), pagination, or error handling. For a tool with no structured output schema, more detail on return values would be beneficial.
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 0 parameters, and schema description coverage is 100% (though empty). The description doesn't need to explain parameters, so it appropriately focuses on output semantics. It adds meaning by detailing what information is returned (chain IDs, native tokens, etc.), which is valuable since there's no output schema provided.
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 verb ('List') and resource ('all supported chains') with detailed scope ('EVM + Solana') and specific attributes ('chain IDs, native tokens, stablecoins, and RPC configuration status'). It effectively distinguishes itself from siblings like get_balance or get_token_info by focusing on chain metadata rather than wallet/token 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?
The description implies usage context through the listed attributes (e.g., chain IDs for network selection, RPC status for connectivity checks), suggesting it should be used when needing chain metadata for configuration or reference. However, it doesn't explicitly state when NOT to use it or name specific alternatives among siblings, though the distinction is clear from the resource focus.
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?
With no annotations provided, the description carries the full burden and does an excellent job disclosing key behavioral traits: it explicitly states the operation is read-only, doesn't cost gas, doesn't modify state, and returns raw hex results. This covers safety, cost, and output format effectively.
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 perfectly front-loaded with the core functionality in the first sentence, followed by important behavioral details, and ends with a practical use case. Every sentence adds value with zero 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?
For a read-only tool with no annotations and no output schema, the description provides excellent context about behavior, safety, and use cases. The only minor gap is not explicitly mentioning potential error cases or limitations, but it's otherwise quite 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 schema already documents all three parameters thoroughly. The description doesn't add any meaningful parameter semantics beyond what's in the schema descriptions, maintaining the 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 specific action ('execute a read-only call against a smart contract'), the resource ('smart contract'), and the method ('eth_call'). It distinguishes from sibling tools like 'send_transaction' or 'sign_transaction' by emphasizing read-only nature and no state modification.
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 ('useful for reading on-chain data like token balances, prices, positions') and implicitly distinguishes it from write operations. However, it doesn't explicitly name alternatives or specify when not to use it beyond the read-only emphasis.
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?
With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: it's a soft-delete (not permanent), specifies effects on listings and transactions, and implies it's a mutation operation. However, it doesn't mention permissions, reversibility, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that are front-loaded with the core action and immediately explain the consequences. Every word adds value with no redundancy or unnecessary elaboration.
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 mutation tool with no annotations and no output schema, the description provides good context about the soft-delete behavior and effects. However, it doesn't cover response format, error cases, or confirmation of deletion, leaving some gaps in completeness.
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% with one parameter clearly documented in the schema. The description doesn't add parameter-specific information beyond what the schema provides, but with high schema coverage and only one parameter, this is acceptable. Baseline would be 3, but the simplicity of a single parameter warrants 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 the action ('Delete (soft-delete)') and the resource ('a wallet'), with specific details about the effect ('no longer appear in listings and cannot be used for transactions'). It distinguishes from potential hard-delete operations by specifying 'soft-delete'.
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 a wallet needs to be removed from listings and transaction use, but doesn't explicitly state when to use this vs. alternatives like 'pause_wallet' or 'delete_paywall'. No explicit 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the return format ('in both raw and human-readable format') and the read-only nature implied by 'check', but lacks details on potential errors, rate limits, authentication needs, or network behavior. It adds some context but leaves gaps for a tool interacting with blockchain data.
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 zero waste: the first states the core functionality and return format, the second provides usage guidance. Every word earns its place, and key 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?
Given no annotations and no output schema, the description does well by explaining the return format and usage context. However, for a blockchain tool with 5 parameters and potential complexity (e.g., network calls, error cases), it could benefit from more behavioral details like what happens on invalid inputs or network failures.
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 5 parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't explain relationships between parameters like how wallet_id maps to owner address). Baseline 3 is appropriate when the schema does the heavy lifting.
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 with specific verbs ('check', 'returns') and resources ('ERC-20 tokens', 'allowance'), distinguishing it from siblings like get_balance or get_token_balance by focusing on spender approval amounts rather than ownership balances. It explicitly mentions what the tool does and what it returns.
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 explicit guidance on when to use this tool ('to check if an approval is needed before a DeFi transaction'), which differentiates it from alternatives like approve_token (which sets approvals) and get_balance (which checks ownership). It clearly states the practical context for usage.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's multi-step behavior (fetching, parsing payment requirements, executing payment, retrying) and includes important operational details like supporting the x402 standard and the max_payment safety feature. It lacks specifics on error handling or rate limits, but covers core behavioral traits well.
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 appropriately sized and front-loaded, starting with the core purpose and flow, then adding supporting details (standard reference, max_payment tip). Every sentence earns its place by contributing essential information without redundancy or 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 the tool's complexity (multi-step payment flow) and no annotations or output schema, the description does a good job explaining what the tool does and key considerations like max_payment. It could be more complete by detailing the return format or error cases, but it provides sufficient context for an agent to understand and invoke the tool 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 description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds some context by mentioning max_payment prevents overspending and referencing the x402 standard, but does not provide significant additional semantic meaning beyond what the schema descriptions offer. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 with specific verbs ('fetches', 'parses', 'executes', 'retries', 'returns') and resources ('URL', 'payment requirements', 'on-chain payment', 'final response'). It distinguishes from siblings by focusing on the x402 payment flow, unlike wallet management or token operations in 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 provides clear context for when to use this tool: for handling x402 payment flows when accessing URLs that may require payment. It mentions setting max_payment to prevent overspending, which is a practical guideline. However, it does not explicitly state when not to use it or name 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?
With no annotations provided, the description carries full burden. It clearly describes the core behavior (authorizing token transfers by a spender contract) and mentions security implications ('unlimited approval' vs 'exact amount'). However, it doesn't disclose other important behavioral traits like whether this requires gas fees, confirmation times, reversibility, or error conditions. The description adds value but leaves gaps for a mutation tool.
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 perfectly front-loaded with the core purpose in the first sentence, followed by usage context and parameter guidance. Both sentences earn their place by providing essential information without redundancy. The structure moves from general to specific efficiently.
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 mutation tool with 6 parameters, no annotations, and no output schema, the description is reasonably complete about purpose and usage but lacks details about behavioral consequences, return values, and error handling. It covers the 'why' and basic 'how' but not the full operational context an agent would need for safe 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 description coverage is 100%, so the baseline is 3. The description adds meaningful context for the 'amount' parameter by explaining the special 'max' value and contrasting it with exact amounts, which goes beyond the schema's technical description. However, it doesn't provide similar context for other parameters like 'decimals' or 'chain_id'.
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 ('Approve a spender contract to transfer ERC-20 tokens on your behalf') and distinguishes it from siblings like 'get_allowance' (which checks approvals) and 'transfer_token' (which executes transfers). It specifies the resource (ERC-20 tokens) and the authorization relationship (spender contract acting on behalf).
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 ('Required before interacting with any DeFi protocol (DEXs, lending, etc.)') and provides clear alternatives for the 'amount' parameter ('Use amount "max" for unlimited approval, or specify an exact amount'). It distinguishes from siblings by emphasizing this as a prerequisite authorization step.
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?
No annotations are provided, so the description carries the full burden. It discloses that this is a purchase transaction requiring on-chain payment with USDC and returns payment instructions, but lacks details on costs, rate limits, or error handling. The description adds some behavioral context but is incomplete for a financial transaction tool.
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 action and usage context, with no wasted words. Every sentence adds value by explaining the tool's purpose and behavioral outcome efficiently.
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 annotations and no output schema, the description covers the purpose and usage well but lacks details on costs, transaction confirmation, or error cases. For a financial tool with on-chain interactions, this leaves gaps in behavioral transparency, though it's adequate for basic understanding.
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 schema fully documents the 'count' parameter. The description doesn't add parameter details beyond the schema, but it contextually explains that credits are for verification beyond the free tier, which helps interpret the parameter's purpose. With 1 parameter and high schema coverage, baseline 3 is appropriate, but the added context justifies 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 the specific action ('Buy x402 verification credits with USDC on-chain'), identifies the resource ('verification credits'), and distinguishes it from siblings by focusing on credit purchasing for paywall owners, unlike tools like 'create_paywall' or 'get_usage'.
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 this tool: for paywall owners needing credits beyond the free tier (1,000/month) without Stripe billing. It also implies when not to use it (if within free tier or with Stripe), though it doesn't name specific 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively communicates key behavioral traits: that signing requires a wallet's private key, that it returns different formats for different chains (hex for EVM, base64 for Solana), and that it does NOT broadcast transactions. However, it doesn't mention error conditions, rate limits, or authentication requirements.
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 perfectly concise with three sentences that each serve a distinct purpose: stating the core function, specifying return formats for different chains, and providing critical usage guidance. There is zero wasted language or 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?
For a complex transaction signing tool with 10 parameters and no output schema, the description provides good context about what the tool does and when to use it. However, it doesn't explain what happens with the signed transaction output or provide examples of typical next steps after signing, which would be helpful given the absence of an 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 description coverage is 100%, so the schema already documents all 10 parameters thoroughly. The description adds minimal parameter-specific information beyond what's in the schema, mainly clarifying the different return formats for EVM vs Solana. This meets the baseline expectation when schema coverage is complete.
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 ('sign a transaction with a wallet's private key'), identifies the resource (transaction), and distinguishes from sibling tools by explicitly contrasting with 'send_transaction' for sign+broadcast. It provides clear differentiation from related operations.
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 explicit guidance on when to use this tool ('sign a transaction') versus when to use an alternative ('use send_transaction for sign + broadcast'). It clearly defines the tool's scope as signing-only and directs users to the appropriate alternative for broadcasting.
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:

[![agentwallet-mcp MCP server](https://glama.ai/mcp/servers/hifriendbot/agentwallet-mcp/badges/card.svg)](https://glama.ai/mcp/servers/hifriendbot/agentwallet-mcp)

Score Badge

Copy to your README.md:

[![agentwallet-mcp MCP server](https://glama.ai/mcp/servers/hifriendbot/agentwallet-mcp/badges/score.svg)](https://glama.ai/mcp/servers/hifriendbot/agentwallet-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/hifriendbot/agentwallet-mcp'

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