AgentPay-mcp

Server Quality Checklist

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

Latest release: v3.0.1
Disambiguation4/5
The tools are mostly distinct with clear purposes, but there is some overlap between check_spend_limit and send_payment, as both involve spend limit checks, which could cause minor confusion. The x402 session tools are well-differentiated, and other tools like deploy_wallet and get_transaction_history have unique functions.
Naming Consistency4/5
Naming is mostly consistent with a verb_noun pattern, such as check_spend_limit and send_payment, but there are minor deviations like x402_pay (which mixes protocol prefix with verb) and the x402_session_* tools that use a consistent prefix but vary in verb style. Overall, it's readable with only slight inconsistencies.
Tool Count5/5
With 11 tools, the count is well-scoped for managing AgentPay wallets and x402 payments. Each tool serves a specific purpose, such as deployment, transactions, and session management, without feeling excessive or insufficient for the domain.
Completeness5/5
The tool set provides comprehensive coverage for wallet management and x402 payment handling. It includes deployment, transaction sending, limit checks, history retrieval, approval queuing, and full session lifecycle management, leaving no obvious gaps for the intended use cases.
Average 4.3/5 across 11 of 11 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 2 of 10 community issues answered or closed in the last 6 months
- 9 commits in the last 12 weeks
- Last stable release on February 26, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
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

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 what data is retrieved ('executions, queued transactions, approvals, cancellations, spend policy updates, and operator changes') but lacks details on permissions, rate limits, pagination, or error handling. It adds some context about filtering but is incomplete for a read operation with no 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 front-loaded with the core purpose in the first sentence, followed by specific details and usage guidance in the second. Both sentences are essential—no wasted words—making it efficient 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 complexity (4 parameters, no annotations, no output schema), the description is adequate but has gaps. It explains what data is retrieved and filtering options, but lacks details on return format, error cases, or prerequisites. Without annotations or output schema, more behavioral context would improve completeness for a historical query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value by mentioning filtering by 'event type or block range', which aligns with the schema but does not provide additional semantics beyond what the schema specifies. 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 ('Retrieve') and resource ('wallet's recent on-chain transaction history from event logs'), and distinguishes this tool from siblings by focusing on historical transaction data rather than current operations (like check_spend_limit) or wallet management (like deploy_wallet).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage ('Filter by event type or block range for targeted queries'), but does not explicitly state when to use this tool versus alternatives like get_wallet_info or when not to use it. It implies usage for historical queries without naming specific sibling alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's function and scope (read-only data retrieval for wallet status), but lacks details on potential errors, rate limits, authentication needs, or response format. It adds value beyond the schema by explaining the token parameter's purpose, but does not fully compensate for the absence of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by specific usage guidance. Both sentences are essential—the first defines scope, the second explains parameter usage—with zero redundant or vague language, making it highly 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 tool's moderate complexity (1 optional parameter, no output schema, no annotations), the description is adequate but has gaps. It clearly explains what the tool does and parameter usage, but lacks details on output structure, error conditions, or dependencies. Without annotations or output schema, the description does not fully compensate for these missing elements, making it minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the baseline is 3. The description adds meaningful context by explaining that the token parameter is used 'to check budget for a specific ERC20' and defaults to ETH, which clarifies the semantic purpose beyond the schema's technical specification. This elevates the score above the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get comprehensive wallet information') and enumerates the exact data returned (address, on-chain balance, spend limits, remaining period allowance, queue depth). It distinguishes from siblings like 'get_transaction_history' (historical data) or 'check_spend_limit' (specific limit check) by emphasizing comprehensive status retrieval.
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 check budget for a specific ERC20') and mentions the default behavior (defaults to ETH). However, it does not explicitly state when to use alternatives like 'check_spend_limit' for focused limit queries or 'get_transaction_history' for past activity, leaving some sibling differentiation implicit.
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 does well by explaining the return format ('clear yes/no with remaining budget details') and the practical consequence ('avoid surprise queuing'), but doesn't mention authentication requirements, rate limits, error conditions, or whether this is a read-only operation (though 'check' 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?
The description is perfectly concise with two sentences that each earn their place. The first sentence states the purpose and return value, the second provides crucial usage guidance. No wasted words, and the most important information (what it does) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter tool with no annotations and no output schema, the description does well by explaining the purpose, return format, and usage context. However, it could be more complete by explicitly stating this is a read-only operation (implied but not stated) and mentioning any authentication requirements. The connection to 'send_payment' is excellent contextual guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 fully documents both parameters. The description doesn't add any parameter-specific information beyond what's in the schema (it mentions 'proposed payment amount' which aligns with 'amount_eth' but provides no additional syntax or format details). 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 verb ('check') and resource ('proposed payment amount'), and distinguishes it from sibling tools by explicitly mentioning 'send_payment' as an alternative. It explains what the tool does (verifies if amount is within wallet's autonomous spend limits) and what it returns (yes/no with budget details).
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 ('Use this before send_payment to avoid surprise queuing'), clearly positioning it as a prerequisite check. It distinguishes from the 'send_payment' sibling by explaining the sequential relationship and purpose (avoid queuing).
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 key behaviors: the deterministic addressing (CREATE2), NFT ownership, return values (wallet address and transaction hash), and environment variable requirements. It doesn't mention potential side effects like gas costs or blockchain confirmation times, but covers the core operational behavior adequately for a deployment 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 efficiently structured in two sentences: the first states the core purpose and key characteristics, the second covers return values and configuration options. Every phrase adds value with zero redundant information, making it easy to parse quickly.
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 deployment tool with no annotations and no output schema, the description provides good coverage: it explains what the tool does, how it works, what it returns, and configuration options. The main gap is the lack of explicit output format details (though 'wallet address and deployment transaction hash' gives a general idea), but given the tool's straightforward purpose, this is reasonably 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 adds minimal parameter semantics beyond the schema, mainly noting that factory_address and nft_contract_address can come from environment variables. This meets the baseline expectation when schema coverage is high.
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 ('Deploy a new AgentAccountV2 wallet'), the mechanism ('via the factory contract'), and key characteristics ('deterministically addressed (CREATE2) and owned by an NFT'). It distinguishes this tool from sibling tools like 'check_spend_limit' or 'send_payment' by focusing on wallet creation rather than transaction management or querying.
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 deploy a new wallet with specific ownership and addressing. It mentions environmental variable alternatives ('Requires FACTORY_ADDRESS and NFT_CONTRACT_ADDRESS env vars (or pass them as arguments)'), which helps guide parameter usage. However, it doesn't explicitly state when NOT to use it or compare it to specific sibling tools for similar functions.
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 the tool can list sessions or show details, but lacks information on permissions, rate limits, error conditions, or response format. It adds some context about TTL and details like call count and payment info, but behavioral traits are incomplete.
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 and concise, with two sentences that efficiently cover purpose and usage without wasted words. Every sentence earns its place by providing essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is moderately complete for a read-only tool. It explains what the tool does and how to use it, but lacks details on return values, error handling, or operational constraints, leaving gaps in context.
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 already documents the parameter. The description adds value by explaining the semantic effect: omitting the parameter lists all active sessions, while including it shows full details for a specific session. This goes beyond the schema's basic description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('check', 'lists', 'shows') and resources ('x402 V2 payment sessions'), and distinguishes it from siblings by focusing on session status rather than creation, ending, or payment actions.
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?
It explicitly states when to use the tool: 'Without arguments, lists all active sessions with TTL remaining. With a session_id, shows full details for that session.' This provides clear guidance on usage based on parameter presence.
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 key behaviors: immediate execution within limits, queuing for owner approval if exceeding limits, and the need to check limits first. It doesn't cover rate limits or auth needs, but provides substantial 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 efficiently structured with three sentences: purpose, conditional behavior, and prerequisite action. Every sentence adds value—no wasted words—and it's front-loaded with the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a payment tool with no annotations and no output schema, the description does well by explaining the execution flow (immediate vs. queued) and linking to related tools. It could mention return values (tx hash) more explicitly, but overall it's quite complete given the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description doesn't add any parameter-specific semantics beyond what's in the schema (e.g., it doesn't explain token address format or memo usage further). 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: 'Send ETH or ERC20 tokens from the Agent Wallet.' It specifies the action (send), resources (ETH/ERC20 tokens), and source (Agent Wallet), distinguishing it from siblings like check_spend_limit or get_transaction_history.
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 vs. alternatives: 'Always check spend limits first with check_spend_limit to avoid surprises.' It also explains what happens if limits are exceeded (queued for approval, use queue_approval to manage), offering clear context and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: automatic handling of HTTP 402 responses, session token usage to avoid costs, payment rejection based on spend limits or max_payment_eth cap, and the underlying x402 protocol on Base network. However, it lacks details on error handling or response formats, 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 appropriately sized and front-loaded, with the core functionality stated first. Each sentence adds value: explaining session handling, payment logic, rejection conditions, protocol details, and a usage tip. There is no wasted text, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (payment handling, session management) and no annotations or output schema, the description is largely complete. It covers the main behavioral aspects and usage context. However, it could benefit from more details on error scenarios or response formats to achieve full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all 7 parameters thoroughly. The description adds minimal parameter semantics beyond the schema, such as implying 'url' is the target for payment handling and 'max_payment_eth' sets a cap. 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 tool's purpose: fetching a URL while automatically handling HTTP 402 Payment Required responses. It specifies the verb ('fetch') and resource ('URL'), and distinguishes it from siblings by mentioning the x402 protocol and session handling capabilities, unlike generic payment or session tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 vs alternatives. It states to use 'x402_session_start to pay once for a session and save on repeated calls,' indicating an alternative for cost-saving scenarios. It also implies usage for URLs requiring payment, with no misleading suggestions.
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 key behaviors: it's a destructive operation (closes a session), has side effects (x402_session_fetch will return an error), and mentions security implications. It doesn't cover rate limits or authentication needs, but provides substantial context beyond basic function.
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 immediate effect, the second provides usage context. Every phrase adds value without redundancy, making it front-loaded and appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (destructive operation with security implications), no annotations, and no output schema, the description does well by explaining the action, effects, and usage scenarios. It could be more complete by mentioning authentication requirements or response format, but it covers the essential context for safe 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 session_id parameter fully documented in the schema. The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints. 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 ('explicitly close') and resource ('an x402 V2 session'), distinguishing it from siblings like x402_session_fetch, x402_session_start, and x402_session_status. It precisely defines what the tool does beyond just restating the name.
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 ('before it expires naturally', 'useful for security hygiene or when you know a session is no longer needed') and provides a clear alternative (letting it expire naturally). It also mentions the consequence for x402_session_fetch, guiding usage relative 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 and does well by disclosing key behaviors: it automatically attaches the session token, grants access without payment, and returns an error for expired sessions. However, it lacks details on rate limits, authentication needs beyond the session, or what specific errors might occur, 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 essential context and error handling. Every sentence adds value—no wasted words—and it's structured logically from usage to prerequisites to error resolution.
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 (session-based HTTP requests with 6 parameters), no annotations, and no output schema, the description is mostly complete. It covers purpose, usage, prerequisites, and error handling, but lacks details on return values or advanced behavioral traits like rate limits, which would be helpful for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema, only implying that the URL must be 'covered by the session' and noting automatic token injection, but doesn't provide additional syntax or format details. 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 ('Make an HTTP request within an established x402 V2 session') and resource (session-based HTTP requests), distinguishing it from siblings like x402_session_start (which creates sessions) and x402_pay (which involves payments). It explicitly notes 'NO payment required' to differentiate from payment-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('within an established x402 V2 session'), prerequisites ('Requires a session_id from x402_session_start'), and alternatives for errors ('call x402_session_start again to renew'). It also clarifies when not to use it ('NO payment required'), distinguishing it from payment tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: the payment mechanism (on-chain payment), session token characteristics (cryptographically signed, non-custodial), session lifetime concept, and the relationship with x402_session_fetch. It could be improved by mentioning 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 well-structured and efficiently conveys essential information in four sentences. Each sentence adds value: establishing the session, explaining the session-fetch relationship, describing the payment model, and detailing the token characteristics. There's no wasted text.
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 tool with 9 parameters, no annotations, and no output schema, the description provides good context about the tool's purpose, usage patterns, and behavioral characteristics. It explains the return value (session_id) and how to use it. It could be more complete by mentioning error conditions or providing examples of typical use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already documents all 9 parameters thoroughly. The description adds some context about the session establishment process but doesn't provide additional parameter-specific semantics beyond what's in the schema. 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 tool's purpose: 'Establish an x402 V2 payment session' with specific details about making a single on-chain payment and receiving a signed session token. It distinguishes from sibling tools like x402_session_fetch by explaining the relationship between them.
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 usage guidelines: 'All subsequent calls to the same endpoint within the session lifetime use x402_session_fetch — no additional payments required.' It clearly explains when to use this tool versus its sibling x402_session_fetch, and mentions the 'Agents pay once per session rather than once per API call' principle.
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?
No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: the tool manages queued transactions for review, requires owner privileges for approve/cancel actions, and implies mutation capabilities (approve/cancel are destructive). However, it lacks details on error handling, rate limits, or response formats, 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 purpose, followed by usage instructions and prerequisites in two concise sentences. Every sentence adds essential information without redundancy, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description does well by covering purpose, usage, and behavioral aspects like privileges. However, it lacks details on return values, error cases, or pagination for the list action, which could be important for a tool with mutation capabilities.
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 value by explaining the semantics of the 'action' parameter (list for pending transactions, approve/cancel by ID) and clarifying that 'tx_id' is required for approve/cancel, which enhances understanding beyond the schema's enum and required fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Manage over-limit transactions queued for owner review.' It specifies the verb ('manage') and resource ('over-limit transactions'), distinguishing it from sibling tools like check_spend_limit or send_payment, which handle different aspects of transactions.
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 usage guidance: 'Use action="list" to see pending transactions, "approve" to approve one by ID, or "cancel" to cancel one by ID.' It also specifies prerequisites: 'Approve/cancel require the agent key to have owner privileges,' clearly indicating when and how to use each action.
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:

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

Score Badge

Copy to your README.md:

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

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