Specialist tools for any job — a lead, an image, a song, live data, and more.
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 4 of 4 tools scored. Lowest: 3.8/5.
Each tool serves a clearly distinct function: checking account balance, discovering endpoints, executing calls, and providing feedback. There is no overlap or ambiguity between them; an agent can unambiguously pick the appropriate tool for a task.
All tools use single lowercase verbs (balance, call, discover, feedback), following a uniform imperative style. The naming pattern is consistent and predictable, though 'balance' is a noun used as a verb, the convention is uniform across the set.
Four tools are exactly right for the server's purpose as a paid endpoint marketplace: discovery, execution, balance monitoring, and feedback. Each tool is essential and succinctly covers the core workflow without redundancy or bloat.
The tool set covers the full lifecycle: discover available endpoints, call them (with dry-run capability), check balance, and leave feedback. The 'discover' tool also supports listing services and detailed docs, so no obvious gaps exist for the stated domain of paid API access.
balanceCheck the taskfuel balanceAInspectThe connected account's remaining prepaid balance in USD, and what it has spent so far.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It does disclose the output content (remaining balance and spend), but it does not explicitly state whether the operation is read-only, require authentication, or describe the return structure beyond the two data points.
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 with no filler. It is front-loaded and every word adds meaning.
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 balance tool, the description is largely complete: it names the account scope, currency, and the two output values. It lacks explicit return formatting or precision details, but these are not essential 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, which earns the baseline of 4. The description adds no parameter details, but none are needed.
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 title 'Check the taskfuel balance' provides a clear verb+resource, and the description specifies exactly what is returned: 'remaining prepaid balance in USD' and 'what it has spent so far.' This distinguishes it from sibling tools like call and discover.
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 is given on when to use this tool versus alternatives. The description implies it is for checking balance but does not mention exclusions, prerequisites, or related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
callCall a paid APIAInspectCall one of the discovered endpoints and pay for it from the user's balance. Set dry_run: true first to read the real price off the endpoint's HTTP-402 challenge without paying: that is the authoritative price for that exact payload, not an estimate (a free endpoint never issues a 402, so its dry run executes and returns the response at $0). Repeat the identical call without dry_run to execute it. Calls above $10 are refused; max_amount_usd can tighten that ceiling further.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | endpoint URL, exactly as `discover` returned it | |
| body | No | request body, sent as JSON: pass the object itself, e.g. {"prompt": "a cat"}, not a JSON-encoded string | |
| model | No | your own model id, e.g. claude-opus-5. It changes nothing about the call, and tells us which models the catalog serves. Skip it if you are not sure. | |
| method | No | HTTP method (default GET) | |
| dry_run | No | quote the real price without paying | |
| headers | No | extra request headers, no auth headers needed | |
| max_amount_usd | No | your own spend ceiling for this call, in USD |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers key behaviors: the HTTP-402 price challenge, the fact that free endpoints don't issue 402 and return a $0 response on dry run, and that calls above $10 are refused. This is critical safety information for an agent spending user balance.
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?
Four sentences, each dense with actionable information: the core purpose, the dry-run workflow, the free-endpoint edge case, and the pricing ceiling. No redundant phrasing.
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 7 parameters, no annotations, and no output schema, the description covers the essential behavioral mechanics and execution workflow. It doesn't describe the response shape for paid calls or failure modes like insufficient balance, but it does mention the dry-run response at $0, leaving only minor 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?
Schema description coverage is 100%, so the baseline is 3. The description adds meaningful context beyond the schema by explaining how dry_run interacts with the 402 challenge and how max_amount_usd tightens the $10 ceiling. The schema already handles per-parameter semantics well.
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 'Call one of the discovered endpoints and pay for it from the user's balance', which clearly defines the verb, resource, and transactional nature. This distinguishes it from sibling tools like discover and balance.
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 provides explicit workflow guidance: 'Set dry_run: true first to read the real price... Repeat the identical call without dry_run to execute it.' It also references 'discovered endpoints', implicitly positioning it after discover, and explains the default $10 ceiling with max_amount_usd as a tightening option.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
discoverDiscover paid APIsAInspectFind a paid endpoint. Keyword search is the fastest path from a task to an endpoint: pass query. No results is a real answer: nothing offers that term. Pass domain to list one service's endpoints, url + method together for one endpoint's full docs (parameters, request-body schema), or no arguments at all for the allowed service domains.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | an endpoint URL. With `method`, returns its full docs | |
| query | No | keywords to search every service's endpoints | |
| domain | No | restrict to one service domain, e.g. 2s.io | |
| method | No | HTTP method, required alongside `url` |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It mentions that 'no results is a real answer' (expected behavior for empty results) and implies different return patterns per argument set, but does not disclose side effects, rate limits, or authentication needs. While it gives useful behavioral hints, it is not fully transparent about all aspects.
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 (three sentences) and front-loaded with the main purpose ('Find a paid endpoint'). Every sentence adds distinct value: keyword search tip, empty result behavior, and parameter combination use cases. No redundant or irrelevant 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?
Given the tool's complexity (4 parameters, all optional, different usage modes) and the absence of an output schema, the description is largely self-sufficient. It explains all parameter semantics and expected return patterns. Minor gap: it does not specify that return values vary by parameters, but this is inferable from the descriptions.
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%, including descriptions for each parameter (`url`, `query`, `domain`, `method`). The description adds significant context beyond the schema: explaining semantic groupings (e.g., `url`+`method` together for full docs, `query` for fastest search, no args for domains). This enhances the agent's understanding of how parameters combine.
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: 'Find a paid endpoint.' It uses specific verbs and resources ('find', 'paid endpoint') and distinguishes from siblings by focusing on discovery and search, whereas siblings like 'call' and 'balance' imply execution and account queries.
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 explicit guidance on when to use each parameter combination: keyword search with `query` is fastest, no results is a valid answer, `domain` lists one service's endpoints, `url`+`method` returns full docs, and no arguments returns allowed service domains. It does not discuss alternatives but covers all usage scenarios clearly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
feedbackRate a paid API endpointAInspectRate a documented endpoint you called, using the method and url exactly as discover returns them: vote up if you got the expected/useful result, down if it didn't work or wasn't worth the price. Rate it against its own docs, from a call you made. Not down-votes: a missing catalog entry, your own bad arguments, or an endpoint that worked but wasn't what your task needed. Vote and report must agree. Add report to describe what concretely disrupted usage: an unexpected response code, ignored arguments, an empty or low-quality response (it doesn't change the rating). One vote per endpoint, changeable at any time: voting again replaces your previous vote.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | the endpoint URL, as `discover` returned it | |
| vote | Yes | up = you got the expected/useful result; down = it didn't work or wasn't worth the price | |
| method | Yes | HTTP method of the endpoint, as `discover` returned it | |
| report | No | what concretely disrupted usage (unexpected response code, ignored arguments, low-quality response); do not include secrets or response data. Up to 2000 characters |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does so well: it explains vote semantics, that a report must accompany and match the vote, that report details don't alter ratings, and that voting is one-per-endpoint and replaceable. It also warns against including secrets/response data in the report.
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 and front-loaded with the core purpose, and nearly every sentence earns its place. It is slightly redundant ('Rate it against its own docs, from a call you made' repeats the opening), but overall it is appropriately sized for the behavioral detail needed.
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 four parameters, no annotations, and no output schema, this description thoroughly covers the tool's contract: what to vote on, what not to downvote, how method/url must be specified, what report should contain, and how votes are stored/replaced. There are no major unexplained 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?
Although the schema already documents all four parameters (100% coverage), the description adds crucial semantics: method/url must be exactly as `discover` returns them, vote enum meanings are expanded, report is described with concrete examples ('unexpected response code, ignored arguments, empty or low-quality response'), and the report must agree with the vote. This is far beyond schema baseline.
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 action, 'Rate a documented endpoint you called,' and clearly identifies the target resource (a paid API endpoint). It distinguishes itself from sibling tools by tying method/url format to `discover` and requiring that votes come from an actual call.
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 provides explicit inclusion criteria (rate against its own docs, from a call you made) and explicit exclusions (missing catalog entry, bad arguments, task-mismatch). However, it never names sibling tools as alternatives; only `discover` is referenced, so the when-to-use-vs-alternatives guidance is strong but not fully explicit.
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!
