19 free website QA and AI-visibility tools. Remote HTTP MCP, no account, no API key.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.5/5 across 13 of 13 tools scored. Lowest: 3.9/5.
Each tool has a distinct, specific purpose. Overlapping check tools (AI visibility vs robots) are explicitly differentiated with clear guidance on when to use each. Generate vs validate JSON-LD, screenshot vs markdown conversion, and other similar-sounding tools are all clearly separated by their descriptions.
Most tools follow the verb_noun pattern (build_, capture_, check_, detect_, generate_, hash_, validate_), but page_to_markdown breaks the convention with a noun-based name instead of a verb-noun form. This outlier creates a minor inconsistency in an otherwise predictable naming scheme.
13 tools is well within the recommended 3-15 range. Each tool provides a distinct, useful capability for web analysis, content generation, or conversion, and none feel redundant. The count is well-scoped for a 'free tools' server without being overwhelming.
The set covers a broad spectrum of web utilities: URL construction, screenshots, various checks (favicon, robots, social preview, AI visibility), tech detection, content generation (alt text, JSON-LD, llms.txt), and text conversion (markdown, hashing). Minor gaps such as a link checker or performance test exist, but the overall coverage is comprehensive for its intended audience.
build_utm_urlUTM BuilderAInspectBuild 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_full_page_screenshotFull Page ScreenshotAInspectCapture 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.
| 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, the description carries full burden and does well: discloses scrolling for lazy loading, signed link expiry (~24h), no watermark, no height cap, login/private network refusal, rate limits, timeout, output fields, and cost of refresh.
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?
Description is comprehensive but not verbose; it packs crucial operational details (cache, expiry, rate limits) and return fields into a compact paragraph with a clear second paragraph for output. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all essential context: what it does, limitations (no login, public only), behavioral specifics (scrolling, lazy-load), data lifetime, rate limit, timeout, and output shape. Without annotations, the description fully compensates.
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?
Both parameters have thorough descriptions. 'url' clarifies a bare domain is fine, https assumed, and constraints (public URL, no login/private/localhost). 'refresh' explains cache behavior and rate-limit cost. Schema covers 100% of parameters.
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 what the tool does: captures a full-height PNG in a real headless browser with scrolling for lazy-loaded content. This is specific and distinguishes it from siblings like page_to_markdown (converts to text) and check_social_preview (preview images).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: use for full-page screenshots, can't capture behind login, free/no account. But doesn't explicitly contrast with sibling tools (e.g., check_social_preview for social previews) or state when NOT to use it beyond the constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_ai_visibilityAI Visibility CheckerAInspectCheck 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.
| 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?
The description transparently lists what the tool checks (robots.txt, firewall, JavaScript, llms.txt, headings, structured data, author identity) and what it returns (score, grade, categories, findings with justification and fix, cache info). It mentions the rate limit and that it's free, but doesn't explicitly state that it performs read-only HTTP requests. Given it's a checker, this is implied, but not stated outright.
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 thorough but slightly repetitive; the return details are mentioned twice in slightly different wording. However, it is well-structured with clear sections and no filler. Minor redundancy prevents a perfect score, but it remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex, and the description provides enough context: purpose, checks performed, output structure, usage scenarios, and operational constraints (caching, rate limit). It doesn't explain each check in depth, but that's beyond the required scope. The description is sufficient for a user to understand when and how to use 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?
Both parameters (url and refresh) are described with substantial detail. The url parameter explains accepted formats, default scheme, and restrictions (public URL, no private networks or localhost). The refresh parameter clarifies its purpose, the cost in rate-limit terms, and when to use it. This fully covers the semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's core function: checking whether major AI assistants can reach, read, and cite a web page. It enumerates the specific checks performed and explicitly contrasts it with the sibling tool check_robots_txt_for_ai, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides direct guidance on when to use this tool versus the alternative ('Use this for a whole-page verdict; use check_robots_txt_for_ai when the question is only about crawler access'). It also explains the caching and rate-limit behavior, including advice on when to use the refresh parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_faviconFavicon CheckerAInspectCheck 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.
check_robots_txt_for_airobots.txt AI CheckerAInspectTest 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.
| 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, the description carries full responsibility and delivers. It discloses the firewall test, the response format (including cached and ageSeconds), rate limits (10 per hour per IP), timeout (up to 75s), and that it requires no account. This goes well beyond basic behavior and gives the agent critical operational 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?
The description is front-loaded with the core purpose and structured into three sentences, but it is somewhat dense with the crawler list and return format. Every sentence earns its place, providing functional, relational, and operational info without fluff. Slightly long but justifiably so for a tool with no output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and only two parameters, the description provides a comprehensive picture: what the tool does, what it returns (including the report structure), its performance constraints, and its access model. It covers the operational details an agent needs to invoke and interpret the tool correctly, leaving no major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100%, so the baseline is 3. The description does not add meaning beyond the schema for the url parameter (though it reinforces public-only URLs) and does not mention refresh explicitly, but the schema already provides clear descriptions for both parameters. The description's added context about caching and rate limits is helpful but not tied directly to parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Test') with a specific resource ('a site's robots.txt against every AI crawler that matters'), and clearly states the outputs ('which are allowed, which are blocked, and which rule decided it'). It also explicitly distinguishes from a sibling tool ('This is the access-scoped view of check_ai_visibility'), making the tool's unique role clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides strong contextual guidance: it mentions the access-scoped relationship to check_ai_visibility, the firewall test, caching behavior, rate limits, and free status. However, it does not explicitly state when to choose this tool versus check_ai_visibility or exclude alternatives beyond the 'access-scoped view' phrase, leaving some nuance to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_social_previewSocial Preview CheckerAInspectRead 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.
| 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?
Without annotations, the description fully discloses operational behavior: rate limit ('10 runs per hour per IP'), timeout ('up to 75s'), cost of refresh, caching, assumptions (https, public URLs), and accessibility ('Free, no account, no API key'). This exceeds minimal disclosure by covering errors and constraints.
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 packed with useful information but remains readable, using two paragraphs to separate function from constraints. It slightly loads extra details (free, no key) but each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description thoroughly explains return structure ({ ok, report: { previews[], tags, summary, findings[] }, cached, ageSeconds }) and covers edge cases (private networks, login, caching). It sets accurate expectations 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%, but the description adds critical semantics: URL format acceptance ('bare domain... https is assumed'), public visibility requirements, and refresh's rate-limit cost. These details go beyond schema types and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: '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.' This specific verb+resource+outcome distinctively separates it from sibling tools like check_ai_visibility 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?
While it doesn't explicitly mention alternative tools, the description provides implicit usage context by detailing the function (checking social previews) and constraints (rate limit, public URLs, refresh behavior). It implies when to use but lacks explicit 'use instead of X' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
detect_tech_stackTech Stack DetectorAInspectIdentify 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.
generate_alt_textAlt Text GeneratorAInspectFind 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.
| 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?
No annotations exist, so the description carries full burden. It discloses many behaviors: uses vision model, rate limits (10 runs/hour), 24h cache, 90s response time, free/no auth, drafts for human review, and explains skippedReason. This is exceptional transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with purpose, and each sentence adds value (limits, output, behavior, cost). No 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 there is no output schema, the description fully explains the return structure (images[], fields, counts, model), operational constraints (10 runs/hour, 24h cache, 90s timeout), and auth requirements (no account). It is complete for an agent to decide and use 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 baseline 3. The description adds some context (e.g., 'a bare domain is fine' is in schema) but doesn't significantly enhance beyond the schema's already detailed parameter descriptions. The description mentions 'Must be a public URL' which is also in schema. So minimal added value.
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 action: 'draft alt text for the ones that need it' for any public URL. It clearly differentiates from sibling tools (screenshot, markdown, robots.txt) by focusing on image alt text generation. The verb+resource is precise.
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 clearly defines when to use (for generating alt text on public pages) and gives constraints (public URL only, max 10 images, cache behavior). It does not explicitly name alternatives, but the context is clear enough. It says when not to use (private/logged-in pages), which is good.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_json_ldJSON-LD GeneratorAInspectRead 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.
| 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, the description carries the full burden. It discloses rate limits (10 runs/hour/IP), response time (up to 75s), cost (free), and that the markup is model-written and should be reviewed. It does not mention data handling or failure modes, but covers key operational behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two paragraphs. The first sentence efficiently states purpose, then adds useful details like the return structure and operational limits. It is slightly verbose but not wasteful; the return object breakdown adds value 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?
Given no annotations and no output schema, the description covers the essential aspects: generation, validation, output format, constraints, and error handling (via schema). It could mention explicit failure scenarios, but overall it is sufficient for an agent to understand the tool's behavior and output.
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 the schema already explains both parameters (url and refresh) in detail, including constraints and rate-limit impact. The tool description adds no extra parameter-specific meaning 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 clearly states the primary action: '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.' This uses a specific verb (write/validate) and resource (page/JSON-LD block), and distinguishes from the sibling validate_json_ld by emphasizing generation followed by validation.
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 the tool is for generating JSON-LD and mentions validation, but does not explicitly contrast with the dedicated validate_json_ld sibling. It gives context like 'model-written' and 'should be reviewed before published,' but lacks clear when-to-use vs. when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_llms_txtllms.txt GeneratorAInspectGenerate 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.
| 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, the description carries the full burden, and it does so thoroughly. It discloses determinism (no model, same bytes), the return structure ({ ok, report: {...}, cached, ageSeconds }), rate limits, timeout, and the fact that it requires a public URL. It also describes the inventorying process and what the output contains, giving a complete behavioral picture.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a dense single paragraph, but it is well-structured: it starts with the purpose, then explains behavior, return value, and limits. It includes essential information without excessive verbosity, though it could be slightly more scannable with bullets, but it remains concise and informative.
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, the description fully specifies the return object and its fields. It covers all aspects: parameters, side effects (cache behavior), rate limits, timeout, and the public URL requirement. Sibling tools are unrelated, so there is no ambiguity. The description is exceptionally complete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers both parameters (URL and refresh), and the description adds meaningful context beyond it: the URL must be public (refusing login/private/localhost), and refresh skips the 24-hour cache but costs a rate-limit slot. This adds practical semantics that the schema alone does not convey.
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 clearly that the tool generates llms.txt and llms-full.txt for a site, following the llmstxt.org convention. It specifies the resource and the verb 'generate', and it is distinct from all sibling tools, which are unrelated (screenshots, social previews, etc.).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it explains the deterministic process (no model involved), mentions the 10 runs/hour rate limit, the 75-second timeout, and that it's free without an account. However, it does not explicitly state when to prefer this over alternatives, though given the unique nature among siblings, that's not a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hash_md5MD5 Hash GeneratorAInspectHash 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.
page_to_markdownMarkdown for AgentsAInspectFetch 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.
| 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, the description carries the full burden and does so admirably. It discloses the transformation behavior (boilerplate stripping), the exact return shape, the rate limit ('10 runs per hour per IP'), the expected latency ('up to 75s'), and the auth requirement ('Free, no account, no API key').
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 earns its place: purpose, use cases, return signature, rate limit, latency, and auth are packed into a compact two-paragraph structure. The description is front-loaded with the core verb and output, and there is zero filler.
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 has no output schema and no annotations, yet the description fully compensates by specifying the return shape, operational constraints, auth-free access, and the page-cleaning behavior. This is complete for a simple fetch-and-convert tool; the only minor omission is explicit error scenarios, but httpStatus partially covers that.
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 no new parameter-level detail beyond what the schema already provides for 'url' and 'refresh'; it only offers context like rate limits that relate to API usage rather than to the parameters themselves.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action: 'Fetch one web page and convert it to clean CommonMark', naming the resource (web page) and the output format. It also details what gets stripped (navigation, cookie banners, boilerplate), which clearly distinguishes it from the sibling screenshot and SEO tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit use cases: 'read a page as text an agent can reason over, or to publish a .md copy of a page alongside the HTML.' This provides clear context for when to invoke the tool, though it does not explicitly name alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_json_ldJSON-LD ValidatorAInspectRead 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.
| 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. It discloses rate limits ('10 runs per hour per IP'), response time ('up to 75s'), auth requirements ('Free, no account, no API key'), and the read-only nature ('Read the structured data'). It does not detail error behaviors for unreachable pages, but this is adequate for a validation 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 two concise paragraphs: the first states purpose and output; the second lists limits and return shape. Every sentence provides useful information, no fluff. Purpose is front-loaded in the first sentence.
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 has no output schema, but the description compensates by outlining the return object fields ({ ok, report: { ... } }). It covers rate limiting, timeout, and API key requirements. Some output fields like eligibility and categories are not explained, but the names are reasonably self-explanatory. Overall complete for a moderate-complexity validation 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 description coverage is 100%, and both parameters (url, refresh) are already well-documented in the schema. The description repeats that the limit applies to runs but adds no new parameter-level 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 uses specific verbs ('Read', 'check') and names the exact resource ('structured data already on a page', 'Schema.org', 'search engines'). It clearly distinguishes itself from sibling generate_json_ld by focusing on validation of existing markup rather than creation.
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 there is existing JSON-LD on a page that needs validation. It provides clear context (validates against Schema.org and search engine acceptance) but does not explicitly name alternatives or say 'use generate_json_ld for creation'. No exclusions are stated beyond schema-level URL restrictions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
