19 free website QA and AI-visibility tools. Remote HTTP MCP, no account, no API key.
Build a campaign URL with utm parameters, normalised to one tagging convention, and report which GA4 default channel group the link will land in. Warns about the mistakes that silently break reporting: an unrecognised medium that drops traffic into Unassigned, casing that splits one source into several report rows, PII in a campaign name. Pure string work: nothing is fetched and nothing is stored.
Returns { url, normalized, channel, issues[] with level, field and message }. Limit: None. The work is local and costs nothing.. Allow up to 10s for a response. Free, no account, no API key.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | utm_id. Optional campaign ID. | |
| url | Yes | The destination page. Existing utm parameters on it are rewritten; any other query parameter is left alone. | |
| term | No | utm_term. Optional paid keyword. | |
| medium | No | utm_medium. How it gets there, e.g. email, cpc, social. This is the field GA4 reads to pick a channel. | |
| source | No | utm_source. Where the traffic comes from, e.g. newsletter. | |
| content | No | utm_content. Optional variant, e.g. header_link. | |
| campaign | No | utm_campaign. The campaign name, e.g. spring_launch. | |
| caseRule | No | How values are cased before they go in the URL. Default lower, which is what keeps one source from becoming three report rows. | lower |
| spaceRule | No | What happens to spaces inside a value. | underscore |
| stripPunctuation | No | Drop accents and punctuation that make report rows hard to match. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although no annotations are provided, the description is highly transparent: it states the tool performs only string operations, makes no network calls, stores nothing, and is free with no account or API key. It also discloses potential pitfalls in reporting, such as unrecognized mediums and PII in campaign names.
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 mostly concise but contains redundancy: 'Pure string work: nothing is fetched and nothing is stored' is repeated in the return section as 'The work is local and costs nothing.' Also, 'Limit: None' appears twice. The structure could be tightened 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?
Given the tool has no output schema, the description compensates by explicitly stating the return structure: {url, normalized, channel, issues[]}. It also mentions common edge cases (unrecognized medium, casing issues, PII) that could affect output. However, it does not specify error handling for invalid URLs or other potential failures, which would make it more 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?
All 10 parameters have clear, descriptive text (100% schema coverage). For example, 'source' is described as 'Where the traffic comes from' and enums for caseRule and spaceRule are explained. This exceeds the baseline and fully compensates for the lack of detailed parameter annotations.
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 builds a campaign URL with UTM parameters, normalizes them, and reports the GA4 default channel group. It also lists specific warning behaviors, distinguishing it from sibling tools like screenshot or AI visibility checkers.
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 (e.g., 'Pure string work: nothing is fetched and nothing is stored'), but it does not explicitly state when to use this tool versus alternatives, nor provide exclusion criteria. The context from sibling tools makes the purpose clear, but explicit guidance is lacking.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Capture a full-height PNG of a page in a real headless browser, scrolling first so lazy-loaded content renders. Returns a signed link to the image that expires in about 24 hours; download the bytes if you need to keep them. No watermark and no height cap. Cannot capture anything behind a login.
Returns { imageUrl, expiresAt, bytes, width, height, deviceType }. Limit: 10 runs per hour per IP. Allow up to 90s for a response. Free, no account, no API key.
Pass url to start a run. A slow run answers with { status: "pending", runId } instead of a result: call this same tool again with just that runId to collect it, as many times as it takes. Collecting costs no rate-limit slot.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | The page to run against. A bare domain like example.com is fine; https is assumed. Must be a public URL: anything behind a login, on a private network, or on localhost is refused. | |
| runId | No | Collect a run that answered with `{ status: "pending", runId }` instead of a result. Send the runId back on its own, with no url, and the same tool returns the finished result once the run is done. Costs no rate-limit slot. | |
| refresh | No | Skip the 24 hour cache and run again. Costs a rate-limit slot even when a cached result exists, so leave it off unless the page has changed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility and exceeds it: it discloses real-browser behavior, scrolling, 24-hour link expiry, no watermark/height cap, login limitation, rate limit, 90s timeout, async pending/runId polling, and refresh caching semantics. Nothing is hidden.
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?
Every sentence carries operational information; the main capability and key constraints are front-loaded, then async behavior and return shape follow. Despite length, there is no filler or repetition of annotations.
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 exists, but the description lists the returned fields. It covers rate limits, timeout, auth limitations, cache/refresh behavior, and the polling protocol, making it fully actionable for a complex 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?
Schema coverage is 100%, so the baseline is 3; the description adds value by explaining the start-vs-collect workflow, repeating polling at no extra rate cost, and reinforcing that refresh bypasses cache. It does not define a new parameter format, but it clarifies usage enough to earn above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb+resource: capture a full-height PNG of a page in a real headless browser. It clearly delineates the screenshot scope and is distinct from siblings such as page_to_markdown and check_social_preview, so an agent can identify it without inferring.
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?
Gives clear when-to-use context: rendered page capture with lazy-loaded content, public URLs only, and explicit exclusions like login/private/localhost. It does not explicitly name an alternative tool for non-screenshot needs, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether AI assistants (ChatGPT, Claude, Perplexity, Google AI) can reach, read, and cite a web page. Runs the full suite: robots.txt rules per AI crawler, a live firewall test that requests the page as GPTBot, JavaScript dependency, llms.txt, headings, structured data, and author identity. Returns a score out of 100 with a grade, a score per category, and a finding per check with why it matters and how to fix it. Use this for a whole-page verdict; use check_robots_txt_for_ai when the question is only about crawler access.
Returns { ok, report: { score, grade, scoredOutOf, categories[], findings[] with why and fix, detection }, cached, ageSeconds }. Limit: 10 runs per hour per IP. Allow up to 75s for a response. Free, no account, no API key.
Pass url to start a run. A slow run answers with { status: "pending", runId } instead of a result: call this same tool again with just that runId to collect it, as many times as it takes. Collecting costs no rate-limit slot.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | The page to run against. A bare domain like example.com is fine; https is assumed. Must be a public URL: anything behind a login, on a private network, or on localhost is refused. | |
| runId | No | Collect a run that answered with `{ status: "pending", runId }` instead of a result. Send the runId back on its own, with no url, and the same tool returns the finished result once the run is done. Costs no rate-limit slot. | |
| refresh | No | Skip the 24 hour cache and run again. Costs a rate-limit slot even when a cached result exists, so leave it off unless the page has changed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so thoroughly. It discloses rate limits, response time, caching behavior, authentication requirements, the async pending flow, and the exact return shape, giving the agent an accurate model of the tool's runtime behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place: purpose, checks, output, alternative tool, limits, and run lifecycle. It is front-loaded with the core purpose and then gives operational details in a logical order without fluff.
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 and the absence of an output schema, the description fully covers return values, async collection, rate limits, and required inputs. Nothing an agent needs to invoke the tool correctly or interpret the result 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?
Although the schema already documents all three parameters, the description adds essential interaction semantics: url starts a run, runId collects a pending result and costs no rate-limit slot, and refresh skips cache but costs a slot. This goes well beyond the schema and prevents misuse.
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 resource: checking whether AI assistants can reach, read, and cite a web page. It then lists the exact checks run and names the sibling tool check_robots_txt_for_ai as a narrower alternative, making differentiation immediate.
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 this tool for a whole-page verdict and to use check_robots_txt_for_ai when only crawler access matters. It also explains the asynchronous flow (pass url, collect with runId), cache refresh rules, and rate-limit costs, so the agent knows exactly when and how to call it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether a site's favicon actually works. Reads every icon declaration in the page head, then fetches each one, the web app manifest, and the implicit /favicon.ico, and identifies the real format and pixel dimensions from each file's header bytes. Catches the failures a status-code check misses: a catch-all route answering an icon path with HTML at HTTP 200, a sizes attribute that disagrees with the file, an icon served over http on an https page. Use this when a favicon is missing or blurry; use check_social_preview for the image that appears when a link is shared.
Returns { hasWorkingFavicon, tabIcon, icons[] with format, dimensions, bytes and problem, manifest, themeColor, checks[] with id, status and fix, counts }. Limit: 60 runs per hour per IP. Allow up to 30s for a response. Free, no account, no API key.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The page to run against. A bare domain like example.com is fine; https is assumed. Must be a public URL: anything behind a login, on a private network, or on localhost is refused. | |
| refresh | No | Skip the 24 hour cache and run again. Costs a rate-limit slot even when a cached result exists, so leave it off unless the page has changed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so thoroughly. It discloses exactly what the tool fetches (every icon declaration, manifest, /favicon.ico), how it inspects bytes, which edge cases it catches, rate limits, response timeout, and that no account/API key is needed. This is exemplary disclosure for an unannotated 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 is front-loaded with the core purpose, followed by method, use case, return shape, and operational limits. Each sentence serves a distinct function with no filler or redundancy. Despite being detailed, it remains efficiently organized.
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?
This is a complex tool with no output schema and no annotations, but the description compensates by summarizing the return object with key fields and array contents. It also covers practical constraints like rate limits and response time. For a two-parameter tool, this is complete and actionable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and both parameters are already well documented in the input schema. The tool description adds no additional meaning beyond the schema, so the baseline of 3 applies. It reinforces the rate-limit nuance for refresh, but that is also captured in the schema parameter description.
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 resource: 'Check whether a site's favicon actually works.' It clearly distinguishes from sibling tools by explicitly naming check_social_preview as the alternative for link-share images. This is a precise, non-tautological statement.
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 direct when-to-use guidance: 'Use this when a favicon is missing or blurry.' It also names the alternative tool for a different use case, satisfying the when-not-to-use guidance. It further clarifies the public-URL requirement indirectly through the schema, which is reinforced by the tool's purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Test a site's robots.txt against every AI crawler that matters (GPTBot, ClaudeBot, PerplexityBot, Google-Extended, CCBot, Googlebot, Bingbot and the rest) and report which are allowed, which are blocked, and which rule decided it. Also runs a firewall test, because CDN-level blocks stop crawlers before robots.txt is ever read. This is the access-scoped view of check_ai_visibility.
Returns { ok, report: { accessScore, crawlers[] with the rule that decided each verdict, firewall, findings[] }, cached, ageSeconds }. Limit: 10 runs per hour per IP. Allow up to 75s for a response. Free, no account, no API key.
Pass url to start a run. A slow run answers with { status: "pending", runId } instead of a result: call this same tool again with just that runId to collect it, as many times as it takes. Collecting costs no rate-limit slot.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | The page to run against. A bare domain like example.com is fine; https is assumed. Must be a public URL: anything behind a login, on a private network, or on localhost is refused. | |
| runId | No | Collect a run that answered with `{ status: "pending", runId }` instead of a result. Send the runId back on its own, with no url, and the same tool returns the finished result once the run is done. Costs no rate-limit slot. | |
| refresh | No | Skip the 24 hour cache and run again. Costs a rate-limit slot even when a cached result exists, so leave it off unless the page has changed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, and it does so thoroughly. It discloses the async pending/runId flow, 24-hour caching, refresh cost, 10-run-per-hour IP limit, 75-second timeout, auth requirements (none), and the fact that a firewall test is included beyond robots.txt. This is genuinely transparent about how the tool behaves.
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 front-loaded with the core purpose in the first sentence, then efficiently covers return shape, limits, async behavior, and caching in a compact, scannable structure. Every sentence adds necessary information, and the length is justified by the tool's asynchronous and rate-limited nature.
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 having no output schema, the description includes a concise return shape, explains the pending-response mechanism, rate limits, caching, and authentication status. It provides everything an agent needs to call the tool correctly and interpret both immediate and delayed responses.
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 mostly restates what the schema already documents for url, runId, and refresh, adding little new parameter-level meaning beyond the flow context already present in the schema's own descriptions.
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 and resource ('Test a site's robots.txt against every AI crawler'), and clearly states what it reports (allowed, blocked, deciding rule). It also explicitly positions itself relative to the sibling tool check_ai_visibility by calling itself 'the access-scoped view,' which disambiguates it without needing to open the sibling's schema.
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 clear practical context for when and how to invoke the tool, including passing a URL, polling with runId, rate-limit behavior, and caching semantics. It names one sibling alternative ('access-scoped view of check_ai_visibility') but does not provide an explicit when-not-to-use statement or a broader decision rule comparing all alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a page's Open Graph and Twitter card tags and report how the link will render on X, LinkedIn, Facebook, Slack, Discord, and Google. Returns a per-platform preview (title, description, image) plus the findings for tags that are missing, truncated, or the wrong size.
Returns { ok, report: { previews[] per platform, tags, summary, findings[] }, cached, ageSeconds }. Limit: 10 runs per hour per IP. Allow up to 75s for a response. Free, no account, no API key.
Pass url to start a run. A slow run answers with { status: "pending", runId } instead of a result: call this same tool again with just that runId to collect it, as many times as it takes. Collecting costs no rate-limit slot.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | The page to run against. A bare domain like example.com is fine; https is assumed. Must be a public URL: anything behind a login, on a private network, or on localhost is refused. | |
| runId | No | Collect a run that answered with `{ status: "pending", runId }` instead of a result. Send the runId back on its own, with no url, and the same tool returns the finished result once the run is done. Costs no rate-limit slot. | |
| refresh | No | Skip the 24 hour cache and run again. Costs a rate-limit slot even when a cached result exists, so leave it off unless the page has changed. |
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 thoroughly: it discloses the 10-runs-per-hour rate limit, the 75-second timeout, the 24-hour cache, the async pending workflow, the rate-limit cost of `refresh`, and the lack of required auth. This is far beyond a minimal read-only or mutation hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place: purpose, output shape, limits, async flow, and param guidance. The return shape is plainly formatted, and the pending-run behavior is explained without fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must explain return values, and it does: `{ ok, report: { previews[], tags, summary, findings[] }, cached, ageSeconds }`. It also covers the meaningful edge cases for this tool, including cache behavior, rate limits, timeout, and public-URL restrictions, making it complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description reinforces the parameter workflow but largely echoes what the schema already says for `url`, `runId`, and `refresh`. It adds global context like rate limits and timeout, but not substantial per-parameter meaning 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 opens with a specific verb and resource: 'Read a page's Open Graph and Twitter card tags' and explains the resulting per-platform previews. This clearly distinguishes it from sibling tools like check_favicon or check_robots_txt_for_ai by the exact data it inspects and the output it produces.
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 clear usage context: pass `url` for a new run, pass `runId` to collect a pending result, and leave `refresh` off unless the page changed. It also states the public-URL constraint and rate-limit cost. It does not explicitly name alternatives or say when to prefer a sibling, but the use flow and constraints are well explained.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Identify the platform, framework, CMS, ecommerce apps, analytics, CDN, and hosting behind a site by fingerprinting one page's HTML and response headers. One fetch, no rendering and no crawl, so it answers in about a second. A site behind bot protection is reported as blocked rather than as empty.
Returns { platformName, theme, apps[], fonts[], analytics[], hosting[], renderMode, url, status, fetchedAt }. Limit: 60 runs per hour per IP. Allow up to 30s for a response. Free, no account, no API key.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The page to run against. A bare domain like example.com is fine; https is assumed. Must be a public URL: anything behind a login, on a private network, or on localhost is refused. | |
| refresh | No | Skip the 24 hour cache and run again. Costs a rate-limit slot even when a cached result exists, so leave it off unless the page has changed. |
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 covers the single-fetch behavior, no rendering/crawl, bot-protection handling ('reported as blocked rather than as empty'), rate limit (60/hour), timeout (30s), and auth requirements (free, no account, no API key). This is exceptionally 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?
The description is dense but every sentence earns its place: purpose, method, speed, edge-case behavior, return shape, limits, and auth. It is front-loaded with the core purpose and uses a compact return-fields list. 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?
Even without an output schema, the description enumerates the exact return fields and covers important edge cases (bot protection), operational limits, timeout, and authentication. For a two-parameter tool, this is fully complete and leaves no major gaps for an agent selecting or invoking it.
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 input schema already thoroughly documents both parameters, including the public-URL restriction and refresh cache semantics. The description adds general rate-limit and auth context, but no parameter-specific meaning beyond what the schema already provides.
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 ('Identify') and a precise resource scope ('platform, framework, CMS, ecommerce apps, analytics, CDN, and hosting behind a site'), and explains the method ('fingerprinting one page's HTML and response headers'). This clearly differentiates it from sibling tools like page_to_markdown or capture_full_page_screenshot, which serve 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?
The description gives clear context for when to use the tool: 'One fetch, no rendering and no crawl, so it answers in about a second.' This implies it is the fast, lightweight option for tech-stack detection. However, it does not explicitly name alternatives or state when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find every image on a page and draft alt text for the ones that need it, using a vision model that actually looks at the image. Lists every image with the alt it has today, the suggested alt, whether it looks decorative, and why any image was skipped. Up to 10 images per run go to the model. The suggestions are drafts for a human to review.
Returns { images[] with src, hadAlt, currentAlt, suggestedAlt, isDecorative, skippedReason; counts; model }. Limit: 10 runs per hour per IP. Allow up to 90s for a response. Free, no account, no API key.
Pass url to start a run. A slow run answers with { status: "pending", runId } instead of a result: call this same tool again with just that runId to collect it, as many times as it takes. Collecting costs no rate-limit slot.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | The page to run against. A bare domain like example.com is fine; https is assumed. Must be a public URL: anything behind a login, on a private network, or on localhost is refused. | |
| runId | No | Collect a run that answered with `{ status: "pending", runId }` instead of a result. Send the runId back on its own, with no url, and the same tool returns the finished result once the run is done. Costs no rate-limit slot. | |
| refresh | No | Skip the 24 hour cache and run again. Costs a rate-limit slot even when a cached result exists, so leave it off unless the page has changed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does an excellent job. It discloses the 10-image cap, the pending/runId async flow, 10-runs-per-hour rate limit, 90-second response allowance, free access, and why images may be skipped.
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 front-loaded with the core purpose, followed by return shape, limits, usage flow, and async polling instructions. Every sentence provides essential information, and the structure makes the content easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description responsibly defines the return object with its fields. It also covers the full lifecycle of a run, including async handling, rate limits, and the fact that results are drafts, leaving no critical gap for an agent to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds a little workflow context around url and runId, but the schema already explains each parameter in detail, including the pending run behavior and rate-limit cost of refresh.
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 resource: 'Find every image on a page and draft alt text for the ones that need it.' It also clarifies the mechanism (a vision model) and the deliverable (review-ready drafts), which clearly distinguishes it from sibling tools like page_to_markdown or capture_full_page_screenshot.
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 operational guidance: pass a url to start, poll with a runId if pending, and treat suggestions as drafts for human review. It does not explicitly name alternative tools or state when not to use this tool, but the intended context is unmistakable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a page and write a schema.org JSON-LD block for it, then validate that block against the same checks a validator would run. The markup is model-written from the page's own content and should be reviewed before it is published. Returns the block ready to paste into a tag.
Returns { ok, report: { detectedType, jsonLd, jsonLdString, validation: { findings[], passed }, model } }. Limit: 10 runs per hour per IP. Allow up to 75s for a response. Free, no account, no API key.
Pass url to start a run. A slow run answers with { status: "pending", runId } instead of a result: call this same tool again with just that runId to collect it, as many times as it takes. Collecting costs no rate-limit slot.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | The page to run against. A bare domain like example.com is fine; https is assumed. Must be a public URL: anything behind a login, on a private network, or on localhost is refused. | |
| runId | No | Collect a run that answered with `{ status: "pending", runId }` instead of a result. Send the runId back on its own, with no url, and the same tool returns the finished result once the run is done. Costs no rate-limit slot. | |
| refresh | No | Skip the 24 hour cache and run again. Costs a rate-limit slot even when a cached result exists, so leave it off unless the page has changed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does so thoroughly: async pending/runId behavior, 10 runs/hour/IP limit, 75s response allowance, free/no-account/no-API-key access, 24-hour caching, refresh rate-limit cost, and model-written output needing review are all disclosed.
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 long but every sentence carries distinct information: purpose, return shape, limits, async flow, and parameter behavior. It is front-loaded with the core purpose and structured so an agent can quickly extract the key invocation rules.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, so the description must explain both behavior and return shape. It supplies the output object, the pending/runId flow, cache behavior, rate limits, and the final paste-ready form, making it complete enough for correct invocation and interpretation.
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 value by explaining the rate-limit consequence of refresh, the collect-only behavior of runId, and the no-rate-limit-cost property of collecting a result.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: read a page and generate a schema.org JSON-LD block, then validate it. It clearly distinguishes this from a standalone validator by framing validation as a built-in step, and it is distinct from siblings like generate_llms_txt and validate_json_ld.
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 clear operational context: pass url to start, pass runId alone to collect a pending run, and use refresh only when the page changed because it costs a rate-limit slot. It does not explicitly name validate_json_ld as the alternative when JSON-LD already exists, so an explicit when-not-to-use statement is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate llms.txt and llms-full.txt for a site, following the llmstxt.org convention. Inventories the site from its robots.txt, sitemaps, and homepage links, then writes an index file and a full file with page content inlined. Deterministic: no model is involved, so two runs over an unchanged site produce the same bytes. Returns the file contents ready to write to disk.
Returns { ok, report: { siteName, llmsTxt, llmsFullTxt, pagesDiscovered, pagesIncluded, truncated }, cached, ageSeconds }. Limit: 10 runs per hour per IP. Allow up to 75s for a response. Free, no account, no API key.
Pass url to start a run. A slow run answers with { status: "pending", runId } instead of a result: call this same tool again with just that runId to collect it, as many times as it takes. Collecting costs no rate-limit slot.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | The page to run against. A bare domain like example.com is fine; https is assumed. Must be a public URL: anything behind a login, on a private network, or on localhost is refused. | |
| runId | No | Collect a run that answered with `{ status: "pending", runId }` instead of a result. Send the runId back on its own, with no url, and the same tool returns the finished result once the run is done. Costs no rate-limit slot. | |
| refresh | No | Skip the 24 hour cache and run again. Costs a rate-limit slot even when a cached result exists, so leave it off unless the page has changed. |
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 excellently. It discloses determinism, rate limits, 75s timeout, 24h caching, refresh cost, public-only URL restrictions, the async pending/collect protocol, truncation, and the exact return shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense yet every sentence earns its place: purpose first, then behavior, return shape, limits, and the async workflow. It is structured into scannable paragraphs with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity — async responses, caching, rate limits, and no output schema — the description is fully sufficient. It covers result fields, pending-run collection, timeouts, free access, and the conditions under which a run may be truncated. Nothing essential for correct invocation 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% and each parameter is already richly documented in the input schema. The description largely repeats this information rather than adding new parameter-level meaning. It adds a little workflow context around starting and polling runs, but not enough to lift meaningfully beyond the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Generate llms.txt and llms-full.txt for a site.' It explains what the tool does, the convention it follows, and the two-file output. This clearly distinguishes it from sibling tools like page_to_markdown or check_robots_txt_for_ai.
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 how-to guidance: pass `url` to start, use `runId` to poll, and leave `refresh` off unless content changed. It does not explicitly compare itself to sibling tools or state when not to use it, but the tool's unique purpose and invocation workflow are unmistakable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Hash text to an MD5 hex digest. Useful for checksums, cache keys, dedupe keys, and Gravatar-style identifiers. MD5 is broken for anything security-related: never use it for passwords or to verify authenticity.
Returns { md5, algorithm, bytes }. Limit: None. The work is local and costs nothing.. Allow up to 10s for a response. Free, no account, no API key.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The text to hash. Up to 1 MB of UTF-8. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full responsibility and does well: it discloses the return format ('Returns { md5, algorithm, bytes }'), clarifies limits ('Limit: None'), and notes it's 'Free, no account, no API key.' However, it contains a minor inconsistency with 'The work is local' yet 'Allow up to 10s for a response,' which could confuse—hence not a 5.
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 relatively compact but includes a couple of typos ('costs nothing..' with double period) and somewhat redundant notes about being free. It front-loads the core purpose and adds valuable context, but could be tightened without loss.
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 description covers all necessary context for a tool of this simplicity: purpose, use cases, security warning, return value structure, limits, and pricing/authentication requirements. It is complete given the small schema and lack of output schema.
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% (only 'text' parameter, described as 'The text to hash. Up to 1 MB of UTF-8'). The description adds no further semantics about the parameter beyond restating 'Hash text,' 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 opens with 'Hash text to an MD5 hex digest,' which clearly states what the tool does with a specific verb and resource. It further elaborates with use cases like checksums and cache keys, making its purpose unmistakable. Though siblings are unrelated, the description's clarity stands independently.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool (checksums, cache keys, dedupe keys) and, crucially, when not to: 'MD5 is broken for anything security-related: never use it for passwords or to verify authenticity.' This provides clear usage boundaries and appropriate alternatives (though not naming other tools).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one web page and convert it to clean CommonMark, with the navigation, cookie banners, and boilerplate stripped out. Use this to read a page as text an agent can reason over, or to publish a .md copy of a page alongside the HTML.
Returns { ok, report: { markdown, title, description, wordCount, bytes, truncated, httpStatus }, cached, ageSeconds }. Limit: 10 runs per hour per IP. Allow up to 75s for a response. Free, no account, no API key.
Pass url to start a run. A slow run answers with { status: "pending", runId } instead of a result: call this same tool again with just that runId to collect it, as many times as it takes. Collecting costs no rate-limit slot.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | The page to run against. A bare domain like example.com is fine; https is assumed. Must be a public URL: anything behind a login, on a private network, or on localhost is refused. | |
| runId | No | Collect a run that answered with `{ status: "pending", runId }` instead of a result. Send the runId back on its own, with no url, and the same tool returns the finished result once the run is done. Costs no rate-limit slot. | |
| refresh | No | Skip the 24 hour cache and run again. Costs a rate-limit slot even when a cached result exists, so leave it off unless the page has changed. |
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 rate limit (10 runs/hour/IP), timeout (75s), caching (24h via refresh), authentication requirements (free, no account), URL restrictions (public only), and the async pending/runId pattern. It also warns that collecting a pending run costs no rate-limit slot, and the return object exposes a truncated flag, hinting at partial results.
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 compact yet complete. It front-loads the core purpose in the first sentence, then logically groups return values, operational limits, and the async run/collect workflow. Every sentence contributes unique information, and the final paragraph gives a concrete usage template without 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 tool with no output schema and non-trivial async behavior, the description is remarkably complete. It covers return fields, error-prone conditions (private URLs, login walls), rate limiting, caching behavior, polling, timeout, and cost differentiation between starting and collecting runs. An agent has all necessary operational details to invoke and consume this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all three parameters in detail. The description reinforces the relationship between url and runId by describing the polling flow, but this information already exists in the schema's runId description (send runId on its own, costs no slot). Thus the description adds little beyond the schema, matching the baseline of 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 opens with a specific verb and resource: 'Fetch one web page and convert it to clean CommonMark,' and elaborates what 'clean' means by naming stripped elements (navigation, cookie banners, boilerplate). It states two distinct use cases ('read a page as text... publish a .md copy'), which makes the tool's role unmistakable and distinguishes it from siblings like capture_full_page_screenshot.
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 tells the agent when to use this tool ('read a page as text an agent can reason over, or to publish a .md copy') and explains the async workflow (pass url, get pending/runId, poll with runId). It also advises when to leave refresh off. It does not explicitly name alternatives or state when not to use the tool, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the structured data already on a page and check it against Schema.org and what search engines actually accept. Reports every JSON-LD block found, the type of each, and the errors and warnings per block.
Returns { ok, report: { blockCount, invalidBlockCount, declaredTypes[], eligibility[], categories[], findings[] } }. Limit: 10 runs per hour per IP. Allow up to 75s for a response. Free, no account, no API key.
Pass url to start a run. A slow run answers with { status: "pending", runId } instead of a result: call this same tool again with just that runId to collect it, as many times as it takes. Collecting costs no rate-limit slot.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | The page to run against. A bare domain like example.com is fine; https is assumed. Must be a public URL: anything behind a login, on a private network, or on localhost is refused. | |
| runId | No | Collect a run that answered with `{ status: "pending", runId }` instead of a result. Send the runId back on its own, with no url, and the same tool returns the finished result once the run is done. Costs no rate-limit slot. | |
| refresh | No | Skip the 24 hour cache and run again. Costs a rate-limit slot even when a cached result exists, so leave it off unless the page has changed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and succeeds: it discloses the 10-runs/hour rate limit, up-to-75s latency, 24-hour cache with refresh cost, free/no-account/no-API-key status, the async pending/runId pattern, and that collection costs no rate-limit slot. This is unusually complete behavioral disclosure.
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?
About 150 words, every sentence earns its place. The core purpose is front-loaded, followed by the return shape, then limits, then the workflow. Dense but not verbose; the async behavior requires this much explanation.
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 high-complexity async tool with no output schema and no annotations, the description is complete: it covers return values for both success and pending cases, rate limits, timeouts, caching, and the polling workflow. Nothing an agent needs to call and collect results 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 documents url, runId, and refresh in detail. The description reinforces the relationship between url and runId in the async flow, but adds no parameter syntax or format meaning 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 names a specific verb and resource ('Read the structured data already on a page and check it against Schema.org'), then states the output granularity (blocks, types, errors, warnings). This clearly distinguishes it from the sibling generate_json_ld, which creates schema rather than validating it.
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 strong operational guidance: how to start a run with url, how to collect pending results with runId, and when to use refresh (skip cache only if page changed). However, it never explicitly contrasts with alternatives like generate_json_ld or page_to_markdown, leaving the when-not-to-use case implicit.
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.
capture_full_page_screenshot2 fields changedInput schema / properties / runIdAdded value: +{
+ "description": "Collect a run that answered with `{ status: \"pending\", runId }` instead of a result. Send the runId back on its own, with no url, and the same tool returns the finished result once the run is done. Costs no rate-limit slot.",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "url"
-]New value: +[]check_ai_visibility2 fields changedInput schema / properties / runIdAdded value: +{
+ "description": "Collect a run that answered with `{ status: \"pending\", runId }` instead of a result. Send the runId back on its own, with no url, and the same tool returns the finished result once the run is done. Costs no rate-limit slot.",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "url"
-]New value: +[]check_robots_txt_for_ai2 fields changedInput schema / properties / runIdAdded value: +{
+ "description": "Collect a run that answered with `{ status: \"pending\", runId }` instead of a result. Send the runId back on its own, with no url, and the same tool returns the finished result once the run is done. Costs no rate-limit slot.",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "url"
-]New value: +[]check_social_preview2 fields changedInput schema / properties / runIdAdded value: +{
+ "description": "Collect a run that answered with `{ status: \"pending\", runId }` instead of a result. Send the runId back on its own, with no url, and the same tool returns the finished result once the run is done. Costs no rate-limit slot.",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "url"
-]New value: +[]generate_alt_text2 fields changedInput schema / properties / runIdAdded value: +{
+ "description": "Collect a run that answered with `{ status: \"pending\", runId }` instead of a result. Send the runId back on its own, with no url, and the same tool returns the finished result once the run is done. Costs no rate-limit slot.",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "url"
-]New value: +[]generate_json_ld2 fields changedInput schema / properties / runIdAdded value: +{
+ "description": "Collect a run that answered with `{ status: \"pending\", runId }` instead of a result. Send the runId back on its own, with no url, and the same tool returns the finished result once the run is done. Costs no rate-limit slot.",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "url"
-]New value: +[]generate_llms_txt2 fields changedInput schema / properties / runIdAdded value: +{
+ "description": "Collect a run that answered with `{ status: \"pending\", runId }` instead of a result. Send the runId back on its own, with no url, and the same tool returns the finished result once the run is done. Costs no rate-limit slot.",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "url"
-]New value: +[]page_to_markdown2 fields changedInput schema / properties / runIdAdded value: +{
+ "description": "Collect a run that answered with `{ status: \"pending\", runId }` instead of a result. Send the runId back on its own, with no url, and the same tool returns the finished result once the run is done. Costs no rate-limit slot.",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "url"
-]New value: +[]validate_json_ld2 fields changedInput schema / properties / runIdAdded value: +{
+ "description": "Collect a run that answered with `{ status: \"pending\", runId }` instead of a result. Send the runId back on its own, with no url, and the same tool returns the finished result once the run is done. Costs no rate-limit slot.",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "url"
-]New value: +[]build_utm_urlcapture_full_page_screenshotcheck_ai_visibilitycheck_faviconcheck_robots_txt_for_aicheck_social_previewdetect_tech_stackgenerate_alt_textgenerate_json_ldgenerate_llms_txthash_md5page_to_markdownvalidate_json_ldClaiming 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!
Screenshot, diff, audit and sitemap-capture any web page — 5 MCP tools for AI agents.
Security, SEO and AI-visibility scanner for web apps · free scans and focused checks via MCP.
Website QA for your coding agent: audit SEO, performance, security, accessibility over MCP.
7 free tools: MCP health scans, AI-readiness scores, llms.txt generator, glossary, indexes.
Add one secure layer between your agents and this server.
Each tool targets a clearly distinct resource or output, and the only near-overlapping pairs (check_ai_visibility vs check_robots_txt_for_ai, generate_json_ld vs validate_json_ld) explicitly describe their boundaries. Descriptions cross-reference each other to prevent misselection.
Tool names follow a consistent lowercase snake_case verb_noun pattern, with build_, capture_, check_, detect_, generate_, and validate_ prefixes. The few multi-word names like page_to_markdown still read predictably and match the overall style.
13 tools is within the ideal range for a web/SEO utility server and each tool earns its place by providing a distinct analysis or generation capability. The count is large enough to feel substantive but not so large as to overwhelm an agent.
The set covers the main declared workflows well: AI crawler access, social previews, structured data, favicons, alt text, llms.txt, and page conversion. Some adjacent webmaster features like meta title/description auditing or sitemap validation are absent, but no existing workflow ends in a dead end.
