Website Auditor MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.15
Disambiguation4/5
Most tools have distinct purposes: get_ai_visibility vs run_audit, compare_competitors vs get_benchmark, etc. The main ambiguities are track_site's description mentioning 'start (or stop)' when untrack_site explicitly handles stopping, and a slight overlap between list_tracked_sites and get_monitoring_status. These are minor and descriptions are detailed enough to guide selection.
Naming Consistency5/5
All tool names follow a consistent snake_case verb_noun pattern (e.g., get_ai_visibility, list_tracked_sites, run_audit, untrack_site). While different verbs are used for different actions, this is natural and predictable, and there are no mixed conventions like camelCase or vague names.
Tool Count5/5
With 14 tools, the server sits within the well-scoped range of 3-15 tools, and each tool earns its place by covering distinct functionality: auditing, tracking, comparisons, recommendations, schema generation, reporting, and subscription management. Even though a couple of tools overlap (list_tracked_sites and get_monitoring_status), they serve different aspects of the domain.
Completeness4/5
The toolset covers the core lifecycle: track, untrack, audit, get visibility, monitor status, see changes, compare, benchmark, get recommendations, generate schema, share reports, check subscription, and demo with a sample. Minor gaps include no tool to update tracking cadence or directly retrieve a full audit report (only a link to it), but agents can work around these.
Average 4.7/5 across 14 of 14 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 90 commits in the last 12 weeks
- Last stable release on August 13, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and openWorldHint, but the description adds critical context beyond them: the Website Auditor subscription requirement, free-trial details, and the fallback workflow to get_sample_audit. This is valuable behavioral disclosure not present in structured metadata, though it doesn't detail return format or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and usage guidance. The final sentence about subscription and trial is long but information-dense, covering a prerequisite and an alternative tool. It could be split for readability but every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description hints at the return type ('percentile/peer context') and references get_sample_audit's output format as a proxy. It also covers prerequisites and alternatives, making it reasonably complete for a read-only tool with three well-documented parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all three parameters (domain, geo, industry), so the description doesn't need to explain them. The description mentions 'industry and location' but doesn't add semantics beyond what the schema already provides, matching the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('benchmark') and resource ('website's AI visibility') against industry and location. It explicitly contrasts with absolute scoring ('percentile/peer context rather than an absolute number'), distinguishing it from sibling tools like get_ai_visibility and compare_competitors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance with example user queries and states the condition for using an alternative (call get_sample_audit when no subscription). It also implicitly excludes absolute-number requests, giving clear decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds valuable context: subscription/payment requirements, the 7-day free trial, that it establishes history for get_changes, and that stopping is done via 'enabled': false. It does not specify what happens to history when stopping, but the annotations cover the destructive nature enough that this is not a major gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-structured: first sentence gives the core action, second gives use cases, third explains history relationship, and fourth handles subscription prerequisites. Every sentence serves a purpose, though the subscription sentence is longer and more complex than ideal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's mutating nature, lack of output schema, and subscription prerequisite, the description covers the critical context: when to use, subscription requirement, alternative action, and relationship to get_changes. However, it does not describe what the tool returns on success or whether stopping deletes history, which would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema documents domain, cadence, and enabled with descriptions. The description adds no additional parameter-level semantics beyond referencing 'start' and 'stop' which maps to enabled. Baseline 3 is appropriate since the schema handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb+resource: 'Start (or stop) ongoing monitoring of a website's AI visibility on a schedule.' It explicitly contrasts with 'a one-off check,' distinguishing it from siblings like run_audit and get_ai_visibility. It also links to get_changes as the consumer of the established history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use triggers: 'when someone wants to "monitor," "track," "watch," or "get alerted about" a site.' It also states when not to use it ('rather than a one-off check') and gives an alternative action: call get_sample_audit first if the user lacks a subscription. This is clear, actionable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, openWorldHint), the description discloses the subscription requirement, free trial details, output format ('Returns valid JSON-LD'), and a fallback action. It adds real behavioral context without contradicting 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is informative but not wasteful; it front-loads purpose, then covers usage and prerequisites. It's slightly longer than the minimal two-sentence ideal but every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameter structure and no output schema, the description fully covers what the tool does, when to use it, what it returns, and critical prerequisites. The mention of the alternative get_sample_audit completes the picture within the tool ecosystem.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers both parameters with clear descriptions (type enum and domain example), yielding 100% schema description coverage. The tool description adds no additional parameter-level meaning beyond stating the general purpose, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Generate') and resource ('JSON-LD schema') with context ('ready-to-paste structured data tailored to a website'). It distinguishes from sibling tools by focusing on schema generation rather than audits or tracking, and explicitly names related queries ('schema,' 'structured data,' 'JSON-LD').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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 ('Use this when someone asks for "schema," "structured data," "JSON-LD," or wants the actual markup') and provides a clear alternative path when prerequisites aren't met ('if the user doesn't have one, call get_sample_audit first'). This is textbook when/when-not/alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations already mark the tool as readOnlyHint, the description adds valuable behavioral context: it returns trend data from stored snapshot history, includes a name_warning caveat that must be relayed, and discloses the subscription requirement. It also tells the agent how to handle the warning (relay it, offer to re-run). This goes well 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than average but every sentence provides necessary information: purpose, user intents, return values, warnings, and subscription context. It is front-loaded with the main purpose and follows with structured details. A slight deduction for density, but no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 explains what the agent will get: a score, per-engine breakdown, top competitor, and trend data. It also covers the name_warning edge case and the subscription prerequisite, making the tool's context complete enough for correct invocation and result interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with detailed descriptions for each parameter, including the caveats about business_name and business_location. The tool description does not add additional parameter-level meaning beyond what the schema already states, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: checking how visible a website is to AI assistants. It provides specific example queries ('does ChatGPT/Perplexity/Claude/Gemini recommend this business') that anchor the purpose, and the focus on AI visibility distinguishes it from sibling tools like run_audit or get_benchmark.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this whenever someone asks...' with a list of concrete user intents. It also gives an exclusion/alternative: if the user lacks a subscription, call get_sample_audit instead. This provides both when-to-use and when-not-to-use guidance, satisfying the dimension fully.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and openWorldHint annotations, the description discloses key behavioral traits: requires domain tracking, requires a paid subscription with trial details, returns specific delta types, and provides a fallback path. This adds significant value beyond annotations, with no contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is slightly longer but front-loaded with purpose and usage, then detailed prerequisites and outputs. Every sentence contributes necessary information, but it could be tightened without losing value. Overall efficient for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Since there is no output schema, the description fully explains return values (score movement, engines gained/lost, competitors moved, new/resolved issues) and covers prerequisites, subscription, and fallback. This gives the agent everything needed to decide when and how to invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers both parameters 100%, so baseline is 3. The description does not add parameter-specific details beyond context; it only mentions 'since it was last checked' which aligns with the 'since' parameter. No additional semantics like examples or edge cases are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reports what changed in a website's AI visibility and audit since the last check, using specific verbs and resource. It distinguishes itself from siblings like get_ai_visibility or run_audit by focusing on deltas since last check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use with example queries ('did anything change,' 'did my AI visibility drop'), and provides alternatives for prerequisites: track_site for untracked domains, get_sample_audit for users without a subscription. This gives clear context and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and open-world behavior. The description adds meaningful context about the subscription requirement, payment terms, and the fallback flow, which are behavioral traits not visible in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear purpose, usage triggers, return value, and pricing/fallback info. Every sentence adds value, and it is front-loaded with the core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description fully covers what the tool does, what it returns, and the conditions for using it. It also informs the agent of a required subscription and a free alternative, making the context complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description for the only parameter (domain). The description adds no further semantic detail beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: getting specific, prioritized fixes for AI visibility and audit scores. It distinguishes itself from siblings by linking to audits (run_audit) and offering a fallback to get_sample_audit, making its unique role explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit triggers ('how do I fix this,' 'what should I change') and states when to call an alternative (get_sample_audit) if the user lacks a subscription. This is excellent usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and openWorldHint annotations, the description discloses the subscription requirement, pricing, trial details, and payment-method prerequisite. This adds meaningful context about auth and business constraints that the annotations do not cover, so the agent knows the operational implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with heavy front-loading: the first sentence names the action and outputs, the second gives usage triggers and exclusions. Despite the length of the second sentence, every detail (pricing, alternative) is relevant to correct invocation, so it earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple schema and presence of annotations, the description fully covers what the tool returns (URL and HTML snippet), when to use it, and what to do if prerequisites are unmet. It compensates for the lack of an output schema by stating the return types explicitly and is complete for an agent's decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the only parameter (domain) with a clear description, so the baseline is 3. The tool description does not add any extra meaning beyond implicitly referencing the website, which the schema already captures. Thus no enhancement over schema is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Get a shareable report URL and the embeddable badge snippet for a website,' which is a specific verb-plus-resource phrasing. It also distinguishes from siblings by explicitly mentioning the alternative get_sample_audit, so the tool's unique purpose is unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit triggers: 'Use this when someone wants to share, export, send a client, or embed the audit result.' It also gives a clear when-not: if the user lacks a subscription, call get_sample_audit first. This directly guides tool selection and offers a concrete alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes beyond annotations by disclosing idempotency, return value (number of free slots), and subscription requirement; consistent with destructiveHint and readOnlyHint=false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise yet information-dense; every sentence provides necessary usage, behavioral, or qualification details, front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter destructive tool with no output schema, the description covers prerequisites, alternatives, behavior, and return value, making it complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the single 'domain' parameter; description adds no additional parameter-level meaning beyond the schema's example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Stop ongoing monitoring of a website's AI visibility') with a specific verb and resource, distinguishing it from siblings like track_site and list_tracked_sites.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists trigger phrases ('stop tracking,' 'unmonitor,' etc.) and includes an alternative action (call get_sample_audit if no subscription), fulfilling the when-to-use and when-not-to-use criterion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond the readOnly annotation by disclosing quota consumption per uncached competitor, graceful degradation via skipped list, over-quota error behavior with reset time, and subscription/pricing details. This is rich behavioral context not present in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but densely packed with essential information, front-loaded with purpose and usage. Every sentence earns its place, though it could be slightly more scannable with bullet points.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 covers return fields (scores, quota skipped list), error scenarios, and prerequisites. It fully compensates for the missing output schema and provides complete context for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaningful context that each competitor in the array costs an audit and that the tool ranks audited ones when quota is insufficient, which enriches understanding of the competitors parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: comparing a website's AI visibility against named competitors. It also gives concrete example queries ('how do I stack up against X and Y') and distinguishes itself from siblings by focusing on head-to-head competitor comparisons.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is explicitly defined with example queries. It also names an alternative (get_sample_audit) for users without a subscription, providing clear when-to-use and fallback guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description reveals that the tool returns fixed sample data for example.com in the exact shape of a real audit, includes scored summary, per-test results, and AI-visibility breakdown, and is clearly marked as a sample. It also warns that it never describes the user's own site. This adds significant behavioral context beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat lengthy but every sentence serves a purpose: purpose, usage cases, output details, and limitations. It is front-loaded with the core action and then flows logically. It could be tightened slightly, but the structure is clear and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description fully carries the burden of explaining what the user gets and when to use it. It details the output shape, the fact it's a sample, and the boundaries (never the user's site, real audits need subscription). This is complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description cannot add parameter-level semantics. The baseline for 0 params is 4, and the description correctly focuses on the output and use case rather than inventing irrelevant parameter details. No additional param info is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Show a complete sample Website Auditor report.' It clearly distinguishes from siblings by emphasizing it's a sample, no key needed, and for example.com only, contrasting with real audits that require a subscription. This is unambiguous and fully captures the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists triggering phrases ('try it,' 'see a demo,' 'show me what this does') and tells the agent to use it INSTEAD of refusing when no API key is configured. It also contrasts with real audits ('auditing a real domain needs a subscription'), making the alternative usage clear. This is exemplary usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true and openWorldHint=true. The description confirms read-only, no quota consumption, and details the returned fields (tier, status, period end, etc.), adding that starting Pro requires a payment method and terms. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is thorough yet efficient, front-loading the main purpose, listing use cases, then detailing output and prerequisites. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 0 parameters and no output schema, the description fully covers all behavioral aspects: input constraints, output details, and usage context. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has 0 parameters, so schema coverage is 100% by default. Description adds no param info (none needed) but explains what the tool returns, which is valuable context. Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks the caller's own Website Auditor subscription standing, listing specific questions it answers (e.g., 'am I on Pro,' 'is my trial still active'). It distinguishes from sibling tools by being unique for subscription status, while siblings focus on tracking, audits, and reports.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this when someone asks...' and 'before suggesting an upgrade,' providing clear context. Also notes it works with any valid API key and consumes no audit quota, giving practical guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description supplements the readOnlyHint annotation by adding auth/payment requirements (Website Auditor subscription, trial details, payment method needed) and the precise return structure. It also discloses the fallback behavior for users without a subscription, which goes beyond the annotation's basic safety cue.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence carries necessary information: purpose, trigger phrasings, return content, and subscription handling. It is front-loaded with the main action and uses a clear flow, being sufficiently concise for the content it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and empty params, the description fully covers what the tool returns, when to use it, and the subscription prerequisite. It also includes the fallback to get_sample_audit, making the description complete for both subscribers and non-subscribers.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing to explain in the schema. The description still adds the scope of the operation ('across all tracked websites'), which clarifies that no filtering is possible. This meets the baseline for a no-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Get a glanceable summary of monitoring status across all tracked websites.' It further clarifies the output (per-domain AI visibility, last audit, next run, recent change) and differentiates from siblings like get_ai_visibility by emphasizing the 'all tracked websites' scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'Use this when someone asks...' with concrete example phrasings, and gives a clear alternative for non-subscribers: 'call get_sample_audit first.' This tells exactly when to use this tool and what to do instead, covering both prerequisites and fallback.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, but the description adds meaningful behavioral context such as the required Website Auditor subscription, free trial terms, and payment details. It also specifies what the return includes (cadence, active state, slots), going beyond the basic read-only annotation. No contradiction 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the main purpose. It then adds concise usage examples, return details, and subscription constraints, with every sentence contributing value and no unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, when to use it, prerequisites (subscription), fallback behavior, and output structure, providing a complete picture. Given the lack of an output schema and the tool's simplicity, this is fully sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4 per the rubrics. The description doesn't need to explain parameters, but it enriches understanding by describing the output fields and slot limitations, which is sufficient for this tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists websites currently monitored for AI visibility, using a specific verb and resource. It also distinguishes from sibling tools by focusing on tracked domains, cadence, active state, and slot usage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly provides trigger phrases ('what am I tracking,' 'which sites am I monitoring') for when to use this tool. It also gives an alternative action (call get_sample_audit) when the user lacks the required subscription, offering clear decision guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and openWorldHint annotations, the description discloses important behavioral traits: it requires a Website Auditor subscription with trial terms, it returns a scored summary plus a report link, and it instructs how to handle the name_warning caveat. It also reveals that a guessed business_name is scored as confirmed, which is a nuanced behavior an agent needs to know.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is densely informative yet efficiently arranged: purpose, usage triggers, output summary, caveat handling, subscription details, and fallback alternative. Every sentence earns its place, with no fluff or redundancy. The single paragraph flows logically from what to when to how.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description tells the agent what to expect ('a scored summary across categories and a link to the full report') and covers caveats, subscription requirements, and an alternative path. Combined with the rich schema and sibling context, it is fully self-sufficient for correct invocation and response handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema covers 100% of parameters, the description significantly enriches semantics for business_name and business_location. It explains the consequence of omitting business_name (auto-detection with unverified flag) and warns that a guessed name is scored as confirmed, which is critical for data integrity. Similarly, it clarifies how business_location affects detection and scope, adding value far beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource+scope: 'Run a full one-time audit of a website — AI visibility plus SEO, security headers, broken links, and performance.' It clearly distinguishes the tool from siblings like get_ai_visibility, which only returns the AI-visibility number, by emphasizing the complete multi-category report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use it ('Use this when someone asks to audit, scan, check, or review a website's health or SEO, or wants a complete report rather than just the AI-visibility number') and provides a clear alternative for non-subscribers: 'call get_sample_audit first.' It also covers subscription prerequisites, making the decision boundary precise.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![website-auditor-mcp MCP server](https://glama.ai/mcp/servers/SpikeyCoder/website-auditor-mcp/badges/card.svg)](https://glama.ai/mcp/servers/SpikeyCoder/website-auditor-mcp)

Score Badge

Copy to your README.md:

[![website-auditor-mcp MCP server](https://glama.ai/mcp/servers/SpikeyCoder/website-auditor-mcp/badges/score.svg)](https://glama.ai/mcp/servers/SpikeyCoder/website-auditor-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/SpikeyCoder/website-auditor-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server