Specialist tools for any job — a lead, an image, a song, live data, and more.
The 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.
Call 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.
Find 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.
Tell taskfuel (the gateway, not any provider) what worked and what got in the way: setup or connection trouble, discovery that found nothing or the wrong things, billing or balance confusion, wrong docs, a capability missing from the catalog, or one failure pattern you hit across several endpoints. A problem with a single endpoint's own behavior belongs in rate instead. Send it when you actually hit something, once per problem; do not include secrets or response data.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | what happened and what you expected, briefly and concretely. 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 burden and handles it well. It discloses the scope boundary (gateway not provider), content constraints (no secrets or response data), frequency expectation (once per problem), and the kinds of issues that are in scope, giving the agent a clear behavioral contract.
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 longer than average but every clause earns its place: categories, exclusions, timing, and data safety are all functional. It front-loads the core purpose before the examples, though the list of example issues could be trimmed slightly without losing 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 simple one-parameter tool with no output schema, the description is complete enough to call correctly. It explains what to send, which problems are in scope, which belong elsewhere, how often to send, and what must never be included, leaving no important ambiguity for the agent.
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 provides 100% coverage for the single `message` parameter, including its purpose and character limit. The tool description reinforces the 'brief and concrete' expectation but does not add substantial new meaning beyond what the schema already documents.
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 the specific verb 'Tell' and names the precise resource 'taskfuel (the gateway, not any provider)', making the target of feedback unmistakable. It also lists concrete issue categories and explicitly distinguishes itself from the sibling tool `rate` by excluding single-endpoint behavior, so an agent can tell them apart.
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 guidance: send when you actually hit something, once per problem. It also gives an explicit when-not-to-use rule by stating that a problem with a single endpoint's own behavior belongs in `rate` instead, which directly routes the agent to the correct sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the response from a paid call you already made. Free: the call is already paid for. Use it when call never returned. A long generative endpoint can outrun your client's own request timeout, and the call is charged and completed regardless, so the result is yours. Do NOT repeat the call in that situation: that is a second charge for work already bought. Call this with no arguments to list your recent paid calls, newest first, and pass the request_id of the one you want. Results are kept for 60 minutes.
| Name | Required | Description | Default |
|---|---|---|---|
| request_id | No | the call to fetch. Omit to list your recent paid calls and their request ids |
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 states the operation is free, that the underlying call was charged and completed regardless, that calling with no arguments lists recent paid calls newest first, and that results are kept for 60 minutes. These are the key behavior details an agent needs.
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 longer than two sentences but every sentence earns its place: purpose, cost model, trigger condition, timeout rationale, charge warning, usage pattern, and retention window. It is front-loaded with the core purpose and wastes no words.
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 one-optional-parameter retrieval tool with no output schema, the description is complete. It explains both invocation modes (no args to list, with `request_id` to fetch), the retention limit, and the critical billing consequence. An agent has everything needed to call it 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?
The schema already documents `request_id` at 100% coverage, including the omit-to-list behavior. The description adds minor useful context like 'newest first' and the free-of-charge aspect, but this is mostly behavioral rather than new parameter-level meaning. 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?
The description names a specific verb ('Get the response'), a specific resource ('a paid call you already made'), and explicitly frames the tool as a retrieval mechanism for calls whose result never arrived. It also distinguishes itself from the `call` sibling by warning not to repeat `call`, so an agent can select it unambiguously.
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 an explicit trigger condition ('Use it when `call` never returned'), explains why that happens (client timeout), and gives a clear exclusion: do NOT repeat `call` because it causes a second charge. This is exemplary alternative-selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rate 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. For problems with taskfuel itself rather than one endpoint, use feedback.
| 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 provided, the description carries the full behavioral burden and does so well. It discloses one-vote-per-endpoint behavior, that re-voting replaces the previous vote, that `report` is optional and does not change the rating, and that the vote and report must agree. It also sets expectations around what should not be down-voted.
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 fairly long, but nearly every sentence contributes a needed rule or example. It is front-loaded with the core purpose, then covers exclusions, report semantics, replacement behavior, and alternatives. It could be slightly better structured with separators, but the length is justified given the nuanced behavior.
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 4 parameters, no output schema, and no annotations, this description is remarkably complete. It covers the required inputs, how to obtain them, what counts as up/down, exclusions, report semantics, vote replacement, and alternative routing to `feedback`. An agent has enough context to invoke this tool correctly in most situations.
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 covers all parameters, the description adds important semantics beyond the schema: `method` and `url` must match exactly what `discover` returned, `vote` meanings are reinforced, and `report` should describe concrete disruptions like unexpected response codes or ignored arguments. It also adds a constraint not in the schema: do not include secrets or response data in `report`.
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 and object: 'Rate a documented endpoint you called.' It clearly defines the up/down vote semantics and scope, and distinguishes itself from sibling tools by explicitly routing non-endpoint issues to `feedback`. An agent can tell exactly what this tool is for.
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 when-to-use guidance: rate only endpoints you actually called, using method/url as returned by `discover`, and judge against the endpoint's own docs. It also lists specific non-down-vote cases and names `feedback` as the alternative for taskfuel-level problems, leaving little room for misuse.
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_resultfeedback6 fields changedInput schema / properties / messageAdded value: +{
+ "description": "what happened and what you expected, briefly and concretely. Up to 2000 characters",
+ "maxLength": 2000,
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / methodRemoved value: -{
- "description": "HTTP method of the endpoint, as `discover` returned it",
- "minLength": 1,
- "type": "string"
-}Input schema / properties / reportRemoved value: -{
- "description": "what concretely disrupted usage (unexpected response code, ignored arguments, low-quality response); do not include secrets or response data. Up to 2000 characters",
- "maxLength": 2000,
- "minLength": 1,
- "type": "string"
-}Input schema / properties / urlRemoved value: -{
- "description": "the endpoint URL, as `discover` returned it",
- "minLength": 1,
- "type": "string"
-}Input schema / properties / voteRemoved value: -{
- "description": "up = you got the expected/useful result; down = it didn't work or wasn't worth the price",
- "enum": [
- "up",
- "down"
- ],
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "method",
- "url",
- "vote"
-]New value: +[
+ "message"
+]ratecall1 field changedInput schema / properties / modelAdded value: +{
+ "description": "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.",
+ "type": "string"
+}feedback1 field changedInput schema / properties / report / descriptionPrevious value: -"what concretely disrupted usage (unexpected response code, ignored arguments, low-quality response); do not include secrets or response data"New value: +"what concretely disrupted usage (unexpected response code, ignored arguments, low-quality response); do not include secrets or response data. Up to 2000 characters"call2 fields changedInput schema / properties / body / descriptionPrevious value: -"request body, sent as JSON — pass the object itself, e.g. {\"prompt\": \"a cat\"}, not a JSON-encoded string"New value: +"request body, sent as JSON: pass the object itself, e.g. {\"prompt\": \"a cat\"}, not a JSON-encoded string"Input schema / properties / headers / descriptionPrevious value: -"extra request headers — no auth headers needed"New value: +"extra request headers, no auth headers needed"discover1 field changedInput schema / properties / url / descriptionPrevious value: -"an endpoint URL — with `method`, returns its full docs"New value: +"an endpoint URL. With `method`, returns its full docs"feedbackbalance2 fields changedInput schema / properties / contextRemoved value: -{
- "description": "Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\"",
- "type": "string"
-}Input schema / requiredRemoved value: -[
- "context"
-]call2 fields changedInput schema / properties / contextRemoved value: -{
- "description": "Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\"",
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "url",
- "context"
-]New value: +[
+ "url"
+]discover2 fields changedInput schema / properties / contextRemoved value: -{
- "description": "Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\"",
- "type": "string"
-}Input schema / requiredRemoved value: -[
- "context"
-]balance2 fields changedInput schema / properties / contextAdded value: +{
+ "description": "Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\"",
+ "type": "string"
+}Input schema / requiredAdded value: +[
+ "context"
+]call2 fields changedInput schema / properties / contextAdded value: +{
+ "description": "Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\"",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "url"
-]New value: +[
+ "url",
+ "context"
+]discover2 fields changedInput schema / properties / contextAdded value: +{
+ "description": "Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\"",
+ "type": "string"
+}Input schema / requiredAdded value: +[
+ "context"
+]balancecalldiscoverClaiming 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!
Add one secure layer between your agents and this server.
Each tool has a clearly distinct role: discover finds endpoints, call executes them, balance reports funds, rate evaluates a specific endpoint, and feedback addresses gateway-level issues. The only potential overlap (rate vs feedback) is explicitly resolved in the descriptions.
All tools use short lowercase single-word names, giving the set a consistent style. balance and feedback are noun-like while the others are verbs, but this is a minor deviation and does not create confusion.
Five tools is well-scoped for a paid API gateway: discovery, execution, balance checking, endpoint rating, and gateway feedback cover the core loop without redundant helpers.
The core workflow of finding, calling, and paying for endpoints is complete, with balance and feedback/rating closing the loop. Minor gaps such as transaction history or account management are not essential to the stated purpose.