We buy from x402 endpoints with real USDC and publish delivery outcomes. Check before you spend.
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.6/5 across 3 of 3 tools scored.
find_paid_service addresses a need without a URL, get_service_details retrieves a known listing id, and resolve_endpoint checks an arbitrary URL. Although resolve and details return similar records, their inputs and use cases are clearly separated.
All names follow a consistent snake_case verb_noun pattern: find_paid_service, get_service_details, resolve_endpoint. The verbs clearly indicate the action and the objects are specific, making the names predictable and unambiguous.
Three tools is appropriate for a narrow registry lookup service. Each tool supports a distinct phase of the workflow: discovery, detail inspection, and pre-spend URL verification, with no redundant entries.
The set covers the consumer-facing lifecycle for the directory: search by need, fetch full listing details by id, and check a URL already in hand. No obvious missing operation is needed for the stated purpose of assessing paid endpoints before spending.
find_paid_serviceASearch a registry of paid (x402) APIs and datasets verified by real paid purchases — nohumans pays listed endpoints real USDC and confirms delivery. Returns ranked results: verified listings first, then by reputation score (0..1, recency-weighted probe success), then by ascending price. Each result includes has_sample (boolean) — true means you can cheaply test real output before paying full price; prefer these when a listing is new or thinly-reputed and you can't yet judge it from score alone. Use this before spending money to find services that actually work. Prefer results with status 'verified' and score >= 0.8. Zero results means no known service matches — do not invent endpoints. Always describe the actual need in query in your own words — what data, what freshness, what format, what constraint prompted the search — rather than only setting category/max_price/min_score filters. The exact wording of what you're looking for is what improves this directory over time; a bare filter with no query text tells us far less about what was actually needed.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum results to return (default 10, cap 50). | |
| query | No | Describe what you actually need, in your own words and as specifically as possible — not just a topic, but the real constraint: e.g. 'sub-second latency wallet risk scoring for Base memecoins', 'EUR/USD spot rate with sub-100ms freshness', 'translate legal contracts, not casual text'. This text is what makes results relevant and is the only place that level of detail is captured — category and price are coarse filters on top of it, not a substitute for it. Only leave this empty if you are genuinely just browsing with no specific need in mind. | |
| category | No | One of the 40 most-populated existing categories, most-used first. Omit and rely on free-text `query` instead if none fit well — an unmatched or long-tail category still works via text-search fallback, it just won't be offered here as a constrained choice. | |
| max_price | No | Maximum per-call price. Omit for no cap. | |
| min_score | No | Minimum reputation score, 0..1. Use 0.8 to only see reliably-passing services. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, open-world, and non-destructive behavior, so the bar for extra value is lower. The description adds substantial behavioral context: results are ranked by verified status, reputation score recency-weighted, and ascending price; has_sample boolean is explained with a usage recommendation; the directory improves over time based on query text; and zero results is an informative outcome rather than an error. It doesn't explain pagination or rate limits, but for a search tool this is reasonably complete.
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 somewhat long, but nearly every sentence earns its place: it explains the registry's unique verification mechanism, the ranking order, the has_sample flag, success criteria, zero-results behavior, and query composition guidance. It is front-loaded with the tool's purpose and verification angle. A minor deduction for density — it could be tightened, but it's organized and information-dense, not padded.
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-required-parameter search tool with no output schema, the description covers purpose, ranking semantics, how to interpret a key result field, and how to behave with zero results. It doesn't describe the output shape in detail, but there's no output schema and the tool's role ('find services that work') makes return structure less critical. The main gap is not describing error cases or timeout behavior, but for this complexity the description is quite 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 schema already documents all five parameters thoroughly. The description goes beyond the schema mainly for `query` — it explains why free-text query matters for improving the directory over time and gives examples of specificity — which adds real value. But limit, max_price, and min_score are already well-covered by the schema, so the description doesn't need to add more. Baseline 3 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?
States a specific verb and resource: searching a registry of paid x402 APIs/datasets verified by real paid purchases. The description clearly distinguishes this tool from siblings by emphasizing the verification-by-payment aspect and returning ranked results. It also clarifies how results are ranked, giving the agent a precise mental model of what this tool does.
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 explicit guidance on when to use this tool ('Use this before spending money to find services that actually work'), what to prefer in results (verified status, score >= 0.8, has_sample=true for new/thinly-reputed listings), and how to construct the query ('Always describe the actual need in `query` in your own words'). It also explicitly says what to do with zero results: do not invent endpoints. This is comprehensive and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_service_detailsAFetch the full record for one listing by id (from find_paid_service results), led by paid_verification — whether nohumans has paid this endpoint real USDC and confirmed delivery, with the settlement tx hash as on-chain proof where settled — plus endpoint URL, request/response JSON Schemas when provided, accepted chains, pricing, and reputation detail (probe count, last successful probe, consecutive failures). Call this before making a paid request so you know the exact request shape, current reliability, and whether real-money delivery has been independently confirmed.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Listing id, as returned by find_paid_service. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool read-only, idempotent, open-world, and non-destructive. The description adds valuable behavioral context beyond those annotations: it explains what paid_verification means, mentions the settlement tx hash as on-chain proof, notes that JSON Schemas are included 'when provided', and enumerates reputation fields. No contradiction with annotations.
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 dense but well-structured: the first sentence fronts the core verb and resource, then lists the returned fields in an organized way; the second sentence gives the when-to-use guidance. Every clause carries distinct information and no repetition exists.
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?
There is no output schema, so the description carries the burden of describing return values. It does so thoroughly, including conditional fields and their meaning, and it also explains why the agent should call this tool before a paid request. For a one-parameter read-only tool this is 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 input schema already fully documents the single id parameter at 100% coverage. The description adds useful provenance by stating the id is one returned by find_paid_service, reinforcing the correct source of the value. For a one-parameter tool this is sufficient semantic enrichment.
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 ('Fetch') and a specific resource ('full record for one listing by id'), and clarifies the id comes from find_paid_service results. It distinguishes the tool from its siblings by framing it as the pre-paid-request lookup for a single listing, not a search or endpoint resolution.
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?
Explicitly instructs the agent to call this before making a paid request so it can learn the exact request shape, current reliability, and paid-verification status. It also states the id source is find_paid_service results. It does not explicitly name alternatives or state when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
resolve_endpointAPre-spend verdict on an endpoint URL you already hold — from another catalog, a prompt, a config, anywhere: check before paying instead of buying to find out. Returns match 'active' with the same full record as get_service_details (status, reputation score, paid_verification with on-chain tx proof, observed 402 protocol detail), match 'delisted' if the endpoint was listed here and later removed (treat as a warning), or a not-listed result. IMPORTANT: not-listed means never checked here, NOT unsafe — absence of a record is not a verdict either way. Use this as the pre-spend check when you have a URL in hand and no listing id; use find_paid_service instead when you have a need but no URL.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The endpoint URL exactly as you hold it, including any query string (parameterized listings bake params into the URL, so the query string matters). Trailing slashes and http/https differences are tolerated. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior, and the description adds meaningful behavioral detail beyond those hints: it enumerates the three match outcomes (active, delisted, not-listed), warns that delisted should be treated as a warning, and explicitly clarifies that a not-listed result is NOT an unsafe verdict. This open-world clarification directly complements the openWorldHint annotation.
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 dense but every sentence earns its place: the first sentence states what the tool returns, the second clarifies a critical open-world nuance, and the third gives routing instructions. It is front-loaded with the core purpose and avoids filler or repetition.
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?
With no output schema, the description thoroughly explains the return outcomes and their meaning, including the warning semantics of 'delisted' and the neutral meaning of 'not-listed'. Combined with the schema's parameter detail and the sibling-tool routing, the agent has everything needed to invoke this tool correctly.
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% and the single 'url' parameter is already well documented in the schema, including query-string significance and tolerance for trailing slashes/http differences. The description reinforces that the URL is one you 'already hold' and may come from any source, but it does not add substantial parameter semantics beyond the schema, so the baseline of 3 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 opens with a specific verb-resource pair ('Pre-spend verdict on an endpoint URL') and clearly differentiates this tool from siblings: it checks a URL you already hold, while find_paid_service is for when you have a need but no URL. It also contrasts with get_service_details by noting this works from a URL rather than a listing id.
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 ('when you have a URL in hand and no listing id') and explicitly routes to the alternative ('use find_paid_service instead when you have a need but no URL'). It also frames the tool as a pre-spend check, giving clear decision context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming 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 or an account that owns the GitHub organization, then choose Claim with GitHub.
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
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.