changegamer
Server Details
Agent-first resource directory for AI agents: protocols, security, RAG, memory, evals, and more.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.3/5 across 10 of 10 tools scored. Lowest: 3.7/5.
Each tool has a clearly distinct purpose: check_access verifies a specific key, get_access_info returns general access info, get_corpus returns free corpus, get_full_corpus returns premium corpus, get_payment_info gives payment methods, get_pricing gives pricing tiers, get_resource fetches by slug, get_stats gives corpus statistics, list_resources lists metadata, search_resources searches content. No overlap.
All tool names follow a consistent verb_noun pattern (check_access, get_*, list_resources, search_resources). Underscore separation is uniform. No mixing of camelCase or other styles.
10 tools is well-scoped for a resource access API. Each tool covers a distinct aspect of the domain (access, corpus, pricing, search, etc.) without being too few or too many.
The tool set covers all necessary operations for accessing ChangeGamer resources: listing, searching, fetching individual resources (free and premium), corpus access in two tiers, stats, payment/pricing info, and access verification. No obvious gaps for the intended use case.
Available Tools
10 toolscheck_accessAInspect
Verify an access key and report what it unlocks. Returns valid:true/false; when valid, the tier, when it was created, the premium slugs it unlocks, and that it grants the gated /api/corpus.full.jsonl + get_full_corpus deliverable. Never returns the key, email, or Stripe session. Use this to confirm a freshly-purchased key works before relying on it.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | Yes | Access key to verify (cg_...) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavioral traits: returns valid:true/false, details of valid responses, and explicitly lists what is never returned. No contradictions.
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?
Concise and well-structured: opens with primary purpose, then enumerates return values and exclusions. Every sentence adds value, 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 simple verification tool with one parameter, the description fully covers return information and exclusions. No output schema exists, so the description compensates adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description for the single parameter 'api_key'. The description adds context about usage (freshly-purchased) but does not significantly enhance the schema's semantic meaning.
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 function: 'Verify an access key and report what it unlocks.' It lists specific return values (valid, tier, created time, premium slugs, deliverables) and explicitly states what it does not return (key, email, Stripe session), differentiating it from siblings like get_access_info.
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?
Provides a clear use case: 'Use this to confirm a freshly-purchased key works before relying on it.' Does not explicitly mention alternatives or when not to use, but the instruction is actionable and context-specific.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_access_infoAInspect
Return current access and pricing information for ChangeGamer resources.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It implies a read-only operation ('return'), which is positive, but gives no insight into side effects, authorization needs, or output format. For a 0-parameter tool, basic safety is implied but not elaborated.
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?
A single, concise sentence that conveys the core purpose with no extraneous words. Perfectly efficient for a simple tool.
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 should hint at the return structure. It mentions 'access and pricing information' but doesn't specify what fields or format to expect. For a 0-parameter tool, it's adequate but could provide more detail on the data shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and the schema coverage is trivially 100%. The description adds no parameter info, but none is needed. Baseline is 4 for zero-parameter tools, as the schema fully documents the empty set.
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?
Verb 'return' and resource 'access and pricing information for ChangeGamer resources' clearly state the tool's purpose. It is distinct from siblings 'get_resource' (returns a specific resource) and 'list_resources' (lists resources), which focus on different aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'get_resource' or 'list_resources'. An explicit condition or exclusion would help, e.g., 'Use this when you need access rights or pricing, not when you need the resource content itself.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_corpusAInspect
Return the entire free corpus as one document (every free resource title, description, canonical URL, and full Markdown body) — the same content as /llms-full.txt. Premium resources appear as a stub with a purchase link, not their body. Use this to ingest everything in a single call; the response is large.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It discloses that free resources have full body, premium resources have stub with purchase link, and response is large. However, it doesn't mention read-only nature, authentication needs, or rate limits, though these are implied for a GET-like operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. First sentence defines output, second adds usage guidance and warning. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description adequately explains output contents (free resource details, premium stubs) and mentions response size. Lacks explicit format specification but references /llms-full.txt as a known source, making it sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; schema coverage is 100%. The description adds no parameter info, but per guidelines, 0 parameters baseline is 4, and description does not need to compensate.
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 returns the entire free corpus as one document, listing specific fields included and noting premium resources are stubs. It distinguishes itself from sibling tools by emphasizing it's a single call to ingest everything, contrasting with get_resource for single resources.
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 advises use for ingesting everything in one call, with a warning about large response size. Implicitly differentiates from siblings by describing the all-in-one nature, though no explicit when-not-to-use or alternative tool names are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_full_corpusAInspect
Return the ENTIRE corpus including premium resource bodies in one document — the keyed deliverable of the Corpus/Enterprise license. Requires a Corpus- or Enterprise-tier api_key (a Starter key unlocks premium resources but NOT the corpus file); without an entitled key a payment-required/upgrade object is returned. The free, premium-stubbed version is get_corpus.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | Corpus/Enterprise license key (cg_...) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description fully discloses the tool's behavior: it returns the full corpus for entitled keys, otherwise returns a payment-required/upgrade object. No hidden behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with the main action, each sentence adds necessary context with no wasted 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?
Given no output schema and no annotations, the description covers purpose, key requirement, error case, and alternative. Missing return format details, but acceptable for a single-parameter 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 schema already describes the api_key parameter; the description adds value by specifying that Starter keys are insufficient, reinforcing the tier requirement beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns the entire corpus including premium resource bodies, and distinguishes it from the sibling tool get_corpus (free, premium-stubbed version).
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 says requires Corpus- or Enterprise-tier api_key, explains what happens without an entitled key (payment object returned), and points to get_corpus as the alternative for free access.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_payment_infoAInspect
Return the agent payment manifest: every way to pay (HTTP 402 + Bearer key, MCP, Stripe checkout, x402, RSL per-crawl), the exact 402 retry loop, what is always free, and the recommended path per use case. Same data as /api/payment.json.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it is a read-only operation that returns data with no side effects. It details the exact content, including payment methods and retry loop, ensuring transparency.
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, front-loaded with the main purpose. It efficiently packs detailed information about what the tool returns without unnecessary 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?
Despite no output schema, the description thoroughly explains the return value, listing all components such as payment methods, retry loop, free content, and recommendation path. It is complete for a zero-parameter 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?
There are no parameters, so schema coverage is 100%. The description adds no parameter information, but none is needed. Baseline 4 applies for zero-parameter tools.
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 returns the agent payment manifest, listing specific components like payment methods, retry loop, free content, and recommended path. It uses the verb 'Return' with a specific resource, distinguishing it from siblings like get_pricing.
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 implies usage when payment details are needed and notes it is the same as an API endpoint. However, it does not explicitly state when to use or avoid this tool compared to siblings, though the unique content makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_pricingAInspect
Return the full paid-offer catalog: every tier with price, currency, interval, checkout URL, what it unlocks, deliverables, and license grant — plus the free layer and premium slug list. Same data as /api/pricing.json.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states it returns data without side effects, but does not explicitly confirm it is a read-only, safe operation. The reference to '/api/pricing.json' implies idempotency, but more clarity on non-destructiveness would help.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. First sentence states the main purpose and enumerates key outputs. Second sentence adds a useful anchor to a known API endpoint. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description enumerates the major parts of the return data (price, currency, interval, etc.). It covers the catalog scope, including free layer and premium slug list. Minor gap: no mention of pagination or size of catalog, but for a tool returning static pricing data, it is fairly 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?
Tool has zero parameters, and schema coverage is 100%. Description does not need to add parameter information. Baseline 4 is appropriate as there is nothing to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it returns the full paid-offer catalog and lists specific fields (price, currency, interval, checkout URL, unlocks, deliverables, license grant, free layer, premium slug list). Verb 'Return' with resource 'full paid-offer catalog' is unambiguous. Sibling tools like get_resource or get_payment_info have different purposes.
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 explicit 'when to use' or 'when not to use' guidance. The description implies it is for getting the complete pricing data, but alternatives like get_payment_info or list_resources are not contrasted. Usage context is clear but not articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_resourceAInspect
Fetch a ChangeGamer resource by slug. Free resources return full metadata and Markdown body. Premium resources require a valid api_key; without one a payment-required object is returned.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Resource slug (e.g. "getting-started") | |
| api_key | No | Access key for premium resources |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fully covers behavioral traits: free vs premium responses, payment-required object on unauthorized premium access. It does not mention rate limits or error details, but the key behaviors are transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with core purpose, no redundant information. Every word 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?
Given no output schema, the description fully explains return values for free, premium (with/without key). It covers both parameters and the critical behavioral distinction, making the tool completely self-explanatory.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds value by clarifying the conditional need for api_key (premium only) and providing an example slug. This surpasses the baseline 3.
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 fetches a resource by slug, and distinguishes behavior for free vs premium resources. It is specific and differentiates from siblings get_access_info and list_resources.
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 explains when to use the tool (fetch by slug) and when an api_key is needed. It implies alternatives via sibling list but does not explicitly state when to use get_access_info or list_resources instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_statsAInspect
Return corpus stats: total/free/premium counts, per-category counts, tag count, newest/oldest update dates, the 10 most recently updated resources, and feed URLs. A small freshness/size signal to poll before deciding whether to re-ingest. Same data as /api/stats.json.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It details exactly what data is returned (stats, counts, dates, feeds) and mentions lightweight nature. No contradictory behavioral info needed.
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 sentences, no redundancy. Front-loaded with key data, then usage context, then reference to equivalent API endpoint.
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, no-output-schema tool, the description fully covers what the tool does, what it returns, and why to use it. No gaps given the simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, baseline is 4. Description adds meaning by explaining the returned data, which is helpful beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns corpus stats with specific fields like total/premium counts, per-category counts, and recent updates. It distinguishes itself from siblings by specifying the lightweight, polling-purpose nature.
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 states usage as 'a small freshness/size signal to poll before deciding whether to re-ingest', giving clear context. However, it doesn't compare directly to siblings or state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_resourcesAInspect
List all ChangeGamer resources with metadata and absolute URLs. Returns slug, title, description, category, tags, updated date, premium flag, and HTML/Markdown/JSON variant URLs. No body content.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool returns metadata and absolute URLs, and explicitly states 'No body content,' which is a key behavioral trait. Without annotations, it covers the core behavior adequately, though it could mention any side effects or auth requirements (unlikely for a listing 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 consists of two sentences with no wasted words. The first sentence states the core purpose, and the second lists return fields and a critical detail (no body content). It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description is reasonably complete. It covers what the tool does and what it returns. However, it could mention the relationship to sibling tools or any default ordering, but is sufficient for basic understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is trivially 100%. According to guidelines, the baseline for 0 parameters is 4, and the description does not need to add parameter semantics.
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 lists all ChangeGamer resources with metadata, distinguishing it from sibling tools like get_resource which likely retrieves a single resource. The verb 'List' and the scope 'all' make the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any explicit guidance on when to use this tool versus alternatives like get_resource or get_access_info. While the name and description imply it's for listing all resources, there is no direct comparison or usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_resourcesAInspect
Search the ChangeGamer corpus by keyword. Ranks resources by relevance across title, description, tags, category, and body, and returns metadata plus HTML/Markdown/JSON URLs (no body content). Use this to find resources before fetching them with get_resource.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results (default 10). | |
| query | Yes | Search keywords, e.g. "retrieval augmented generation" or "mcp auth" |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses important behavior: returns only metadata and URLs (no body content), ranks across specified fields. This sufficiently informs an agent of what to expect, though additional details like authentication or rate limits could improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, entirely non-redundant. First describes functionality, second gives usage context. Every word 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?
With no output schema, the description adequately explains the response structure (metadata and URLs, no body). It also explains ranking logic and mentions the fields searched. For a 2-parameter tool, this is comprehensive.
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?
Input schema covers both parameters with descriptions (100% coverage). The description adds value by providing example search keywords and explaining the ranking across fields, enhancing the schema's meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool searches the ChangeGamer corpus by keyword, ranks by relevance, and returns metadata and URLs. It explicitly differentiates from the sibling get_resource by noting 'no body content' and advising to use this before fetching with get_resource.
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 advises 'Use this to find resources before fetching them with get_resource', providing clear guidance on when to use it relative to a sibling. No explicit mention of when not to use it compared to list_resources, but the context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!