The observation layer for AI agents. Outrings provides deterministic web intelligence through MCP, transforming websites into structured, evidence-backed signals that AI systems can inspect and trust.
Most tools have clearly distinct purposes: full audit vs. single-category check vs. score-only vs. comparison vs. badge embed vs. inventory vs. change tracking. However, check_ai_visibility overlaps with check_category's 'ai' area, potentially causing confusion for agents. Descriptions help delineate but the overlap is notable.
Seven of eight tools follow a consistent verb_noun snake_case pattern (audit_website, check_ai_visibility, check_category, compare_websites, get_badge_embed, get_score, get_site_inventory). Only 'what_changed' breaks the pattern by using a question phrase. Otherwise naming is uniform and predictable.
8 tools is well-scoped for a website intelligence server. Each tool addresses a distinct need (full audit, narrow check, AI visibility, comparison, score, badge, inventory, diff tracking) without being excessive or sparse. The set feels complete for its domain.
The tool surface covers the full lifecycle of analyzing a website: comprehensive audit (audit_website), granular category checks (check_category, check_ai_visibility), score retrieval (get_score), comparison (compare_websites), change monitoring (what_changed), asset inventory (get_site_inventory), and even a sharing artifact (get_badge_embed). No obvious dead ends or missing operations for the stated purpose.
Run the full 200-check audit of a website and return the overall score, every category score, and the ranked list of what to fix first. Use this when the user asks a broad question about a site — "how is my website", "what is wrong with it", "is this site any good" — or when you need grounding before advising on changes. Takes roughly 2-8 seconds. If the user only cares about one area, check_category is faster and returns less.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The website to inspect. A bare domain works — "example.com" is treated as https://example.com. | |
| detail | No | summary: scores plus priority actions (default, best for most answers). markdown: the whole report as prose written for a model to read. full: the complete JSON including every check, link, script and email found. | summary |
| Name | Required | Description |
|---|---|---|
| url | Yes | The URL that was measured, after redirects. |
| grade | Yes | Letter grade from A+ to F. |
| score | Yes | Overall score out of 100. |
| counts | Yes | Checks by status. The last five are undetermined states and are never scored as passes. |
| categories | Yes | Every category with its own score. |
| undetermined | No | Check ids that reached no verdict. Never treat these as passes. |
| priorityActions | No | Findings ranked by points recovered per unit of effort. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes beyond the provided annotations by adding useful behavioral context like the expected response time ('Takes roughly 2-8 seconds') and a note about using the tool as 'grounding' before advising on changes. It doesn't contradict the read-only and idempotent annotations.
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?
Perfectly sized. Three sentences, each with a distinct purpose: what the tool does, when to use it, and what to expect in terms of performance. Every sentence earns its place, and the information is structured logically.
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 is perfectly complete for a tool with only two simple parameters and no complex return types. It thoughtfully covers the functionality, provides examples for the parameter, and explicitly acknowledges the existence of a sibling tool without going into unnecessary depth about 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?
While the schema already covers most of the descriptive burden with 100% coverage, the description adds excellent VALUE BEYOND that, particularly for the 'url' parameter with the real-world example that a bare domain is treated as https. This proactive clarification is exactly what a helper should do.
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 is exceptionally clear with a strong verb and resource ('Run the full 200-check audit of a website'). It explicitly distinguishes itself from siblings by mentioning the use case for broad questions and specifically names the alternative 'check_category' for narrower queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Offers explicit trigger phrases and when-to-use guidance. It also provides a clear alternative ('If the user only cares about one area, check_category is faster') and notes the trade-off in terms of speed and output size, which is invaluable for an agent to select the right tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Measures technical crawler access and the page signals that affect whether an AI system can retrieve and parse a site. Reports, per crawler, whether GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-SearchBot, Claude-User, PerplexityBot, Google-Extended, Googlebot, Bingbot, Applebot-Extended and CCBot are allowed or blocked, naming the exact robots.txt rule responsible. Also checks whether content is served in HTML rather than requiring JavaScript, whether structured data is present and valid, and whether llms.txt exists. It does NOT determine whether an assistant will rank, select, mention or cite the page: access is a precondition for citation, not a cause of it, and the crawlers serve different purposes — for OpenAI, OAI-SearchBot governs eligibility for ChatGPT search while GPTBot relates to model training. Use this to rule out or confirm a technical blocker, and say plainly that ranking and selection are outside what any measurement here can establish.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The website to inspect. A bare domain works — "example.com" is treated as https://example.com. |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| name | No | |
| score | Yes | Technical retrievability only. Not a prediction of citation. |
| counts | No | Checks by status. The last five are undetermined states and are never scored as passes. |
| category | Yes | |
| problems | No | Blocked crawlers and missing signals, each naming the rule responsible. |
| passingCount | No | |
| undetermined | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds substantial behavioral nuance: it lists all 11 crawlers inspected, explains that crawlers serve different purposes (e.g., OAI-SearchBot vs GPTBot), and explicitly discloses the interpretive limitation that technical access is a precondition for citation, not a cause of it. This goes well beyond the annotation flags.
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: the crawler enumeration, the checks performed, and the explicit boundary on conclusions are all relevant. It is appropriately sized for a tool of this breadth, with the caveat clearly separated as 'It does NOT.'
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—multiple checks across 11 crawlers, structured data validation, and llms.txt detection—the description covers purpose, scope, and interpretation thoroughly. It even sets expectations about what cannot be inferred. Since an output schema exists, return values need no additional explanation. Nothing operationally important 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?
The single parameter url is fully documented in the schema, including bare-domain normalization ('example.com' → https://example.com). The description adds no extra parameter-level meaning beyond that, so the schema carries the burden; per the rubric, the high schema coverage baseline of 3 applies.
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-oriented statement: 'Measures technical crawler access and the page signals that affect whether an AI system can retrieve and parse a site.' It then enumerates the exact checks (per-crawler robots.txt rules, HTML vs JS, structured data, llms.txt) and explicitly distinguishes the tool from ranking/selection concerns, clearly differentiating it from sibling tools like audit_website or get_score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: 'Use this to rule out or confirm a technical blocker.' It also provides a strong when-not boundary by stating it does not determine ranking, selection, mention, or citation. It does not name an alternative sibling tool for those ranking questions, so it lacks fully explicit alternatives, but the contextual guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect a single area and return its verdict, the checks that failed, why each matters and how to fix it. Categories: seo, ai (whether AI crawlers and answer engines can read and cite the site), security (headers, exposure, secrets in source), privacy, tls (certificate and protocol), dns (records, SPF, DMARC, CAA), a11y (accessibility), content, slop (AI-generated-filler signals), design, infra, tech, credibility, correlation (does the page deliver what its title promises), faq, discoverability, local, contact. Use this rather than audit_website when the question is narrow — "is my site secure", "why is my SEO bad", "can ChatGPT see my site".
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The website to inspect. A bare domain works — "example.com" is treated as https://example.com. | |
| category | Yes | Which area to inspect. | |
| failing_only | No | Return only problems, omitting checks that passed. |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| name | No | Human-readable category name. |
| score | Yes | |
| counts | No | Checks by status. The last five are undetermined states and are never scored as passes. |
| category | Yes | The category id that was inspected. |
| problems | No | Checks that failed or warned, in check order. |
| passingCount | No | |
| undetermined | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds transparency about the output structure (verdict, checks, why, how to fix), which complements the annotations without contradicting them.
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 moderately verbose due to the category list, but it is well-organized with clear explanations. It avoids unnecessary fluff and stays focused on purpose, usage, and output, making it appropriately concise for the complexity.
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 comprehensive schema and annotations, the description provides sufficient context. It explains what the tool does, when to use it, and what it returns. The absence of output schema details is acceptable since the description already outlines the return content.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers each parameter's meaning (url, category, failing_only). The description enriches the category parameter by explaining each enumerated value (e.g., 'ai' as AI crawlers and answer engines), improving semantic clarity beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it inspects a single area and returns verdicts, failed checks, reasons, and fixes. It explicitly distinguishes itself from audit_website for narrow questions, making the purpose and scope 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?
Provides explicit guidance on when to use this tool over audit_website (narrow questions) and gives concrete examples ('is my site secure', 'why is my SEO bad'). It also enumerates all categories, facilitating correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Score two to four sites and return them ranked, with the category gaps between them. Use it for "how do I compare to my competitors" or "which of these is better built". Each site is a real audit, so this takes several seconds per URL.
| Name | Required | Description | Default |
|---|---|---|---|
| urls | Yes | The sites to compare. Bare domains are fine. |
| Name | Required | Description |
|---|---|---|
| ranked | No | The same sites, highest score first. |
| results | Yes | One entry per URL, in the order given. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, but the description adds valuable behavioral context: 'Each site is a real audit, so this takes several seconds per URL.' This warns about latency and conveys that the operation performs real work. It also explains that output is ranked with category gaps, which is beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action and output, followed by use cases and a performance note. No filler or redundancy. Every 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 the tool's complexity (multiple URLs, ranking, output schema exists), the description is complete: it states input scope (two to four sites), output behavior (ranked with category gaps), and performance characteristics (several seconds per URL). The output schema covers return value structure, so no further detail is needed.
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 provides 100% coverage for the single 'urls' parameter, already describing it as 'The sites to compare. Bare domains are fine.' The description reinforces the two-to-four site range but does not add new semantic details beyond the schema. With high schema coverage, the baseline is 3, and there is no additional value from the 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 clearly states the tool's function: 'Score two to four sites and return them ranked, with the category gaps between them.' It uses a specific verb ('score' and 'rank') and resource ('sites'), and the use cases ('how do I compare to my competitors' or 'which of these is better built') make the purpose unmistakable. This also distinguishes it from sibling audit_website, which likely handles a single site.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: 'Use it for "how do I compare to my competitors" or "which of these is better built".' This is clear context, but it does not explicitly mention alternatives or when not to use it (e.g., for a single-site audit), which would warrant a 5. The sibling list suggests audit_website as an alternative, but the description doesn't reference it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Produce the HTML (and Markdown) for a badge the site owner can paste into their footer or README. It renders a live SVG showing a real measured score that refreshes every six hours and links through to the full audit, so a visitor can verify it. Use this when someone wants to display that their site was checked.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The website to inspect. A bare domain works — "example.com" is treated as https://example.com. | |
| style | No | Badge shape. score shows the number, verified shows a tick and wordmark, shield is the flat two-part style used by build badges, compact is the smallest. | score |
| theme | No | Colour scheme to match the page it will sit on. | light |
| metric | No | Which score the badge displays. Use overall unless the site wants to highlight one category. | overall |
| Name | Required | Description |
|---|---|---|
| host | Yes | |
| html | Yes | Ready-to-paste anchor and image markup. |
| linkUrl | No | Full report the badge links to, so a visitor can verify the score. |
| imageUrl | Yes | Live SVG badge; re-renders from a real audit every six hours. |
| markdown | No | The same badge for a README. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnly, idempotent, non-destructive), the description adds that the badge is a live SVG that refreshes every six hours and links to the full audit, which is valuable for setting user expectations about behavior. This is meaningful additional context without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences: the first front-loads the action and output, the second gives usage context. No filler or redundant phrasing, making it easy to parse quickly.
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 relatively simple tool, the description covers the output format, live behavior, refresh rate, linkage, and usage trigger. With a full schema and output schema present, it doesn't need to explain return values further. It could mention limitations (e.g., public accessibility requirement) but is otherwise 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?
Input schema covers 100% of parameters with descriptive text for each (url, style, theme, metric). The description does not add parameter-specific semantics beyond the schema, so baseline 3 is appropriate for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it produces HTML (and Markdown) for an embeddable verification badge, specifying the output format and target user (site owner). This distinguishes it from sibling tools like get_score (which returns a numeric score) by focusing on the embeddable code artifact.
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 says 'Use this when someone wants to display that their site was checked,' providing a clear trigger condition. It does not explicitly mention alternatives or exclusions, but this context is sufficient to guide selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The cheapest useful call: overall score, letter grade and every category score, with no findings or prose. Use it when comparing sites, when the user only wants a number, or as a first step before deciding which category to look into.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The website to inspect. A bare domain works — "example.com" is treated as https://example.com. |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| grade | Yes | |
| score | Yes | Overall score out of 100. |
| auditedAt | No | |
| categories | Yes | Category id to score. Null where nothing was determinable. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds value by specifying the return content (overall score, letter grade, category scores) and the 'no findings or prose' limitation, plus the efficiency angle ('cheapest useful call'). No contradictions with annotations.
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 tight sentences that lead with the core value proposition ('cheapest useful call') and return details, then provide usage guidance. No filler or repetitive content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one well-documented parameter, an output schema (indicated), and strong annotations, the description covers the essentials: what it returns, when to use, and how it differs from heavier options. It gives enough context for an agent to decide and 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?
The input schema has 100% coverage and adequately describes the url parameter, including the bare domain handling. The description does not add parameter-specific information, but since the schema is complete, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns an overall score, letter grade, and every category score, with no findings or prose. It distinguishes from siblings like check_category (which would provide category details) and compare_websites by emphasizing it's the 'cheapest useful call' and a first step before going deeper.
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 lists use cases: comparing sites, when the user only wants a number, or as a first step before deciding which category to look into. It also hints at when not to use it ('with no findings or prose'), implying that for detailed findings one should use other tools, though it doesn't name them directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a complete inventory of what the Outrings collector observed on a page — not a sample of it — for one kind of thing: internal links, external links, sitemap URLs, email addresses, scripts, images, forms, iframes, stylesheets or API endpoints referenced. The collector does not execute JavaScript, so this is everything present in the served HTML and the responses it fetched, which is not necessarily everything a real browser would end up loading at runtime. Use it for "what third-party scripts am I loading", "which email addresses are exposed on my site", "how many images are missing alt text", "what does my page link out to".
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The website to inspect. A bare domain works — "example.com" is treated as https://example.com. | |
| limit | No | Cap the rows returned. The total count is always reported. | |
| inventory | Yes | Which listing to return. internalLinks and externalLinks are URLs; externalDomains is the deduplicated hosts they point at; endpoints are API paths found in scripts; discovered are paths seen in sitemaps and robots.txt; exposedProbe is the result of probing commonly exposed paths. |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| rows | No | Shape depends on the inventory: a list of URLs or strings, or an object keyed by host with counts. |
| total | Yes | Rows observed, before any limit. |
| returned | No | Rows in this response. |
| inventory | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, openWorld, idempotent, non-destructive), the description adds valuable behavioral context: the collector does not execute JavaScript, results are based on served HTML and fetched responses, and the inventory is complete rather than sampled. This meaningfully clarifies the tool's limitations and output fidelity.
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 three well-structured sentences: a precise statement of what it returns, an important caveat about JavaScript, and concrete use cases. No sentence is wasted, and the most important information is front-loaded.
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 an output schema is present and annotations already cover safety and world-openness, the description provides the remaining essential context: the exact inventory categories, the non-JavaScript limitation, and typical use cases. It is complete for an agent to select and call this tool appropriately.
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 does not add parameter-level detail beyond the schema, though it does reinforce the meaning of 'inventory' and the completeness guarantee. This is adequate but not exceptional.
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: 'Return a complete inventory of what the Outrings collector observed on a page.' It enumerates the exact kinds of inventory items, which directly maps to the inventory enum and clearly distinguishes this from a sample or aggregate view.
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 gives intended use cases with quotes ('what third-party scripts am I loading', 'which email addresses are exposed on my site', etc.). It also usefully cautions that JavaScript is not executed, implying it should not be used for runtime-loaded resources, though it does not name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Re-audit a site and report what moved since it was last checked: which findings are new, which were resolved, and how each category score shifted. Use it after the user says they fixed something, or to verify that a deployment did not regress anything. Returns comparable=false when the site has no earlier snapshot, which is not an error — it means history starts now. Unlike the other tools this one WRITES: it stores a durable snapshot of the result, because a comparison against history requires contributing to it. The baseline is the most recent retained snapshot and snapshots are kept at most once per site per six hours, so baselineAt may not be the deployment immediately before this one — read baselineAt rather than assuming it is the last change. Check comparable before attributing any score movement to the site: when the ruleset differed between the two measurements it is false, and the difference then includes a change in grading rather than a change in the website.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The website to inspect. A bare domain works — "example.com" is treated as https://example.com. |
| Name | Required | Description |
|---|---|---|
| to | No | One end of the comparison. |
| from | No | One end of the comparison. |
| host | Yes | |
| note | No | |
| score | No | Present instead of a diff when history starts with this call. |
| summary | No | |
| resolved | No | |
| worsened | No | |
| currentAt | No | |
| direction | No | |
| spanHours | No | |
| baselineAt | No | Timestamp of the snapshot being compared against. Snapshots are retained at most once per site per six hours, so this may not be the deployment immediately before the current one. |
| categories | No | |
| comparable | Yes | False when the two measurements used different rulesets, or when no earlier snapshot exists. Check this before attributing any score movement to the website. |
| scoreDelta | No | |
| newProblems | No | |
| schemaChanged | No | |
| partlyImproved | No | |
| rulesetChanged | No | Null when one snapshot predates version tracking. |
| comparabilityNote | No | Plain-language account of whether the two ends can be compared. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes far beyond the annotations (readOnlyHint=false, idempotentHint=false). It discloses the write behavior ("Unlike the other tools this one WRITES: it stores a durable snapshot"), the 6-hour snapshot retention limit, the baselineAt caveat, and the comparable flag semantics including the ruleset-difference scenario. This is exemplary transparency with no contradiction to annotations.
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 non-obvious, decision-relevant information (write behavior, snapshot rate limiting, baselineAt, comparable flag, ruleset caveat). It is front-loaded with purpose and usage before the caveats. Slightly dense, but the complexity of the tool justifies the length — no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists (covering return values), the description correctly focuses on behavioral semantics rather than return format. It covers write side-effects, snapshot retention policy, baseline ambiguity, and the critical comparable flag pitfall. For a tool with this complexity, nothing important appears 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 coverage is 100% — the input schema already fully documents the url parameter, including the bare-domain normalization ("example.com" treated as https://example.com). The description adds no parameter-specific meaning beyond the schema, so the baseline of 3 applies.
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+resource statement: "Re-audit a site and report what moved since it was last checked: which findings are new, which were resolved, and how each category score shifted." It clearly distinguishes from the sibling compare_websites (which compares two sites) by anchoring on comparison against past history rather than another site.
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 explicit trigger conditions: "Use it after the user says they fixed something, or to verify that a deployment did not regress anything." It also hints at differentiation from "the other tools" by noting this one writes. However, it does not explicitly name alternatives or state when NOT to use it (e.g., when comparing two arbitrary sites, which would be compare_websites).
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.
audit_website1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "categories": {
+ "description": "Every category with its own score.",
+ "items": {
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "score": {
+ "description": "Null when no check in the category reached a verdict.",
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "counts": {
+ "description": "Checks by status. The last five are undetermined states and are never scored as passes.",
+ "properties": {
+ "blocked": {
+ "type": "integer"
+ },
+ "fail": {
+ "type": "integer"
+ },
+ "inconclusive": {
+ "type": "integer"
+ },
+ "info": {
+ "type": "integer"
+ },
+ "na": {
+ "type": "integer"
+ },
+ "pass": {
+ "type": "integer"
+ },
+ "requires_browser": {
+ "type": "integer"
+ },
+ "timeout": {
+ "type": "integer"
+ },
+ "unknown": {
+ "type": "integer"
+ },
+ "warn": {
+ "type": "integer"
+ }
+ },
+ "type": "object"
+ },
+ "grade": {
+ "description": "Letter grade from A+ to F.",
+ "type": "string"
+ },
+ "priorityActions": {
+ "description": "Findings ranked by points recovered per unit of effort.",
+ "items": {
+ "properties": {
+ "action": {
+ "type": "string"
+ },
+ "category": {
+ "type": "string"
+ },
+ "pointsIfFixed": {
+ "description": "Arithmetic from the weights that produced the score, not an estimate.",
+ "type": "number"
+ },
+ "rank": {
+ "type": "integer"
+ },
+ "severity": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "score": {
+ "description": "Overall score out of 100.",
+ "type": "number"
+ },
+ "undetermined": {
+ "description": "Check ids that reached no verdict. Never treat these as passes.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "url": {
+ "description": "The URL that was measured, after redirects.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "url",
+ "score",
+ "grade",
+ "counts",
+ "categories"
+ ],
+ "type": "object"
+}check_ai_visibility1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "category": {
+ "const": "ai",
+ "type": "string"
+ },
+ "counts": {
+ "description": "Checks by status. The last five are undetermined states and are never scored as passes.",
+ "properties": {
+ "blocked": {
+ "type": "integer"
+ },
+ "fail": {
+ "type": "integer"
+ },
+ "inconclusive": {
+ "type": "integer"
+ },
+ "info": {
+ "type": "integer"
+ },
+ "na": {
+ "type": "integer"
+ },
+ "pass": {
+ "type": "integer"
+ },
+ "requires_browser": {
+ "type": "integer"
+ },
+ "timeout": {
+ "type": "integer"
+ },
+ "unknown": {
+ "type": "integer"
+ },
+ "warn": {
+ "type": "integer"
+ }
+ },
+ "type": "object"
+ },
+ "name": {
+ "type": "string"
+ },
+ "passingCount": {
+ "type": "integer"
+ },
+ "problems": {
+ "description": "Blocked crawlers and missing signals, each naming the rule responsible.",
+ "items": {
+ "properties": {
+ "fix": {
+ "type": "string"
+ },
+ "found": {
+ "description": "What was actually observed.",
+ "type": "string"
+ },
+ "id": {
+ "description": "Stable check id, e.g. sec.csp.",
+ "type": "string"
+ },
+ "severity": {
+ "enum": [
+ "low",
+ "medium",
+ "high",
+ "critical",
+ null
+ ],
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "status": {
+ "enum": [
+ "fail",
+ "warn"
+ ],
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "why": {
+ "description": "Why it matters. Our reading, not the observation.",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "score": {
+ "description": "Technical retrievability only. Not a prediction of citation.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "undetermined": {
+ "items": {
+ "description": "A check that reached no verdict. Report it as undetermined, never as a pass.",
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "reason": {
+ "enum": [
+ "unknown",
+ "blocked",
+ "timeout",
+ "inconclusive",
+ "requires_browser"
+ ],
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "url",
+ "category",
+ "score"
+ ],
+ "type": "object"
+}check_category1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "category": {
+ "description": "The category id that was inspected.",
+ "type": "string"
+ },
+ "counts": {
+ "description": "Checks by status. The last five are undetermined states and are never scored as passes.",
+ "properties": {
+ "blocked": {
+ "type": "integer"
+ },
+ "fail": {
+ "type": "integer"
+ },
+ "inconclusive": {
+ "type": "integer"
+ },
+ "info": {
+ "type": "integer"
+ },
+ "na": {
+ "type": "integer"
+ },
+ "pass": {
+ "type": "integer"
+ },
+ "requires_browser": {
+ "type": "integer"
+ },
+ "timeout": {
+ "type": "integer"
+ },
+ "unknown": {
+ "type": "integer"
+ },
+ "warn": {
+ "type": "integer"
+ }
+ },
+ "type": "object"
+ },
+ "name": {
+ "description": "Human-readable category name.",
+ "type": "string"
+ },
+ "passingCount": {
+ "type": "integer"
+ },
+ "problems": {
+ "description": "Checks that failed or warned, in check order.",
+ "items": {
+ "properties": {
+ "fix": {
+ "type": "string"
+ },
+ "found": {
+ "description": "What was actually observed.",
+ "type": "string"
+ },
+ "id": {
+ "description": "Stable check id, e.g. sec.csp.",
+ "type": "string"
+ },
+ "severity": {
+ "enum": [
+ "low",
+ "medium",
+ "high",
+ "critical",
+ null
+ ],
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "status": {
+ "enum": [
+ "fail",
+ "warn"
+ ],
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "why": {
+ "description": "Why it matters. Our reading, not the observation.",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "score": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "undetermined": {
+ "items": {
+ "description": "A check that reached no verdict. Report it as undetermined, never as a pass.",
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "reason": {
+ "enum": [
+ "unknown",
+ "blocked",
+ "timeout",
+ "inconclusive",
+ "requires_browser"
+ ],
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "url",
+ "category",
+ "score"
+ ],
+ "type": "object"
+}compare_websites1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "ranked": {
+ "description": "The same sites, highest score first.",
+ "items": {
+ "properties": {
+ "categories": {
+ "additionalProperties": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "type": "object"
+ },
+ "grade": {
+ "type": "string"
+ },
+ "score": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "results": {
+ "description": "One entry per URL, in the order given.",
+ "items": {
+ "properties": {
+ "categories": {
+ "additionalProperties": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "type": "object"
+ },
+ "grade": {
+ "type": "string"
+ },
+ "score": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "results"
+ ],
+ "type": "object"
+}get_badge_embed4 fields changedInput schema / properties / metric / descriptionAdded value: +"Which score the badge displays. Use overall unless the site wants to highlight one category."Input schema / properties / style / descriptionAdded value: +"Badge shape. score shows the number, verified shows a tick and wordmark, shield is the flat two-part style used by build badges, compact is the smallest."Input schema / properties / theme / descriptionAdded value: +"Colour scheme to match the page it will sit on."Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "host": {
+ "type": "string"
+ },
+ "html": {
+ "description": "Ready-to-paste anchor and image markup.",
+ "type": "string"
+ },
+ "imageUrl": {
+ "description": "Live SVG badge; re-renders from a real audit every six hours.",
+ "format": "uri",
+ "type": "string"
+ },
+ "linkUrl": {
+ "description": "Full report the badge links to, so a visitor can verify the score.",
+ "format": "uri",
+ "type": "string"
+ },
+ "markdown": {
+ "description": "The same badge for a README.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "host",
+ "imageUrl",
+ "html"
+ ],
+ "type": "object"
+}get_score1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "auditedAt": {
+ "format": "date-time",
+ "type": "string"
+ },
+ "categories": {
+ "additionalProperties": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "description": "Category id to score. Null where nothing was determinable.",
+ "type": "object"
+ },
+ "grade": {
+ "type": "string"
+ },
+ "score": {
+ "description": "Overall score out of 100.",
+ "type": "number"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "url",
+ "score",
+ "grade",
+ "categories"
+ ],
+ "type": "object"
+}get_site_inventory1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "inventory": {
+ "enum": [
+ "internalLinks",
+ "externalLinks",
+ "externalDomains",
+ "sitemapUrls",
+ "emails",
+ "phones",
+ "forms",
+ "scripts",
+ "iframes",
+ "styles",
+ "images",
+ "endpoints",
+ "icons",
+ "discovered",
+ "exposedProbe",
+ "crawledPages"
+ ],
+ "type": "string"
+ },
+ "returned": {
+ "description": "Rows in this response.",
+ "type": "integer"
+ },
+ "rows": {
+ "description": "Shape depends on the inventory: a list of URLs or strings, or an object keyed by host with counts.",
+ "oneOf": [
+ {
+ "items": true,
+ "type": "array"
+ },
+ {
+ "type": "object"
+ }
+ ]
+ },
+ "total": {
+ "description": "Rows observed, before any limit.",
+ "type": "integer"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "url",
+ "inventory",
+ "total"
+ ],
+ "type": "object"
+}what_changed1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "baselineAt": {
+ "description": "Timestamp of the snapshot being compared against. Snapshots are retained at most once per site per six hours, so this may not be the deployment immediately before the current one.",
+ "format": "date-time",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "categories": {
+ "items": {
+ "properties": {
+ "category": {
+ "type": "string"
+ },
+ "delta": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "from": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "note": {
+ "type": "string"
+ },
+ "to": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "comparabilityNote": {
+ "description": "Plain-language account of whether the two ends can be compared.",
+ "type": "string"
+ },
+ "comparable": {
+ "description": "False when the two measurements used different rulesets, or when no earlier snapshot exists. Check this before attributing any score movement to the website.",
+ "type": "boolean"
+ },
+ "currentAt": {
+ "format": "date-time",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "direction": {
+ "enum": [
+ "improved",
+ "regressed",
+ "stable",
+ "not-comparable",
+ "unknown"
+ ],
+ "type": "string"
+ },
+ "from": {
+ "description": "One end of the comparison.",
+ "properties": {
+ "at": {
+ "format": "date-time",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "grade": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "score": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "versions": {
+ "description": "Ruleset that produced this measurement. Null for snapshots written before version tracking existed.",
+ "properties": {
+ "collector": {
+ "type": "string"
+ },
+ "ruleset": {
+ "type": "string"
+ },
+ "schema": {
+ "type": "string"
+ }
+ },
+ "type": [
+ "object",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "host": {
+ "type": "string"
+ },
+ "newProblems": {
+ "items": {
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "status": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "note": {
+ "type": "string"
+ },
+ "partlyImproved": {
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "resolved": {
+ "items": {
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "was": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "rulesetChanged": {
+ "description": "Null when one snapshot predates version tracking.",
+ "type": [
+ "boolean",
+ "null"
+ ]
+ },
+ "schemaChanged": {
+ "type": [
+ "boolean",
+ "null"
+ ]
+ },
+ "score": {
+ "description": "Present instead of a diff when history starts with this call.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "scoreDelta": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "spanHours": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "summary": {
+ "type": "string"
+ },
+ "to": {
+ "description": "One end of the comparison.",
+ "properties": {
+ "at": {
+ "format": "date-time",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "grade": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "score": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "versions": {
+ "description": "Ruleset that produced this measurement. Null for snapshots written before version tracking existed.",
+ "properties": {
+ "collector": {
+ "type": "string"
+ },
+ "ruleset": {
+ "type": "string"
+ },
+ "schema": {
+ "type": "string"
+ }
+ },
+ "type": [
+ "object",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "worsened": {
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "host",
+ "comparable"
+ ],
+ "type": "object"
+}audit_websitecheck_ai_visibilitycheck_categorycompare_websitesget_badge_embedget_scoreget_site_inventorywhat_changedClaiming 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!
