Wash-filtered intelligence for x402: categories, services, wash analysis, trends.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.4/5 across 5 of 5 tools scored.
Each tool has a clearly distinct purpose: wash analysis, category listing, service details, trends, and search. No overlap or ambiguity.
All tools follow a consistent pattern: x402_<verb>_<noun>. The prefix 'x402_' is used uniformly, and verbs like check, get, search are clear and predictable.
Five tools is an appropriate number for an analytics server. Each tool covers a needed functionality without being excessive or insufficient.
The set covers core operations for exploring the x402 ecosystem: aggregate wash report, categories, service details, trends, and search. No apparent gaps for its read-only purpose.
x402_check_washAInspectGet the aggregate wash-report dataset: 30-day total active buyers, real-volume %, suspected_wash and self_test counts, full 8-label distribution, 14-day wash percentage time series, and five anonymized case studies (Service A through E) with pattern signals.
For per-address real-time wash analysis with full signal breakdown, use the paid POST /api/v1/wash/check HTTP endpoint ($0.05 USDC) — that endpoint speaks x402, agents pay and receive data in a single HTTP round-trip. Free tier. No payment required. Returns wash-filtered data using the same v2.0 algorithm as the paid endpoints.
| Name | Required | Description | Default |
|---|---|---|---|
| address | No | Optional wallet or seller address. When provided, the response includes a hint about the paid per-address endpoint. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry the burden of behavioral disclosure. It discloses that the tool is free, uses the same v2.0 algorithm as paid endpoints, and that providing an address triggers a hint about the paid endpoint. It lacks explicit read-only confirmation or rate-limit details, but the context of 'Get' and 'Returns' implies a safe read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose and structured into three sentences. The first sentence is comprehensive but a bit list-heavy, and the phrase 'Free tier. No payment required.' is slightly redundant. Overall, it remains efficient and free of fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides a thorough enumeration of the returned data components, contextualizes the free vs. paid tiers, and mentions the address hint. Given the presence of an output schema, the description doesn't need to detail return values; it covers usage context, constraints, and feature differentiation adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes the 'address' parameter as optional, noting it includes a hint about the paid endpoint. The description reinforces this by mentioning per-address alternatives. Since schema coverage is 100%, the description adds marginal value beyond the schema, which aligns with the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves an aggregate wash-report dataset, enumerating specific components such as 30-day active buyers, wash percentages, and case studies. The verb 'Get' plus the resource 'aggregate wash-report dataset' precisely defines the tool's function and differentiates it from sibling tools focused on categories, services, trends, and search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the free tier is for aggregate data and directs users to the paid per-address endpoint when real-time per-address analysis is needed. This provides clear guidance on when to use this tool versus the alternative, including cost and protocol details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
x402_get_categoriesAInspectList all 33 x402 service categories with aggregate stats: services count, 24h volume, transaction count, real-volume %, and label distribution. Use this to understand the shape of the x402 ecosystem before drilling into specific services or wallets. Free tier. No payment required. Returns wash-filtered data using the same v2.0 algorithm as the paid endpoints.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses that it is free ('Free tier. No payment required') and that it returns 'wash-filtered data using the same v2.0 algorithm as the paid endpoints,' which is valuable context about data processing. It could mention rate limits or auth, but for a read-only list tool, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose, then usage guidance, then free/filter context. Every sentence adds value with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no parameters) and has an output schema, so the description need not explain return values. It covers purpose, usage, and behavioral nuances like free access and wash-filtering, making it complete for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% trivially. Per the rubric, a 0-parameter tool gets a baseline of 4, and there is nothing to add about parameters. The description appropriately omits parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all 33 x402 service categories with aggregate stats' with specific metrics, making the tool's purpose unambiguous. It distinguishes from siblings by focusing on categories with ecosystem-level overview rather than individual services, trends, or search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'Use this to understand the shape of the x402 ecosystem before drilling into specific services or wallets,' indicating when to use it as a starting point. It does not explicitly name alternatives, but the context implies that other tools are for deeper dives, so the guidance is clear though not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
x402_get_serviceAInspectGet the full detail record for one x402 service: name, description, seller address, chain, price, 24h and total transaction stats, 30-day daily volume time series, buyer-label distribution, and top buyers. Use this to evaluate a single service's traffic composition. Free tier. No payment required. Returns wash-filtered data using the same v2.0 algorithm as the paid endpoints.
| Name | Required | Description | Default |
|---|---|---|---|
| service_id | Yes | Numeric x402 service id (visible in /services list and detail URLs). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It usefully reveals that the tool is free, requires no payment, and returns wash-filtered data using the same algorithm as paid endpoints. It does not discuss error handling or rate limits, but these are less critical for a simple read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured: a main verb and resource, a colon-enumerated list of returned fields, and a clear usage statement. Each sentence provides distinct value—what it does, when to use it, and key constraints (free, no payment, wash-filtered).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-record retrieval tool, the description is complete: it defines the scope, lists the payload, explains the usage context, and discloses cost/algorithm behavior. Since an output schema exists, detailed return-format documentation is unnecessary, and the one required parameter is fully covered by the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the single parameter 'service_id' with 100% coverage, including a description of what it is. The tool description does not add additional semantic detail about the parameter beyond what the schema already provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and clearly identifies the resource ('full detail record for one x402 service'), enumerating the exact fields returned. It distinguishes itself from sibling tools by emphasizing a single service and traffic composition, which is not the focus of search, trends, categories, or check_wash.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'Use this to evaluate a single service's traffic composition.' It provides clear context and intent, though it does not explicitly mention alternatives or exclude other tools, which would warrant a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
x402_get_trendsAInspectGet the last-24-hour trends snapshot: new services count vs the previous 24h, total transaction count, total USDC volume, active buyer count, daily new-services bar (14 days), recent new services (top 10), category volume movers, and hot services with traffic surges (>= 100 24h tx and >= +50% growth). Refreshed every 5 min. Free tier. No payment required. Returns wash-filtered data using the same v2.0 algorithm as the paid endpoints.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses key behaviors: refresh cadence ('Refreshed every 5 min'), cost ('Free tier. No payment required.'), and data processing ('Returns wash-filtered data using the same v2.0 algorithm as the paid endpoints'). This goes well beyond basic operation and explains important characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the primary purpose and then efficiently enumerates the exact contents. Every phrase adds value, with no fluff or redundancy. It is concise despite the number of metrics listed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite zero parameters and an output schema that covers return structure, the description fully contextualizes the tool by specifying time window, refresh rate, pricing, and filtering methodology. It is complete for a zero-input snapshot tool, leaving no operational gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 to explain. The baseline for 0 params is 4, and the description adds no parameter semantics because none exist. It correctly implies no input is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get the last-24-hour trends snapshot' with a specific list of metrics (new services count, transaction count, USDC volume, etc.). It distinctly differentiates from siblings by focusing on aggregated trends rather than individual service lookup or search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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—when a snapshot of trends over the last 24 hours is needed, refreshed every 5 minutes. It does not explicitly name alternatives or exclusions, but the scope is unmistakable and no alternative tool is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
x402_search_servicesAInspectSearch the index of 36k+ x402 services with filters. Returns a paginated list of matching services with their stats and label mix. Use this to find services by topic, chain, or seller wallet. Free tier. No payment required. Returns wash-filtered data using the same v2.0 algorithm as the paid endpoints.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | 1-indexed page number. | |
| sort | No | Sort key: tx_24h | volume_24h | tx_total | price | real_pct | wash_pct | first_seen | alpha. | tx_24h |
| chain | No | Filter to one chain: 'base', 'solana', 'arbitrum', 'base-sepolia'. | |
| search | No | Free-text match against name, description, or seller address. | |
| category | No | Filter to a single category slug (e.g. 'ai_inference', 'wallet_analytics'). | |
| page_size | No | Page size (max 200; default 24). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits itself. It discloses that the tool is free, returns paginated results, and applies wash-filtering using the same algorithm as paid endpoints. It also describes the output composition (stats and label mix). It does not mention read-only status or rate limits, but for a search tool this is sufficient. It adds meaningful context beyond what the schema provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action and contains several useful details (free tier, pagination, wash-filtering, use case). There is a minor redundancy: 'Free tier. No payment required.' conveys the same information in two phrases, which is a small efficiency lapse. Overall it is concise and well-structured for its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, output type, filtering capabilities, and key behavioral attributes (free, wash-filtered, paginated). Since an output schema exists, return values do not need to be detailed. It omits explicit mention of read-only behavior or default behavior with no filters, but these are reasonably implied. For a 6-parameter search tool with no annotations, the description is highly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 high-level use context (e.g., 'topic, chain, or seller wallet') but does not add specific parameter syntax or format details beyond the schema. It slightly reinforces the purpose of the 'search' and 'chain' parameters but does not go beyond the schema's own descriptions, so the baseline is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Search') and a clear resource ('the index of 36k+ x402 services') with filters, and it states the return type (paginated list with stats and label mix). It distinguishes itself from sibling tools like x402_get_service (single service), x402_get_categories, and x402_get_trends by focusing on search/filter over the whole index.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use context: 'Use this to find services by topic, chain, or seller wallet.' It does not explicitly name alternatives or when-not-to-use, but the sibling tool names and the stated purpose make the differentiation clear. This is solid guidance without exclusions, qualifying as 'clear context, no exclusions.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.