A digital audit for small-business websites: a score out of 100 and the main problems.
Scored across 2 tools
check_website performs a live audit of a URL, while explain_area only explains Sitecomb's six audit categories. Their purposes are clearly distinct and the descriptions reinforce when to use each.
Both tools follow the same verb_noun snake_case pattern: check_website and explain_area. There is no mixing of conventions or ambiguous verb styles.
Two tools is thin for the stated auditing domain, even though both are useful. The surface feels borderline minimal rather than comfortably scoped.
The server covers the core read-only workflow: audit a site and explain the audit areas. Minor gaps exist, such as no way to retrieve a full issue list beyond the top three, but agents can still handle the primary use cases.
Checks a public small-business website with Sitecomb's digital audit. 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), and the description adds genuinely new operational context: the check loads the site like a real browser, takes up to roughly a minute, never mutates the site, fails without a score when blocked, and is subject to daily rate limits per person and per website. That is exactly the beyond-annotations detail an agent needs.
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 the verb, resource and return values, then usage triggers, then scope and limits. Every sentence carries information, though the enumeration of six audit areas is slightly list-heavy for the marginal benefit it provides.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description compensates fully by describing the score, the capped problem list, and the accompanying rationale. Runtime expectation, failure behavior, and rate limits are all covered, so an agent knows what to expect before and after the call.
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?
Only one parameter, and schema description coverage is 100% – the schema already documents the url and gives example formats. The description adds no syntax or format guidance beyond that, 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 with Sitecomb's digital audit') and immediately describes the output shape (score out of 100, up to three problems with reasons). An agent can distinguish this from the sibling explain_area, which is about explaining an area rather than running a check.
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, including the user phrasings that should route here ('is my website any good', 'why isn't my site bringing in customers', 'audit my website'). It also names the conditions under which the tool cannot help (site down or blocking automated checkers).
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_areaScores 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.
AI website audit: security, SEO, performance, UX and accessibility checks with actionable fixes.
Website, local SEO, performance and conversion audits with human-confirmed checkout.
Add one secure layer between your agents and this server.
