Where a link really goes, what the server says about itself, and what pages a site publishes.
FREE, no payment. The aggregate of what agents have told us they are looking for, most-requested first, with the categories nothing available yet serves.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Window in days, default 30, max 90. |
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 that the tool is free, returns an aggregate, is ordered most-requested first, and covers categories with no available solution. However, it does not describe the output format, pagination, data freshness, authentication requirements, or rate limits, leaving meaningful gaps.
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 short and front-loaded with the free aspect, but the main sentence is grammatically awkward and confusing: 'with the categories nothing available yet serves' obscures meaning. Clarity is sacrificed, so this is under-specified rather than cleanly 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?
The tool is simple with one optional parameter and no output schema, so the description partially explains the return content. However, it does not clarify the output structure, how to interpret the categories, or when this report should be preferred over sibling tools. The confusing phrasing further reduces completeness.
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 only parameter, 'days,' is well documented with a default and maximum. The description adds no parameter-specific meaning, but the schema already provides enough for correct invocation. 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 clearly identifies the resource: an aggregate report of what agents are looking for, ordered by request frequency. The title reinforces this. It differentiates from siblings by describing a demand summary rather than a data-fetching or URL utility, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus request_data, site_pages, or resolve_url. The only contextual hint is 'FREE, no payment,' which addresses cost rather than selection criteria. Usage context is only implied by the general idea of a demand report.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FREE, no payment. Describe in your own words the data you are trying to buy — anything, not just URLs — and get back whether we operate a service that supplies it, with the MCP endpoint if so. Every request is catalogued so repeatedly-requested data gets built. Nothing identifying is stored, only the words of the request.
| Name | Required | Description | Default |
|---|---|---|---|
| need | Yes | What you are looking for. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden and meets it: it states the operation is free, that requests are catalogued, that no identifying information is stored, and what the response will contain. This gives an agent a clear picture of side effects and privacy expectations beyond the bare schema.
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, each carrying necessary information: cost, expected outcome, and data-handling behavior. The description is front-loaded with the most actionable detail 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 single-parameter tool with no output schema, the description fully equips an agent: what to submit, what to expect back, cost implications, and privacy guarantees. Nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents the 'need' parameter with an example. The description reinforces that the parameter can be free-form ('anything, not just URLs'), but adds no new semantic detail beyond what the schema provides. 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 clearly states the tool's action: users describe in their own words what data they want, and the tool returns whether a service supplies it plus the MCP endpoint. It distinguishes itself from sibling tools by explicitly covering 'anything, not just URLs,' positioning it as a free-form request tool rather than a concrete URL/page/header resolver.
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 when to use it: when the desired data isn't easily expressed as a URL and you want to check availability before buying. It does not explicitly name sibling tools or state 'use resolve_url/site_pages/url_headers for URL-based lookups,' so some inference is required, but the 'anything, not just URLs' phrasing provides reasonable context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Follow a URL's redirect chain one hop at a time and report every step: each intermediate host and status, the final destination, whether it crossed to a different host, and a cleaned copy with tracking parameters (utm_*, fbclid, gclid and friends) stripped. Use before following or showing a shortened, tracked or unfamiliar link — a shortener cannot hide its destination from this. Stops after 10 hops, and refuses to follow a redirect into private address space. Costs $0.005 USDC per call via x402 on Base.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL to resolve, e.g. a shortened or tracked link. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the behavioral burden. It discloses the one-hop iteration behavior, the 10-hop limit, refusal to follow redirects into private address space, and the per-call cost via x402 on Base. This is far beyond minimal and gives the agent realistic expectations.
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 pack the purpose, output details, usage guidance, safety limits, and cost without redundancy. The most important behavior is front-loaded, and every clause 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?
For a single-parameter tool with no output schema and no annotations, the description is remarkably complete: it explains what the result contains, how far it will go, what it refuses to do, and what it costs. An agent has enough context to select the tool and interpret its results.
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 lone 'url' parameter is already described with an example. The description adds contextual color about shortened/tracked/unfamiliar links, but does not materially extend the parameter semantics beyond what the schema provides, so 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 states a precise operation—following a URL's redirect chain hop by hop and reporting each step—along with the specific outputs (intermediate host/status, final destination, cross-host flag, cleaned URL). This clearly distinguishes it from siblings like url_headers, which inspects headers rather than resolving redirects.
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 explicitly says to use the tool before following or showing a shortened, tracked, or unfamiliar link, and notes that a shortener cannot hide its destination. It does not explicitly name alternative tools or exclusion cases, but the use context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The pages a site declares in its sitemap, with last-modified dates, located via robots.txt first and the conventional /sitemap.xml second. Use to enumerate a documentation set or a blog archive before deciding what to read, instead of crawling blindly. A sitemap index is reported as such, so you know to call again for the child sitemaps. Costs $0.008 USDC per call via x402 on Base.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Site root (e.g. 'https://example.com') or a sitemap URL directly. | |
| limit | No | Maximum entries to return. Default 200, maximum 1000. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does substantial work: it discloses the lookup order (robots.txt then /sitemap.xml), how sitemap indexes are surfaced, and the per-call cost of $0.008 USDC. The cost disclosure is especially valuable behavioral context for an agent deciding whether to invoke. It stops short of describing failure behavior when no sitemap exists, a modest gap.
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 with distinct value: core function, usage guidance, edge-case index behavior, and cost. The most important information is front-loaded, and there is zero redundancy with the schema or title.
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 read-only enumeration tool with 2 parameters and no output schema, the description covers the essential ground: what is returned, how it is located, index handling, and pricing. The lack of an output schema raises some burden to describe return shape, which is partially addressed ('pages with last-modified dates'). Error and pagination details could round it out but are not critical.
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% for both parameters, so the baseline of 3 applies. The description adds implied meaning to the url parameter by explaining how the root URL is resolved (robots.txt first), but the limit parameter semantics are fully handled by the schema. The description does not need to compensate for any schema gap.
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 the specific resource ('pages a site declares in its sitemap'), the data included (last-modified dates), and the discovery method (robots.txt first, /sitemap.xml second). This clearly differentiates it from sibling tools like resolve_url and url_headers, which handle URL mechanics rather than content enumeration.
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?
Explicit use cases are given: enumerate a documentation set or blog archive before deciding what to read. The phrase 'instead of crawling blindly' provides an exclusion condition. The sitemap-index note ('call again for the child sitemaps') advises a follow-up action. It doesn't name sibling alternatives, but the siblings serve clearly different purposes, so the omission is minor.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Response status, server software, content type, caching, and which of the six standard security headers the host sets or omits. Use to check a URL is live and well-formed before relying on it, or to profile a site cheaply without downloading it. Header presence is a hygiene signal, not a safety verdict — a site can set every header and still be malicious. Costs $0.005 USDC per call via x402 on Base.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL to inspect. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It goes beyond the basic fetch by disclosing the cost per call ($0.005 USDC via x402 on Base) and adding an important interpretive caveat that header presence is a hygiene signal, not a safety verdict. This is meaningful behavioral and risk context.
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 earning its place: output inventory, use cases, safety caveat, and cost. The most important scoping information is front-loaded, and there is no redundant or filler text.
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 and no annotations, the description covers selection, invocation, cost, interpretation, and limitations. An agent has enough context to decide when to call it and what to expect without needing additional documentation.
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 schema already documents the single 'url' parameter with examples and a clear description. The tool description adds little beyond implying the URL should be well-formed, so the 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 clearly identifies the tool's purpose by enumerating what it returns: response status, server software, content type, caching, and security headers. It implies a fetch/inspect operation on a URL without naming a sibling alternative, but the resource and output are specific enough to distinguish it from the sibling list.
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 explicit use cases: checking whether a URL is live and well-formed before relying on it, and cheaply profiling a site without downloading it. It does not state when not to use it or name alternative tools, so it falls short of a 5, but the context is clear.
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.
demand_report1 field changedInput schema / properties / days / examplesAdded value: +[
+ "30"
+]request_data1 field changedInput schema / properties / need / examplesAdded value: +[
+ "live electricity spot prices by ZIP"
+]resolve_url1 field changedInput schema / properties / url / examplesAdded value: +[
+ "https://bit.ly/example"
+]site_pages2 fields changedInput schema / properties / limit / examplesAdded value: +[
+ "200"
+]Input schema / properties / url / examplesAdded value: +[
+ "https://example.com"
+]url_headers1 field changedInput schema / properties / url / examplesAdded value: +[
+ "https://example.com"
+]demand_reportrequest_dataresolve_urlsite_pagesurl_headersClaiming 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!
Check how well AI agents can discover and understand a public website.
Live DNS, email-auth and redirect checks, HTTP security headers, uptime history, PC hardware prices.
Does a cited URL exist, and does the source name what your claim names? Two answers.
Robots-aware website audits, pre-crawl quotes, and structured evidence for people and agents.
Add one secure layer between your agents and this server.
The three URL tools are sharply separated: resolve_url handles redirects, site_pages enumerates sitemaps, and url_headers inspects headers. The only mild ambiguity is demand_report versus request_data, but their descriptions make the read-aggregate vs query/submit distinction clear enough.
All names are snake_case and readable, but the set mixes imperative verb phrases (resolve_url, request_data) with bare noun compounds (site_pages, url_headers, demand_report). There is no consistent verb_noun or noun_noun convention across the server.
Five tools is a manageable count and not bloated. However, demand_report and request_data are data-marketplace features rather than URL intelligence, so the scope is slightly broader than the server name implies.
The URL tools cover a coherent pre-fetch workflow: redirect resolution, header/status profiling, and sitemap enumeration. There is no content-fetch or reputation-check tool, but those appear to be out of scope, and demand_report/request_data provide a way to ask for missing data, so the surface has no dead end.
