Accountless public-source, SEC Form D and OFAC tools with x402 USDC payment on Base.
Create a live x402 challenge using this service's known-valid published example for one product. This never moves funds. The returned arguments can be passed unchanged to submit_x402_payment.
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes |
| 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, and it uses that space well by disclosing the most important behavior: no funds are moved. It also indicates that a live challenge is created, which implies a non-trivial side effect without risk of settlement. It does not mention authentication or rate limits, but for this focused example tool the key safety trait 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?
Three short sentences, each earning its place: the first states the action, the second provides the critical safety qualifier, and the third links the output to the follow-up tool. It is front-loaded with the core purpose and contains no 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 description covers purpose, safety, and output usage, and an output schema is available so return structures do not need explanation. However, the required 'product' parameter is left underspecified, which is a real gap for an agent that must decide what value to pass. This keeps it from being fully 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?
The single required parameter 'product' has no schema description and the description only says 'for one product.' It does not explain what identifies a product, whether it is an ID, slug, or one of the service's known products, or where valid values can be found. The description thus adds almost no semantic value over the raw 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 names a specific resource and action: creating a live x402 challenge backed by a known-valid published example for one product. It immediately clarifies the safety scope ('This never moves funds') and explicitly frames the output for use with submit_x402_payment, which differentiates it from the payment-submission sibling.
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 gives a clear usage context: the returned arguments should be passed unchanged to submit_x402_payment, and the tool never moves funds. It stops short of explicitly naming alternatives or stating when not to use it, but the connection to the submission tool is strong and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a live x402 challenge for SEC Form D funding signals. This does not move funds.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| since | Yes | ||
| states | No | ||
| industry_keywords | No | ||
| include_amendments | No | ||
| minimum_amount_sold_usd | No | 0 |
| 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 behavioral transparency burden. It does usefully disclose that the tool does not move funds, which is a key safety-related behavior. However, it does not explain whether it creates persistent state, requires authentication, expires, or what side effects a 'live challenge' may have.
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 concise: two sentences with no filler. The main action is front-loaded, and the non-mutating caveat is placed right after. It earns its place, though it is terse enough that significant details are missing.
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 six-parameter tool with no annotations and a payment-related domain, this description is incomplete. It does not explain what a live x402 challenge is, how the parameters shape it, or how this relates to the sibling payment tools. An output schema exists, but it cannot compensate for missing usage and parameter semantics.
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 0%, so the description was expected to compensate. It does not mention any of the six parameters, including the required 'since' field, nor does it clarify how limit, states, industry_keywords, include_amendments, or minimum_amount_sold_usd affect the results. Agents have no semantic guidance for constructing arguments.
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 names a specific action ('Create a live x402 challenge') and a clear domain ('SEC Form D funding signals'). It is not a tautology and gives the agent a concrete idea of what the tool does. However, 'x402 challenge' is jargon that is not explained, and the description does not differentiate this tool from its payment-related siblings.
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?
There is no explicit guidance on when to use this tool versus the sibling tools. The phrase 'This does not move funds' is a useful hint that this is not the final payment submission tool, but it never says to use submit_x402_payment for actual payment, or get_payment_preflight_payment for preflight checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a live x402 challenge for an exact-address OFAC payment preflight. This does not move funds and is not sanctions clearance.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | ||
| network | No | eip155:8453 |
| 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 burden of behavioral disclosure. It states that a live challenge is created, explicitly says no funds move, and clarifies this is not sanctions clearance. This gives meaningful transparency, though it does not detail other side effects such as whether state persists.
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 concise sentences deliver the core purpose first, then immediately clarify non-behavior. Every sentence earns its place with no redundant 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?
For a simple two-parameter tool with an output schema, the description provides enough context to invoke it: create a live preflight challenge for an address, without moving funds. It could be stronger by mentioning the network semantics, but the default in the schema covers most of that 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?
The schema has 0% description coverage, so the description must compensate. It adds meaning to address via 'exact-address', but it does not explain the network parameter or its default value. Partial compensation for a low-coverage schema warrants a mid-range score.
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 states a specific action and resource: 'Create a live x402 challenge' for an 'exact-address OFAC payment preflight'. It also distances itself from payment execution and sanctions clearance, which differentiates it from siblings like submit_x402_payment.
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 clearly frames when this tool applies: for an exact-address OFAC payment preflight. It also gives useful exclusions ('does not move funds', 'not sanctions clearance'), implying that fund movement should go to submit_x402_payment, though it does not explicitly name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a free, side-effect-free quote and exact input example for one paid product. Does not create a payment challenge.
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes |
| 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 of behavioral disclosure. It clearly states that the operation is free, side-effect-free, and does not create a payment challenge—key behavioral traits that an agent needs to safely invoke the 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?
The description is two sentences with no filler. The core behavior and safety profile are stated immediately, and the exclusion is placed at the end without redundancy.
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 simple single-parameter tool with an output schema, the description covers the essential behavioral context: what the tool returns, that it is free and side-effect-free, and that it does not initiate a payment. No critical information for invoking it correctly is missing.
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 only documents that 'product' is a required string with no enum or description. The description adds that it is for 'one paid product' and that an exact input example is returned, but it does not clarify what values the 'product' string should take or how the example is formatted.
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 ('Return') and identifies the resource: a free, side-effect-free quote and exact input example for one paid product. It also explicitly distinguishes the tool from payment-related siblings by stating 'Does not create a payment challenge.'
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 gives clear context for when to use the tool: when the agent needs a free quote and example input for a paid product. It also provides an exclusion by clarifying that this tool does not create a payment challenge, which helps differentiate from payment-oriented siblings, though it does not name alternatives directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check live readiness, x402 network and prices before spending. This free call has no side effects.
| 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 provided, the description carries the full burden of behavioral disclosure. It explicitly states the call is free and has no side effects, which is critical safety information for an agent deciding whether to invoke it.
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 one concise sentence that front-loads the tool's purpose and ends with the key safety caveat. Every word earns its place with no redundancy.
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 zero-parameter read-only status tool, the description covers purpose, timing, and side-effect profile. Since an output schema exists, omitting return-value details is acceptable, and the description gives an agent enough to invoke the tool appropriately.
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, so there are no parameter semantics to document. The description appropriately avoids inventing parameter details, and the baseline for a parameterless tool is strong.
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 states a specific verb ('Check') and a clear resource: live readiness, x402 network, and prices. It signals the tool is a pre-payment status check, which helps distinguish it from payment-executing siblings.
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 phrase 'before spending' gives clear contextual guidance on when to use the tool. It does not explicitly name alternatives or exclusion cases, but the timing is unambiguous for an agent deciding whether to call it first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a live x402 challenge for one public HTTPS source snapshot. This does not move funds.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| query | No | ||
| max_characters | No |
| 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 carries the full behavioral disclosure burden. It does disclose the most important side-effect boundary: the operation does not move funds, and it describes the output as a 'live' x402 challenge. However, it does not explain other behavioral aspects such as whether the source URL is contacted, challenge lifetime, rate limits, or any server-side state changes beyond challenge creation.
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 two short, front-loaded sentences with no filler. The purpose statement comes first, and the critical no-funds-movement clarification follows immediately. Every sentence earns its place.
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?
Even though an output schema exists and only one parameter is required, the combination of 0% schema coverage and minimal description leaves important gaps. The agent cannot reliably know what query and max_characters control, nor when to choose this tool over the closely related payment siblings. The description provides too little context for confident invocation.
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 0%, and the description provides no parameter-level information. The agent is left to infer the meaning of url, query, and max_characters from names and defaults alone. Because coverage is low, the description was obligated to compensate but did not.
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 and resource: 'Create a live x402 challenge for one public HTTPS source snapshot.' It also clarifies a critical distinguishing trait: 'This does not move funds.' However, it does not explicitly name or differentiate among sibling payment tools like submit_x402_payment or get_payment_preflight_payment, relying on the no-funds-movement statement to imply the boundary.
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?
There is no explicit guidance on when to use this tool versus alternatives. The description only implies that it creates a challenge and does not move funds, leaving an agent to infer that this is not the submission or preflight tool. No sibling tool is mentioned, and no conditions or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tell the operator about a machine-service capability you would pay for. The structured request is stored privately for product research; contact_uri is optional and is never called automatically.
| Name | Required | Description | Default |
|---|---|---|---|
| contact_uri | No | ||
| job_to_be_done | Yes | ||
| max_budget_usd | No | ||
| decision_criteria | No | ||
| current_alternative | No | ||
| max_latency_seconds | No | ||
| required_output_fields | No |
| 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 behavioral disclosure burden and does so reasonably well. It reveals that requests are stored privately, that the purpose is product research, and that contact_uri is never automatically invoked. This goes beyond a generic 'request' statement and gives the agent useful non-obvious 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 two sentences with no filler. It front-loads the primary purpose and adds the most important privacy/contact caveat right after. Every sentence carries meaningful information.
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 tool with seven parameters and no annotated descriptions, the description is too sparse to fully support correct invocation. The output schema exists, which lessens the need to explain return values, but the description leaves parameter semantics and selection guidance largely uncovered. It captures the high-level intent but not enough operational detail.
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 0%, so the description should compensate by explaining parameter meanings. It only explains contact_uri's optionality and non-auto-call behavior, and implicitly points at job_to_be_done. It provides no guidance for max_budget_usd, decision_criteria, current_alternative, max_latency_seconds, or required_output_fields, which are not self-explanatory.
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 states a clear purpose: submit a structured request for a machine-service capability the agent would pay for. It names the core action and resource ('Tell the operator about a machine-service capability') and the context of product research. It does not explicitly differentiate from siblings, but sibling names are about payments/quotes, so the distinction is apparent.
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 gives useful context for when to use the tool: it is for capability requests the agent would pay for, stored for product research. It also clarifies that contact_uri is optional and never called automatically, which is a meaningful usage caveat. However, it does not state explicit when-not-to-use conditions or alternatives, leaving some inference required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a wallet-generated x402 PAYMENT-SIGNATURE for a previously quoted product. Use exactly the same arguments. Never provide a private key or seed phrase. request_id enables safe result replay.
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes | ||
| arguments | Yes | ||
| request_id | No | ||
| payment_signature | Yes |
| 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 burden and adds safety guidance (never provide private key or seed phrase) and idempotency semantics (request_id enables safe replay). It stops short of explicitly stating that submitting a signed payment may execute an irreversible financial transaction, but 'PAYMENT-SIGNATURE' and 'Submit' convey the core 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?
Three short sentences, each earning its place: purpose, argument-matching rule, safety warning, and replay semantics are all front-loaded. No 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 description covers the required flow (prior quote, same arguments, wallet-generated signature, optional request_id), and the output schema removes the need to document return values. The only material gap is an explicit warning that this action can finalize a real payment.
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 0%, so the description must compensate. It does: product and arguments map to the previous quote, payment_signature must be wallet-generated rather than credentials, and request_id controls replay. It doesn't enumerate argument shapes, but 'use exactly the same arguments' is a strong semantic guide.
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 states a specific operation (submit) and resource (wallet-generated x402 payment signature), tied to a prior quote. This clearly separates it from the sibling get_* tools, which are retrieval actions.
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 gives clear when-to-use context: only for a previously quoted product, with arguments identical to that quote. It does not explicitly name alternatives or exclusions, but the sibling set is retrieval-oriented and the 'previously quoted' condition is a sufficient routing signal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
get_example_paymentget_form_d_funding_leads_paymentget_payment_preflight_paymentget_quoteget_service_statusget_source_snapshot_paymentrequest_capabilitysubmit_x402_paymentClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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!
8.1M+ US gov and science data via x402 USDC. 21 tools, $0.001 sample tier, sanctions, SEC, CVEs.
Paid x402 tools over MCP: search, FX, LEI, company research, risk. Pay-per-call USDC on Base.
SEC EDGAR MCP: search, preview, purchase filings. x402 USDC on Polygon. xpay + Cloud Run upstream.
Pay-per-call (x402/USDC-Base) web + crypto data tools for AI agents: audit, extract, crypto, DeFi.
Add one secure layer between your agents and this server.
The four get_*_ayment tools all create live x402 challenges and differ only by product, while get_quote and get_example_payment both provide example input data — creating real selection ambiguity. Descriptions do clarify the product and side-effect differences, but an agent must read carefully to avoid picking the wrong one.
All tools use lowercase snake_case with a verb prefix, and the get_X_payment pattern for challenge creation is consistent. However, 'get' is overloaded to cover both free reads that create no side effects and challenge creation calls, and get_payment_preflight_payment has a redundant 'ayment' that muddies the naming pattern.
Eight tools map cleanly to the paid-evidence workflow: status check, quote, four product-specific challenge creators, payment submission, and a capability-request escape hatch. Each tool earns its place, and the count is well-scoped for a niche paid API.
The core quote→challenge→submit→result flow is covered, and request_capability is a good gap-filler for missing products. Minor gaps remain: there is no explicit result-retrieval tool beyond request_id replay, and product discovery is implicit through get_quote and get_service_status rather than a dedicated list endpoint.
