Dotsy

verify_page

Read-onlyIdempotent

Pre-publish lint (tags, assets, layout, SEO, speed and accessibility). Summary first: health issues grouped by code, each with fix:{tool,args,fill?} — supply the fill args, then call. health.summary counts are whole-site (groups/codes filter only issues and assets). Pair with preview_page — see get_skill('verify').

Input Schema

Name	Required	Description
`site`	Yes	Site slug, e.g. acme-studio
`codes`	No	Only these health codes, e.g. perf_image_heavy.
`paths`	No	Routes to check; omit to verify every route on the site.
`detail`	No	summary (default): grouped by code, clean pages counted. full: per-page lists.
`groups`	No	Only these groups: speed = perf_, a11y = a11y_, links = link_* + content_*. Omit for all.
`context`	Yes	One sentence: why you are calling this tool and what you are trying to accomplish. Stored on the site's activity log and visible to everyone on the site — never put secrets or personal data here.
`guestToken`	No	Guest token from start_site. Send it on every call until claim_site. Omit when this chat is already signed in to Dotsy.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 25, 2026

changedInput schema / properties / groups / description

Previous value: -"Only these groups (links = links & content). Omit for all."New value: +"Only these groups: speed = perf_*, a11y = a11y_*, links = link_* + content_*. Omit for all."

Changed3 schema fields changedOct 25, 2026

addedInput schema / properties / codes

Added value: +{
+  "description": "Only these health codes, e.g. perf_image_heavy.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedInput schema / properties / detail

Added value: +{
+  "description": "summary (default): grouped by code, clean pages counted. full: per-page lists.",
+  "enum": [
+    "summary",
+    "full"
+  ],
+  "type": "string"
+}

addedInput schema / properties / groups

Added value: +{
+  "description": "Only these groups (links = links & content). Omit for all.",
+  "items": {
+    "enum": [
+      "seo",
+      "speed",
+      "a11y",
+      "links"
+    ],
+    "type": "string"
+  },
+  "type": "array"
+}

First observedOct 6, 2026

TDQS

A4.2/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/idempotent/non-destructive, yet the description still adds real behavioral substance: results arrive summary-first, issues are grouped by code, each carries a fix:{tool,args,fill?} payload that must be filled and re-invoked, and health.summary counts remain whole-site even when groups/codes are supplied. That non-obvious counting caveat is exactly the kind of detail an agent cannot infer from schema or 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?

Roughly four sentences, front-loaded with the purpose before the output contract and caveats; nothing is redundant. It is telegraphic in places ("supply the fill args, then call"), which slightly raises parsing cost but does not waste words.

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?

With no output schema, the description carries the return-value burden and does so by describing the summary-first grouped-by-code shape and the fix payload. What remains unstated is whether it lints the live site or drafts, and how it relates to preflight_site — minor gaps for a 7-parameter read-only 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 the baseline is 3, but the description adds genuine semantics: groups/codes narrow only issues and assets while the health.summary totals stay site-wide. It also documents the fix/fill interaction pattern that determines how subsequent calls are made.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource: a pre-publish lint covering tags, assets, layout, SEO, speed and accessibility, which tells an agent concretely what it checks. It does not, however, distinguish itself from the sibling preflight_site, which sounds like it covers adjacent pre-publish ground.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

"Pre-publish lint" plus "Pair with preview_page — see get_skill('verify')" gives a clear usage context and a named companion tool. There are no explicit exclusions or guidance on when to prefer preflight_site over this, so it stops short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Dotsy tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?