x402station-mcp

Server Quality Checklist

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

Latest release: v1.0.10
Disambiguation5/5
Each tool serves a distinct function: preflight checks, alternative endpoints, credit management, forensics, catalog blacklists, watch subscriptions, and catalog diffs. Descriptions are detailed, leaving no ambiguity about tool purposes.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., buy_credits, watch_subscribe, whats_new), making predictions and selection straightforward for an agent.
Tool Count5/5
With 10 tools, the server covers its domain of endpoint safety monitoring, credit management, and subscription alerts without being overly bloated or sparse.
Completeness4/5
The tool surface covers the main workflow: preflight checks, alternatives, credit buying, status, forensics, blacklisting, watching, and polling. A minor gap is the lack of a free endpoint status query for a single URL, but the paid preflight covers it.
Average 4.4/5 across 10 of 10 tools scored. Lowest: 3.8/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 2 commits in the last 12 weeks
- Last stable release on May 8, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behavioral details beyond a simple read: it explains that the tool is free, that anyone with the creditId can access it (security implication), and that 404 errors intentionally blur malformed UUIDs and non-existent credits to prevent enumeration. This is valuable 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 sentences long, front-loading the key information (free, return fields) and then adding security notes. Every sentence serves a purpose; no redundancy or filler. It is maximally efficient for its informational load.
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 tool with one parameter and no output schema, the description is complete: it lists the return fields, explains the access model, and addresses security. Given the low complexity and good schema coverage, no additional context is needed.
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 already describes the creditId parameter with format and origin. The description adds meaning by framing the parameter as a secret that gives anyone holding it read access, echoing the decrement permission model. This enhances the parameter's semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The title and description clearly state the tool reads a credit's balance and expiry. It lists the returned fields, making the purpose explicit. However, it does not explicitly differentiate from siblings like buy_credits or preflight, leaving some ambiguity for an AI agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes that no payment is required and that anyone with the UUID can read state, but it does not provide explicit guidance on when to use this tool versus alternatives like buy_credits or forensics. There is no mention of prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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, return structure, the need to store creditId (not retrievable later), header usage, expiration (90 days), and fallback behavior. Lacks details on error handling but is otherwise transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph of six sentences, front-loaded with the main purpose. It covers cost, returns, usage, and fallback without unnecessary words. Could be more structured but is concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains return values ({ creditId, balance, expiresAt }) and provides complete usage instructions including header and fallback. It covers the lifecycle well, though missing prerequisites like account setup.
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 0 parameters, so baseline score of 4 applies. The description does not need to add parameter meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Bulk-prepaid preflight bundle' and specifies paying $0.50 USDC for 1000 calls, making the action and resource clear. It distinguishes from siblings like 'preflight' (which performs calls) and 'credits_status' (which checks balance).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Use this once you've decided to do high-volume preflight work,' providing a clear context for use. It implicitly contrasts with per-call pricing via the fallback mechanism, but does not explicitly list when not to use or compare with 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?
Without annotations, the description covers key behavior: cost, duration, prepaid alerts, returned watchId and secret, HMAC verification, and that the secret is non-retrievable. It does not mention cancellation or error scenarios but is substantial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loading the purpose and cost. It is concise but could be slightly more structured (e.g., separating return info). No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description mentions returns (watchId + secret) and explains the secret's role. It covers subscription details and defaults, though it omits error cases or endpoint validation. Sufficient for a tool with few parameters.
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%, and the description adds value by stating the default signals and reinforcing webhookUrl constraints (HTTPS, no userinfo, SSRF guard). This enhances understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The title and description clearly state the tool subscribes to webhook alerts for x402 endpoint state changes, specifying the cost, duration, and alert count. It distinguishes from sibling tools like watch_status and watch_unsubscribe.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the subscription process, default signals, and the need to store the secret, but lacks explicit guidance on when to use this tool versus alternatives like watch_status or watch_unsubscribe. However, the context of cost and setup is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although no annotations are provided, the description fully discloses cost and caching recommendation. It implies a read-only operation with no side effects. Lacks details on rate limits or error responses, but for a simple data retrieval tool, it is sufficiently 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?
Two sentences, front-loaded with the core purpose, then immediately followed by actionable usage guidance and cost. No wasted words; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description covers purpose, cost, and usage pattern. Minor gaps: does not mention authentication requirements or typical result size. Still fairly complete for a simple blacklist tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline is 4. Description adds value by specifying what is returned (active endpoints + counts), going 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?
Description clearly states it returns active flagged x402 endpoints with per-reason counts. Verb 'returns' and specific resource ('catalog of decoys/zombie blacklist') make purpose unambiguous. Distinguishes from siblings by noting it's a blacklist meant for periodic caching, unlike preflight or other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to pull periodically and cache locally, and contrasts with 'preflighting every URL' as a cheaper alternative. Provides cost context ($0.005 USDC). Could be more explicit about when not to use, but gives clear context on the intended use case.
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 provided, but description discloses cost ($0.001 USDC) and the scope of data (7-day history). It does not mention potential failure cases or permissions, but overall 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?
Two concise sentences front-load all critical information: data provided, cost, and relationship to sibling tool. 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?
With no output schema, the description adequately explains the return data (list of metrics). Could mention pagination or error handling, but the depth is sufficient for a paid 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 already covers the single parameter with a clear description. The description adds that the URL must be for an x402 endpoint, but this is minor beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'deep history for one x402 endpoint' and lists specific metrics (uptime, latency, status-code distribution, etc.), differentiating from siblings like preflight by explicitly stating it's a superset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: 'superset of preflight — if you're running forensics you don't need preflight too.' Also mentions cost, helping agents decide when to invoke.
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 provided, so description carries the burden. It discloses that the tool reads current state (active/expired, alerts, deliveries, signal), is free, and requires the secret from watch_subscribe. It does not mention error handling or side effects, but for a read-only status tool, the disclosure is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no fluff. First sentence lists all returned fields. Second notes free and secret-gated. Third ties secret to watch_subscribe. Front-loaded main purpose, every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, description explains return fields sufficiently (state, alert count, deliveries, signal snapshot). Lacks details on error responses or data format for signal snapshot, but overall adequate for a 2-param read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters with descriptions (UUID watchId, 64-char hex secret). Description adds value by specifying the secret is the one returned by watch_subscribe, linking to a related tool. This extra context goes beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it 'returns the current state of a watch' and enumerates specific fields (active/expired, alerts remaining, last 10 deliveries, signal snapshot). The verb 'returns' and resource 'watch status' are specific, and it distinguishes from sibling tools like watch_subscribe and watch_unsubscribe.
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?
Mentions that the tool is free and secret-gated, linking the secret to watch_subscribe, which implies usage after subscribing. However, it lacks explicit guidance on when not to use it or comparisons to siblings like watch_unsubscribe.
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?
With no annotations, the description fully discloses behavioral traits: deactivation, cessation of alerts, row+history retention, free, secret-gated, and no refund. This is comprehensive for the tool's action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three succinct sentences with no redundancy. It is front-loaded with the primary action and uses minimal but informative language.
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 tool with two parameters and no output schema, the description covers the main points. It lacks potential error cases but is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters well-described. The description does not add new meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it deactivates a watch and explains the effect: no further alerts, is_active=false, and retention of history. This distinguishes it from the sibling watch_subscribe.
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: it deactivates a watch, is free, secret-gated, and there is no refund. It implies when to use (stop alerts) but does not explicitly mention when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses key behaviors: filters out 7-day-dead and 1-hour-erroring candidates, ranks by uptime+latency, costs $0.005 USDC, and falls back to taskClass if url is unknown. It lacks details on edge cases like missing both parameters.
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-sentence paragraph efficiently conveys purpose, input, behavior, and usage hint. Every sentence is informative with no redundancy, and the core action 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?
Covers main use case, filtering criteria, cost, and parameter guidance. Missing return format details and error handling (e.g., no alternatives found), but is sufficient given no output schema and low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage, but the description adds context beyond field descriptions: explains how url and taskClass are used as match keys, the ranking logic, and implies default limit of 5. This enriches the agent's understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'returns up to 5 healthy sibling endpoints' when given a flagged URL or taskClass hint. It distinguishes itself from sibling tools like preflight by specifying it is used after preflight returns ok=false, providing a clear purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs when to use: 'Use this immediately after preflight returns ok=false'. It also explains the different parameter combinations (url, taskClass, or both) and when to choose each, providing strong guidance.
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?
With no annotations provided, the description fully discloses behavioral traits: cost ($0.001 USDC), internal cron interval (5 min), and that faster polling yields unchanged data. It also explains the logical conditions for inclusion in added/removed lists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact 5 sentences, each delivering critical info. The main purpose is front-loaded. Slightly verbose in the pricing example, but still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description enumerates all returned fields (added_endpoints, removed_endpoints, counts, polls_in_window, active totals) and explains behavior and constraints, making it fully informative for agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers both parameters with descriptions. The description adds value by stating defaults (since=now-24h, limit=200) and clarifying the limit applies independently to each list, enhancing understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a 'polling-friendly catalog diff' that returns added and removed endpoints since a given timestamp, distinguishing it from sibling tools like the full catalog or subscription-based tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly recommends use for 'aggregator agents that need a fresh delta without re-pulling the whole catalog' and notes that polling more often than every 5 minutes returns identical data. However, it does not list specific alternative tools or conditions to avoid usage.
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 provided, so description fully discloses behavior: costs $0.001 USDC, auto-signed with AGENT_PRIVATE_KEY, returns ok only when no critical warning fires. Warns about specific threats (decoys ≥$1k, zombie services, dead endpoints).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first defines purpose and output, second provides usage guidance and cost. No wasted words; critical information presented first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, description explains return structure and conditions. Covers cost, signing, and specific dangers to avoid. For a simple tool with one parameter, this is highly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter 'url' has schema description ('The full URL of the x402 endpoint') and description adds context ('given x402 URL') and ties it to safety check purpose. Schema coverage is 100%, so baseline 3; description adds value by connecting parameter to tool's role.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks if an x402 URL is safe to pay, specifies the return value format ({ok, warnings[], metadata}), and distinguishes it from sibling tools by emphasizing it should be called before paid requests to avoid decoys, zombies, and dead endpoints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call 'BEFORE any other paid x402 request' to avoid specific risks (decoys, zombies, dead endpoints). Also mentions cost ($0.001 USDC) and auto-signing. Lacks explicit when-not-to-use guidance, but the positive directive is clear.
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:

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

Score Badge

Copy to your README.md:

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

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