x402-mcp-commerce

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct resource or action: catalog browsing vs. buying, flight search vs. price confirmation, table search vs. booking, and separate tools for weather, places, news, domains, and payment/spending metadata. There is no overlap that would cause an agent to select the wrong tool for its intent.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (browse_catalog, search_flights, book_table, check_weather, track_confirmation). The verbs are appropriate and uniform, making the expected function of each tool predictable.
Tool Count5/5
With 15 tools, the server sits at the upper edge of the well-scoped range. Each tool addresses a distinct service or workflow, and the breadth reflects the 'commerce marketplace' concept without excessive redundancy or trivial additions.
Completeness3/5
The server provides search and booking for tables but only search for flights and hotels, with no booking or cancellation tools for those domains. While buy_item covers storefront purchases, there is no order history or cancellation mechanism. The spending_report and track_confirmation tools help, but the missing lifecycle steps are notable gaps.
Average 4.2/5 across 15 of 15 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the return value (merchant's artifact and payment receipt) and mentions the payment mechanism (USDC over x402), which is useful. However, the phrases 'Free at the merchant' and 'Costs free per call, paid in USDC over x402' are internally contradictory about whether the call involves payment, causing ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core purpose. However, 'Free at the merchant' and 'Costs free per call' are redundant, and the payment wording could be tightened without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-optional-parameter tool with no output schema, the description provides enough scope: what is returned, the cost/payment context, and the listing focus. However, the term 'artifact' is vague and the payment ambiguity is not resolved, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single 'rail' parameter, and its schema description already explains the enum values and default 'auto'. The tool description adds no additional parameter-level meaning, so the baseline of 3 is appropriate for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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'), the target resource ('a storefront's items'), and the key details ('with prices and buy routes'). This distinguishes it from sibling tools like buy_item (which purchases) and list_commerce_tools (which likely lists tools).
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 this is for browsing a catalog before purchasing, but does not explicitly state when to use it versus alternatives like buy_item or list_commerce_tools. It gives context about cost and payment but lacks direct usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the operation is read-only ('Read') and that no payment is made ('Free — no payment is made'), which is useful. However, it does not address error handling, authentication requirements, or the case where the manifest is unavailable, leaving gaps in behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences: the first front-loads the core purpose, and the second adds a clarifying cost note. 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple discovery tool with one parameter, no output schema, and no annotations, the description sufficiently covers what the tool does and what the user will learn (routes, prices, payment rails, schemas). It omits edge-case behavior like errors or unavailable manifests, but given the tool's simplicity, it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a complete description of baseUrl with an example. The tool description reinforces that baseUrl is the service origin but adds no additional syntax or format details beyond what the schema provides. Since schema coverage is 100%, the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action ('Read'), the resource (x402 service's /.well-known/x402 manifest), and the outcome (learn routes, prices, payment rails, response schemas). This clearly distinguishes it from sibling tools like browse_catalog and list_commerce_tools, which focus on different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for discovering a service's capabilities before interacting, but it does not explicitly state when to use it versus alternatives or mention any exclusions. The 'Free — no payment is made' note hints at a low-cost operation but does not provide explicit guidance on sibling tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description transparently discloses the paid nature of the call ($0.005 per call), payment method (USDC over x402), and that it returns the merchant's artifact and payment receipt. This provides key behavioral context beyond what schema offers, though it lacks details on authentication or error handling.
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, then adds cost and return information. Every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (paid API, 7 parameters, no output schema), the description adequately covers return values by specifying the type of data returned (priced offers with airline, times, stops, fare basis) and the additional artifact/receipt. It lacks details on pagination or round-trip behavior, but schema covers the optional returnDate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all parameters, so the baseline is 3. The description adds no extra parameter semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches flights between two airports on a date, which is a specific verb+resource+scope. It distinguishes from siblings like price_flight by mentioning it returns priced offers with airline, times, stops, and fare basis, indicating a broader search 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 for flight searching but does not explicitly state when to use this tool versus alternatives like price_flight. No exclusions or alternative recommendations are provided, so usage guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 cost ($0.005 per call), payment method (USDC over x402 to x402-hotel-search), and return payload (merchant's artifact and payment receipt). It does not mention potential side effects beyond payment or failure modes, which keeps it short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise, informative sentences. The first sentence states the core purpose, the second provides payment details, and the third states the return value. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description adequately explains the return value (merchant's artifact and payment receipt) and covers cost/payment, but does not explain how results are represented or preconditions like having a rail key. Given schema descriptions cover all parameters, 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 coverage is 100%, so the baseline is 3. The description only echoes 'city and date range' which maps to cityCode, checkIn, and checkOut, without adding syntax or details beyond the schema. No added meaning for adults or rail parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool searches hotel rooms and offers for a city and date range, with a specific verb ('Search') and resource, distinguishing it from sibling tools like search_flights and find_tables.
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?
It does not explicitly state when to use this over siblings or provide exclusions, but the scope ('hotel rooms and offers for a city and date range') implies the use case. No alternative tools are named, so context is clear but not explicit.
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 of behavioral disclosure. It discloses the cost ('Costs $0.005 per call'), payment method ('paid in USDC over x402'), and return value ('Returns the merchant's artifact and the payment receipt'). However, it does not elaborate on failure modes, validation requirements, or any side effects beyond generating an ICS invite, leaving some behavioral uncertainty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, with the core purpose in the first sentence and essential operational details (cost, payment, return) in the following two. Every sentence provides value, there is no fluff, and it is front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 params, nested objects, no required params, no output schema), the description gives enough context for an agent to understand its function and when to call it. It clearly states the cost, payment rail, and return value. However, it could be more explicit about the input expectations (e.g., how to provide rawText vs. confirmation) and any prerequisites for using the payment rail, but the schema and overall context make it 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?
The input schema already provides descriptions for all four parameters, so the baseline is 3. The description adds minimal extra parameter semantics, only implying that the 'confirmation' parameter should be the artifact from a booking tool. It does not explain how 'rawText' and 'confirmation' relate or when to use one over the other, but the schema descriptions cover their basic meanings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Normalize any merchant confirmation into a portable record plus an ICS calendar invite.' It uses a specific verb ('Normalize') and distinguishes this tool from booking/search siblings by focusing on the post-booking confirmation processing step. The phrase 'any merchant confirmation' conveys broad scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: 'Feed it the artifact any booking tool returned.' This clearly situates it after a booking or purchase flow, differentiating it from the search/booking siblings. It does not explicitly mention when not to use it, but the context is sufficient for an agent to know it's for confirmation normalization rather than discovery or purchasing.
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, the description carries the burden and does well: it discloses cost per call, payment method (USDC over x402 to x402-tablebook), that the hold is refundable, and what is returned (confirmed reservation, cancel token, refund terms, calendar invite, artifact, payment receipt). It lacks detail on failure handling or cancellation process, but provides significant transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the main action, followed by return details and cost. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a booking tool with 6 params and no output schema, the description covers the return value and payment specifics. It could mention prerequisites or failure modes, but the core aspects for invocation are present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter has a clear meaning. The description adds context about payment rails and cost but does not elaborate on individual parameters beyond what schema provides. Hence baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool books a restaurant table with a specific verb and resource, and distinguishes from sibling find_tables by focusing on the booking action. It also mentions the return value, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when a restaurant table needs to be reserved, distinct from find_tables which searches. However, it does not explicitly state when not to use it or mention alternatives, so it falls short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since there are no annotations, the description carries the transparency burden. It discloses payment method (USDC over x402), per-call costs, and return behavior for both digital and physical goods. It lacks details on failure modes or auth requirements, but covers the essential transaction behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action, and every clause adds value: payment method, item types, and return artifacts. There's no repetition of schema fields or wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description explains the return values (merchant's artifact and payment receipt) and specifics for digital vs physical goods. It could mention prerequisites like having funds or error cases, but it is sufficiently complete for a purchasing action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaning by explaining the digital versus physical distinction (which clarifies when shipping fields are relevant) and describes the payment rail override purpose, enhancing the schema descriptions with transaction 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 tool's verb ('Buy') and resource ('item from a storefront'), distinguishing it from siblings like browse_catalog and book_table. It further specifies results for digital vs physical goods, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: the sku comes from browse_catalog and payment rails can be overridden. However, it does not explicitly say when to use this tool vs alternatives like list_commerce_tools or spending_report, nor does it state prerequisites like having a funded wallet.
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, the description carries the full burden of behavioral disclosure. It transparently reveals the cost ($0.001 per call), payment mechanism (USDC over x402 to x402-tablebook), and what it returns (merchant's artifact and payment receipt). This goes beyond typical list tools by disclosing the payment side effect, which is crucial for an agent to understand before invoking.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long. The first sentence states the purpose, and the second covers cost, payment, and return values. It is front-loaded, with no filler or unnecessary detail.
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?
Despite having no output schema, the description explains what is returned (merchant's artifact and payment receipt). It also discloses the cost and payment rail, which is essential context for a paid tool. However, it does not clarify the structure of the merchant's artifact or the exact behavior of the 'days' parameter (though the schema covers it), leaving some minor ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides complete descriptions for all 4 parameters, and the description does not add additional meaning or examples. Per the rubric, when schema coverage is high (100%), a baseline of 3 is appropriate. The description only reiterates 'date and party size' from the purpose, adding no new semantic detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'List open restaurant reservation slots for a date and party size.' This specifies the verb ('List'), the resource ('restaurant reservation slots'), and the key parameters. It also distinguishes itself from the sibling 'book_table' tool, which presumably handles reservations.
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 clearly implies when to use this tool: when you need to find open reservation slots for a date and party size. It provides the context (date, party size) and distinguishes itself from booking tools by focusing on listing. However, it does not explicitly name alternatives or state when not to use it, though the purpose is clear from the first sentence.
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, the description carries the full burden and discloses important behavioral traits: the call costs $0.003 paid via x402, and it returns the merchant's artifact and payment receipt. 'Confirm' and 'before booking' imply no booking side effect. It does not explain hold times or failure refunds, but the core cost and return behavior are transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, with the core purpose front-loaded. Every sentence earns its place: purpose, cost/payment method, and return values. No filler or redundant restatement of the tool name.
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 two-parameter tool with no output schema, the description adequately explains the return values (merchant artifact and payment receipt) and adds essential context (cost and payment rail). It could mention what happens if the offer is no longer available, but overall it provides enough to understand the tool's role in the flight-booking workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds no information about the parameters beyond what the schema already provides (offerId from search_flights, rail override). The schema's own descriptions are sufficient, so the description neither hurts nor meaningfully enhances parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Confirm') and clearly identifies the resource ('live price and availability of a specific flight offer') and the context ('before booking'). It is immediately distinguishable from sibling tools like search_flights, which finds offers rather than confirming a chosen one.
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 phrase 'before booking' clearly indicates when the tool should be used, and the instruction to use an 'offerId from search_flights' implies the preceding step. However, it does not explicitly name alternatives or state when not to use it, so it stops short of full usage differentiation.
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, the description carries the burden of behavioral disclosure. It adds valuable context: the tool costs $0.003 per call, requires payment in USDC via x402, and returns both the merchant's artifact and payment receipt. This goes beyond a basic read-only impression, though it does not detail failure modes or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences: the first states the core purpose, the second covers cost, payment, and return values. Every word earns its place, and the content is front-loaded with the most important information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description compensates by explaining the return format (merchant's artifact and payment receipt) and the payment mechanism. It covers the essential operational context, though it could elaborate on what the artifact contains or how the result is structured.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all parameters with 100% coverage, so the baseline is 3. The description adds some relational context ('topic' maps to q, 'time window' maps to since, 'max articles' maps to limit), but it does not provide additional syntax or formatting details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Query') and names the exact resource ('the global news wire') with a clear scope ('coverage of a topic in a time window'). This clearly distinguishes it from sibling tools like search_flights and search_hotels, which serve different domains.
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 clearly indicates when to use the tool: when you need news coverage on a topic within a time window. It does not explicitly name alternatives or exclusions, but the context is sufficiently clear given the sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses cost ('$0.002 per call'), payment mechanism ('USDC over x402 to x402-places'), and return content ('merchant's artifact and the payment receipt'). This goes beyond the schema and provides useful behavioral context, though it does not mention side effects or safety characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states purpose and scope, the second states cost and return. It is front-loaded, every sentence provides value, and there is no unnecessary repetition of schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description explains the core purpose, cost, payment, and return. It does not specify result ordering, limits, or error handling, but for a search tool with schema-covered parameters, this is reasonably complete. The mention of 'merchant's artifact and payment receipt' gives a sense of output structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 minimal meaning beyond the schema, only loosely connecting 'near a point or in a named area' to parameters like q, lat, lon, and radius. It does not introduce new semantic details for any parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Find') and identifies the resource ('places') with concrete examples ('restaurants, shops, landmarks') and spatial scope ('near a point or in a named area'). This clearly distinguishes it from sibling tools like search_flights or search_hotels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context for use is clear: it finds places near a point or area. However, it does not explicitly state when to avoid this tool or compare it to alternatives like discover_service. No exclusions are mentioned, so it earns a 4 for clear context without explicit 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?
No annotations are provided, so the description carries the full burden. It discloses the cost ($0.001 per call), the payment method (USDC over x402 to x402-domains), and the return payload (merchant's artifact and payment receipt). This is a strong disclosure for a paid tool, though it stops short of covering edge cases or failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary purpose, followed by cost and return information. Every sentence earns its place; there is no fluff or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a relatively simple paid lookup tool, the description covers the essential context: what it does, what it costs, how to pay, and what is returned. Since there is no output schema, the description appropriately substitutes by naming the return items. This is complete for practical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for both parameters: 'domain' is described with an example, and 'rail' has a clear enum with default behavior. The description adds no additional parameter semantics beyond the schema, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Purpose is clearly stated with a specific verb ('Check') and resource ('domain'), and it distinguishes itself from sibling tools by describing the exact output: registration status, holder, and expiry. This is unambiguous and unlikely to be confused with any other tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use the tool: when you need domain registration details. It doesn't explicitly mention alternatives or exclusions, but the context is clear enough given the unrelated sibling tools, so no further guidance is strictly needed.
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 must convey behavioral traits. It explicitly states 'Free — no payment is made,' which addresses cost concerns. The verb 'List' suggests a read-only operation, but it does not explicitly guarantee no side effects or disclose other behaviors like pagination. Still, the added cost info is valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the core purpose, and includes useful additional detail without fluff. Each sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless listing tool, the description covers what is listed, what attributes are returned, and cost. Without an output schema, this is sufficient for an agent to understand what to expect. No further detail is necessary.
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 zero parameters, so there is nothing to explain beyond the schema. The description adds context about what the listing includes, but parameter semantics are inherently covered by the empty schema, earning the baseline score for no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to list every commerce tool exposed by the server, including specific attributes (upstream service, price, payment rail). This distinguishes it from sibling tools which perform distinct actions like buying, pricing, or booking.
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 this tool is for enumerating available commerce tools, but it does not explicitly state when to prefer it over alternatives or mention any exclusions. It provides context about being free but lacks direct usage guidance 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It transparently discloses that the tool costs money ($0.001), the payment mechanism (USDC over x402 to x402-weather-guard), and the return payload (merchant artifact and payment receipt). It does not detail failure modes or side effects, but the read-only nature of a forecast is implicit and the payment behavior is well disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly three sentences, with the first sentence front-loading the core purpose and use case. Each sentence earns its place: purpose, cost/payment, and return value. There is no redundancy or filler.
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?
Despite having no output schema and no annotations, the description covers the essential practical aspects: what the tool does, why to use it, cost, payment mechanism, and what it returns. It could be more explicit about the format of the plan-relevant summary and error handling, but for selecting and invoking the tool, it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters are already described in the schema (100% coverage), so the baseline is 3. The description adds meaningful context by tying the payment rail to the actual cost and x402 recipient, and it clarifies that the output is tailored for booking decisions. This lifts it above 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 opens with a specific verb+resource ('Forecast for a location') and immediately ties it to a use case: deciding whether an outdoor booking is a good idea. Among the sibling tools, there is no other weather tool, so it is clearly distinguished.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a clear trigger for use ('whether an outdoor booking is a good idea') and enough context for an agent to know when to call. It does not explicitly name alternatives or exclusions, but no sibling directly competes, so the guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explicitly states 'Free — no payment is made,' revealing that invoking the tool has no financial side effects. It also uses 'Show' which implies a read-only operation, providing transparency about its non-destructive nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core function and ending with a helpful cost note. Every word earns its place, with no filler or redundant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only report tool with no parameters, no annotations, and no output schema, the description fully covers what the agent needs to know: what it shows (caps, spent amount, payments), scope (this session), and cost (free). It leaves no significant gaps.
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 zero parameters, so there is nothing for the description to explain. As per the baseline for 0 params, a score of 4 is appropriate. The description nonetheless clarifies that the report is about the current session, adding context beyond the empty 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 states a specific verb ('Show') and resource ('this agent's spending caps, how much it has spent so far, and every payment it has made in this session'). It clearly distinguishes itself from siblings by focusing on reporting spending data rather than performing actions.
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 the tool (to check spending caps, total spent, and payments in the session). It does not explicitly name alternatives or exclusions, but states 'Free — no payment is made,' which signals it is a safe, non-costly action. This is clear enough, though not fully explicit about when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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:

[![x402-mcp-commerce MCP server](https://glama.ai/mcp/servers/nirholas/x402-mcp-commerce/badges/card.svg)](https://glama.ai/mcp/servers/nirholas/x402-mcp-commerce)

Score Badge

Copy to your README.md:

[![x402-mcp-commerce MCP server](https://glama.ai/mcp/servers/nirholas/x402-mcp-commerce/badges/score.svg)](https://glama.ai/mcp/servers/nirholas/x402-mcp-commerce)

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/nirholas/x402-mcp-commerce'

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