Money-Engine x402 Research
Server Details
Free agent discovery + paid x402 research (outline 0.01 / brief 0.02 USDC Base).
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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.
Tool Definition Quality
Average 3.5/5 across 6 of 6 tools scored.
Each tool has a clearly distinct purpose: discovery, health, paid research brief, paid outline, free sample outline, and free sample scrub. Descriptions explicitly differentiate free vs paid tiers and conversion paths, eliminating ambiguity.
All tools follow a consistent 'x402_' prefix with snake_case names (e.g., x402_discovery, x402_research_brief). No mixing of conventions or irregular patterns.
6 tools is well-scoped for a research API that offers discovery, health monitoring, free samples, and two paid tiers. Each tool serves a clear role without redundancy.
The tool set covers discovery, health, free sample, paid outline, paid brief, and an alternative scrub demo. It implements a clear conversion ladder from free to paid, with no obvious gaps for the stated domain.
Available Tools
6 toolsx402_discoveryBInspect
Free x402 discovery document (resources, prices, payTo, facilitator, convertLadder).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the tool is 'free' but does not disclose behavior such as authentication needs, rate limits, or side effects. A read operation is implied but not explicitly stated.
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 is front-loaded and contains no unnecessary words. It efficiently conveys the tool's purpose and content.
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?
Given the simple nature (no parameters, no output schema), the description is adequate but lacks detail on the return format or structure. Listing a few fields helps but does not fully compensate for the missing output 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?
With zero parameters, the baseline is 4. The description adds meaning by listing the contents of the discovery document (resources, prices, payTo, etc.), which goes beyond the empty schema.
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 a 'free x402 discovery document' and lists its contents (resources, prices, etc.). The verb is implied (get/retrieve), and it distinguishes from sibling tools by focusing on discovery vs. health, research briefs, etc.
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?
No guidance on when to use this tool versus alternatives like x402_health or x402_research_brief. The description only states what it returns, with no context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
x402_healthBInspect
Free liveness + pricing for the money-engine Research API (x402 USDC on Base). Ladder: free sample_outline → outline 0.01 → brief 0.02.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not detail return values, error behavior, or side effects. Only mentions 'liveness' without specifying how it is determined.
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?
Two sentences, no unnecessary words. Information is front-loaded and efficient.
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?
Adequate for a health check with no params, but lacks details on output format and error states. Could be more informative given no output 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?
No parameters, so no additional meaning needed beyond schema. Baseline 4 per instructions.
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?
Clearly states it provides free liveness and pricing for the x402 USDC API. Mentions the ladder of related tools, distinguishing it from siblings like x402_sample_outline and x402_research_brief.
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?
Implicitly suggests using this tool before others in the ladder to check liveness and pricing, but lacks explicit when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
x402_research_briefAInspect
Paid full research brief (0.02 USDC Base · upgrade). Free first: x402_sample_outline; optional outline 0.01 first. Body {topic}. Without paymentHeader returns 402 + accepts[].
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | Topic or https URL | |
| paymentHeader | No | Optional X-PAYMENT proof after settling USDC |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It discloses that the tool requires payment (0.02 USDC) and that without the paymentHeader it returns a 402 error with an accepts[] array. It does not describe the output format or any side effects, but the key behavioral trait (payment required) is covered.
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 very concise, with no wasted words. It front-loads the purpose and packs multiple pieces of information (cost, alternatives, error case) into a single sentence. However, the structure is somewhat run-on and could be clearer with sentence breaks.
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?
Given the absence of output schema and annotations, the description covers essential context: payment requirement, error handling, and alternative tools. It does not detail the response format, but this is acceptable as no output schema is expected. It provides enough context for an AI agent to decide when and how to use this 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?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining the consequence of omitting paymentHeader ('returns 402 + accepts[]'), which goes beyond the schema's 'Optional X-PAYMENT proof'. For topic, it adds 'Body {topic}', hinting at usage. However, it does not elaborate on the types of topics.
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 'Paid full research brief', indicating the tool produces a paid research brief for a given topic. It distinguishes from siblings by mentioning the free sample (x402_sample_outline) and optional outline, making its purpose clear. However, the phrasing is somewhat cryptic and lacks a verb.
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 some usage guidance by mentioning 'Free first: x402_sample_outline' and 'optional outline 0.01 first', implying a progression from free sample to paid outline to full brief. However, it does not explicitly state when to use this tool versus alternatives, nor does it describe prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
x402_research_outlineAInspect
Paid research outline (0.01 USDC Base · first pay). Free first: x402_sample_outline. Body {topic}. Without paymentHeader returns 402 + accepts[].
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | Topic or https URL | |
| paymentHeader | No | Optional X-PAYMENT proof after settling USDC |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description must disclose behavior. It mentions cost, payment requirement, error response (402 + accepts[]), and request body placement. Lacks details on idempotency, side effects of payment, or success response format. Adequate but not comprehensive for a paid tool.
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?
Three concise sentences, each conveying critical information: cost and purpose, free alternative, and request/error semantics. No unnecessary words; highly efficient.
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 two-parameter tool with no output schema, description covers payment flow, error handling, and free alternative. Lacks details on success output format or how to obtain paymentHeader, but overall adequate given context signals.
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 covers parameters with 100% description. Description adds value by clarifying that topic goes in the request body ('Body {topic}') and that missing paymentHeader triggers a 402 error with acceptance options. This goes beyond the schema's descriptions.
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?
Clearly identifies the tool as a paid research outline with cost (0.01 USDC). Distinguishes from free alternative x402_sample_outline, which is mentioned explicitly. Purpose is specific and unambiguous.
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?
Guides users to try the free version first ('Free first: x402_sample_outline'). Explains that omitting paymentHeader results in a 402 error with an accepts array, implying when payment is needed. Does not fully cover when to use over other siblings like x402_research_brief.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
x402_sample_outlineAInspect
FREE research teaser (3 bullets). Convert ladder: this tool → paid x402_research_outline 0.01 USDC → x402_research_brief 0.02 USDC Base. Body {topic?} default x402.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Topic or https URL (default: x402) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure. It states the output is '3 bullets' and that it's free, but omits details on side effects, authentication, rate limits, or whether it's read-only. For a simple teaser tool, this is minimally adequate but not thorough.
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 very short (2 lines) and front-loads the key value proposition ('FREE research teaser'). However, the cryptic phrase 'Body {topic?} default x402' harms clarity and should be rephrased.
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?
Given no output schema, the description should explain what the tool returns beyond '3 bullets'. It does not describe the structure or format of the bullets, leaving the agent uncertain about the output. For a simple tool, this is a significant gap.
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% (parameter 'topic' described as 'Topic or https URL (default: x402)'). The description adds 'Body {topic?} default x402', which does not provide additional meaning beyond the schema. 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?
Description states it's a 'FREE research teaser (3 bullets)' and distinguishes from paid tools via a conversion ladder, clearly indicating it provides a sample outline for a topic. However, phrasing like 'Body {topic?} default x402' is cryptic and slightly detracts from clarity.
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 conversion ladder explicitly maps the free tool to paid versions (x402_research_outline, x402_research_brief) with costs, guiding when to upgrade. It implies this is for initial exploration but does not explicitly state when not to use it or alternative use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
x402_sample_scrubBInspect
Free sample data-scrub / leak-guard teaser (dirty→clean demo). Alt path — primary convert is x402_sample_outline → outline 0.01.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
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 describes a 'demo' but does not disclose side effects, whether it's read-only, or what actually happens upon invocation. This is insufficient for an agent to understand the tool's behavior.
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 extremely concise—a single sentence and a phrase—with no wasted words. It front-loads the purpose and alternative path efficiently.
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?
Given the lack of output schema and parameters, the description should explain what the tool returns or accomplishes. It only says it's a 'dirty→clean demo' but fails to specify the output or side effects. The mention of a sibling provides mild context, but overall completeness is poor.
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% (vacuous). The description does not add parameter-specific meaning, but no parameters exist, so the baseline of 4 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 identifies the tool as a 'free sample data-scrub / leak-guard teaser (dirty→clean demo)' and distinguishes it from the sibling x402_sample_outline by noting the alternative path. However, the term 'teaser' is vague, leaving some ambiguity about the exact functionality.
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 mentions an 'alt path' and that the primary tool is x402_sample_outline, implying this is a secondary option. However, it does not explicitly state when to use this tool versus alternatives, nor does it provide clear context for decision-making.
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.
Discussions
No comments yet. Be the first to start the discussion!