A digital audit for small-business websites: a score out of 100 and the main problems.
Scored across 2 tools
check_website performs the audit, while explain_area provides static explanation of areas. Their purposes do not overlap, and an agent can easily choose based on whether a website check or conceptual explanation is needed.
Both tool names follow a consistent verb_noun snake_case pattern: check_website and explain_area. The naming is predictable and easy to parse.
The server has only 2 tools, which is borderline thin even for a narrow auditing service. While each tool is distinct, a third tool (e.g., listing areas or retrieving fuller reports) could reasonably earn a place.
The core workflow of checking a website and explaining its six areas is covered. Minor gaps exist, such as no way to fetch more than the top three problems or view check history, but these appear to be deliberate limits of the service.
Checks a public small-business website with Sitecomb's website check. It returns a score out of 100 and the most important problems (up to three). Each comes with a line on why it matters. Use it when someone asks whether their website is any good, or what is wrong with it. Also use it for "why isn't my site bringing in customers?" or a request to check or audit a website. It looks at six areas: security, privacy and legal notices, quality, phones, getting customers and AI visibility. A check loads the site the way a visitor's browser does and takes up to about a minute. It only finds problems; it never changes anything on the site. If the site is down or blocks automated checkers, it says it couldn't check and gives no score. Free checks are limited per person and per website each day.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The website address to check, for example https://yourbusiness.com or yourbusiness.com. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open-world), so the bar is lower, yet the description still adds substantial behavioral context: browser-like rendering of the site, ~1 minute runtime, explicit failure mode (site down or blocking bots yields no score), a daily per-person and per-site rate limit, and the shape of the result. This is exactly the context an agent needs to set expectations and handle failures.
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?
Front-loaded with what it does and returns, then layered with triggers, coverage areas, latency, safety, failure behavior, and limits, all in short sentences. Slightly padded by two overlapping trigger sentences and a read-only restatement that annotations largely cover, but nothing is genuinely wasteful.
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?
With no output schema, the description carries the return-value burden and does so: score out of 100, up to three prioritized problems each with a rationale, plus the no-score failure case. Combined with runtime, scope, and rate limits, an agent can invoke and interpret this tool without guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single url parameter is already documented with examples and length bounds. The description adds no format or normalization guidance 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?
States a specific verb and resource ('Checks a public small-business website') and immediately scopes it with the return value (score out of 100, top three problems) and the six areas examined. An agent knows exactly what this tool produces. It does not, however, name or contrast with its sibling explain_area, which is the one differentiation an agent would benefit from.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete trigger conditions, including paraphrased user utterances ('whether their website is any good', 'why isn't my site bringing in customers?', 'audit a website'), which is unusually strong routing guidance. It stops short of stating when NOT to use it or pointing to explain_area as the alternative for understanding the six areas.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explains what Sitecomb looks at in one of its six areas: security, privacy, quality, phones, customers or ai. Use it when someone asks what Sitecomb checks, or about an area named in a check_website result. It doesn't check any website.
| Name | Required | Description | Default |
|---|---|---|---|
| area | Yes | Which of the six areas to explain. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds a genuine behavioral boundary beyond the annotations: it clarifies that the tool performs no site checking, preventing confusion with check_website. It does not describe the returned explanation's shape, but with no output schema that gap is modest.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with what the tool does, followed by when to use it and the key exclusion. No sentence is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-enum, read-only explainer with no output schema, the description covers purpose, triggers and a boundary against the sibling. It could briefly indicate what the explanation output looks like, but nothing essential to correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single enum parameter is fully documented with the same six values the description lists. The description reinforces the enum but adds no syntax or format detail the schema lacks, so the baseline 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?
States a specific verb (explains) and resource (one of six named Sitecomb areas), and enumerates the exact areas covered. It is immediately distinguishable from the sibling check_website, which performs checks rather than explaining them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit trigger conditions ('when someone asks what Sitecomb checks, or about an area named in a check_website result') and an explicit exclusion ('It doesn't check any website'), which routes the agent away from check_website. Nothing is left to inference.
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.
check_websiteexplain_areaFree website score for speed, SEO, security and AI search readiness, with the fixes.
Audit a website for technical and on-page SEO problems.
Scores a website's online presence 0-100 and lists the top issues to fix. English/Arabic.
Scores a website's online presence 0-100 and lists the top issues to fix. English/Arabic.
Add one secure layer between your agents and this server.