A
licenseA
qualityA
maintenanceEnables agents to verify that a deploy actually worked by checking pages, links, and comparing environments, catching blank 200 responses, broken links, stray noindex, and staging that never updated.
3
MIT
Verant
by ai.verant
Server Details
Proofread live pages and sites for spelling, grammar, and placeholder text. Free: 2 pages a month.
Ownership verified
- Status
- Healthy
- Uptime
- 29.9% over 74 days
- OAuth
- Works in Glama
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
TDQS
A4.7/5.0
Scored across 3 tools
Disambiguation5/5
Each tool has a clearly distinct role: proofread_url handles a single page, proofread_site crawls a whole site, and get_scan polls results by scanId. The descriptions explicitly explain when to use one versus the other, leaving no realistic misselection risk.
Naming Consistency5/5
All three names follow a consistent snake_case verb_noun pattern (get_scan, proofread_url, proofread_site). The convention is predictable and readable throughout.
Tool Count5/5
Three tools is well-scoped for a proofreading service: two entry points for the two scan scopes plus one poller for the shared async result flow. Every tool earns its place with no redundancy.
Completeness4/5
The core lifecycle (start a scan, retrieve findings and site checks) is fully covered, including progress polling and report URL. Minor gaps exist—no cancel/abort scan or list-previous-scans operation—but agents can work around these.
Available Tools
3 toolsget_scanRead a scanARead-onlyIdempotentInspect
Read the progress and findings of a scan that proofread_url or proofread_site started. Call it with the scanId every 10 seconds and stop when done is true (status is not processing). detail "concise" (default) gives counts and the first 25 findings; "full" gives all. Each finding has the original text, the fix, the type, and the page URL; hidden describes that page row, and surface names head copy (page_title, meta_description, social_title, social_description). siteChecks holds the free Open Graph, favicon, and sitemap checks (null before they ran). reportUrl is the full report page.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | concise | |
| scanId | Yes | The Verant scan id to fetch. |
Output Schema
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| done | Yes | |
| mode | Yes | |
| note | No | |
| error | Yes | |
| phase | Yes | |
| scanId | Yes | |
| status | Yes | |
| outcome | Yes | |
| findings | Yes | |
| progress | Yes | |
| shareUrl | Yes | |
| reportUrl | Yes | |
| truncated | Yes | |
| issueCount | Yes | |
| siteChecks | Yes | |
| pollAfterSeconds | No |
TDQS
A4.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive, so the safety profile is covered. The description adds real value beyond that: the done/status completion signal, the polling cadence, the detail-mode output truncation behavior, and what siteChecks holds (null before the checks ran). It does not mention auth requirements or error behavior, keeping it just short of a 5.
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?
Front-loaded with purpose and polling instructions, which is exactly right. However, the second half enumerates return fields (findings contents, hidden, surface, siteChecks, reportUrl) that an output schema already exists to describe, so several clauses are partly redundant.
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 an async polling read tool with an output schema, the definition covers the lifecycle (started elsewhere, poll, stop condition), the mode switch, and the shape of the notable nested fields. Nothing needed to call it correctly is missing.
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?
Schema description coverage is only 50%, with the enum-bearing 'detail' parameter undocumented in the schema. The description compensates fully: 'concise' (default) returns counts plus the first 25 findings, 'full' returns all. That directly resolves the ambiguity the schema leaves open.
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?
States a specific verb and resource ('Read the progress and findings of a scan') and ties it explicitly to the sibling tools that create the scan (proofread_url, proofread_site), so an agent can immediately separate it from them.
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?
Gives concrete operational guidance: pass scanId, poll every 10 seconds, and stop when done is true (status is not processing). It also explains when to pick each detail mode. This is explicit when-to-use and termination guidance that most definitions lack.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
proofread_siteProofread a siteAInspect
Crawl a public website from its root URL and proofread every page found, up to maxPages and the plan's page limit. Pro and Ultra plans only; for one page, use proofread_url. Returns a scanId at once; call get_scan with it every 10 seconds and stop when done is true. Each checked page uses 1 page of the monthly allowance.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The public root URL to crawl and proofread. | |
| maxPages | No | Optional page cap, clamped by the account allowance and page limit. |
Output Schema
| Name | Required | Description |
|---|---|---|
| scanId | Yes | |
| status | Yes |
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare the generic profile (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false). The description adds substantial behavior the annotations cannot convey: asynchronous execution (returns a scanId immediately rather than results), the required polling cadence and termination condition, plan gating, and a real cost model ('each checked page uses 1 page of the monthly allowance').
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?
Three sentences, front-loaded with what it does, then eligibility/routing, then the async follow-up and cost. Every clause carries operational information — no filler or restated title.
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?
An output schema exists, yet the description still supplies the one thing an agent needs to act on the result: that the response is a scanId requiring polling via get_scan with a 10-second interval. Plan restrictions and quota consumption complete the picture for a long-running, allowance-consuming operation.
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% and both parameters are documented in the schema, so the baseline is 3. The description restates the same clamp semantics already present in maxPages' schema description ('clamped by the account allowance and page limit') and adds no format, syntax, or default information beyond it.
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?
States a specific verb and resource ('crawl a public website from its root URL and proofread every page found') with explicit scope limits (maxPages, plan page limit). It also names the sibling it is not — 'for one page, use proofread_url' — so an agent can distinguish it from proofread_url and get_scan without reading schemas.
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?
Gives explicit eligibility ('Pro and Ultra plans only'), an explicit alternative-selection rule ('for one page, use proofread_url'), and the follow-up workflow ('call get_scan with it every 10 seconds and stop when done is true'). When-to-use, when-to-use-something-else, and what-to-do-next are all covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
proofread_urlProofread a pageAInspect
Check one published web page for spelling, grammar, punctuation, and leftover placeholder text. Use it when the user gives a page URL or asks to proofread, spell-check, or find typos on a live page. Returns a scanId at once; call get_scan with it every 10 seconds and stop when done is true. Uses 1 page of the account's monthly allowance (free accounts: 2 pages a month).
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The public page URL to proofread. |
Output Schema
| Name | Required | Description |
|---|---|---|
| scanId | Yes | |
| status | Yes |
TDQS
A4.5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well past the annotations by disclosing the async contract (returns a scanId at once, poll get_scan every 10 seconds, stop when done is true) and the billing consequence (consumes 1 page of the monthly allowance, free accounts limited to 2 pages/month). That is exactly the operational and cost context an agent needs before invoking a non-idempotent, open-world tool.
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?
Three sentences, zero filler, and ordered by importance: what it checks, when to use it, then the mechanics and cost. Every sentence earns its place and nothing is front-loaded incorrectly.
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?
An output schema exists so return values needn't be explained, yet the description still supplies the one thing the schema cannot: how the async result is retrieved and what the call costs. For a one-parameter, fully-described tool this leaves no practical gap.
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% and the single url parameter is already fully documented there ('The public page URL to proofread'). The description only adds the indirect hint that the page must be published/live; it offers no syntax, format, or constraint detail beyond the schema, so the baseline 3 applies.
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?
States a precise verb+resource+scope: 'Check one published web page for spelling, grammar, punctuation, and leftover placeholder text.' The scope word 'one published web page' cleanly separates it from the sibling proofread_site, and the check categories tell the agent exactly what the tool produces.
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?
Gives clear trigger conditions ('when the user gives a page URL or asks to proofread, spell-check, or find typos on a live page') and describes the follow-up workflow with get_scan. It never explicitly says when NOT to use it or names proofread_site as the alternative for multi-page jobs, so sibling routing 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.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
- Changed
get_scan1 field changed- added
Output schema / properties / findings / items / properties / surfaceAdded value: +{ + "enum": [ + "page_title", + "meta_description", + "social_title", + "social_description" + ], + "type": "string" +}
1 tool update
- Changed
get_scan2 fields changed- added
Output schema / properties / siteChecksAdded value: +{ + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "favicon": { + "oneOf": [ + { + "additionalProperties": false, + "properties": { + "checked": { + "const": false, + "type": "boolean" + }, + "reason": { + "type": "string" + } + }, + "required": [ + "checked", + "reason" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "checked": { + "const": true, + "type": "boolean" + }, + "icons": { + "items": { + "additionalProperties": false, + "properties": { + "bytes": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "contentType": { + "type": [ + "string", + "null" + ] + }, + "format": { + "anyOf": [ + { + "enum": [ + "png", + "ico", + "gif", + "webp", + "jpeg", + "svg" + ], + "type": "string" + }, + { + "type": "null" + } + ] + }, + "href": { + "type": "string" + }, + "loads": { + "type": "boolean" + }, + "note": { + "type": [ + "string", + "null" + ] + }, + "pixels": { + "items": { + "additionalProperties": false, + "properties": { + "height": { + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "width": { + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + } + }, + "required": [ + "width", + "height" + ], + "type": "object" + }, + "maxItems": 16, + "type": "array" + }, + "sizes": { + "type": [ + "string", + "null" + ] + }, + "source": { + "enum": [ + "icon", + "apple-touch-icon", + "mask-icon", + "favicon.ico" + ], + "type": "string" + }, + "status": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "type": { + "type": [ + "string", + "null" + ] + } + }, + "required": [ + "source", + "href", + "sizes", + "type", + "status", + "contentType", + "bytes", + "format", + "pixels", + "loads", + "note" + ], + "type": "object" + }, + "maxItems": 21, + "type": "array" + }, + "rows": { + "items": { + "additionalProperties": false, + "properties": { + "label": { + "type": "string" + }, + "state": { + "enum": [ + "ok", + "fix", + "note", + "not-checked" + ], + "type": "string" + }, + "text": { + "type": "string" + }, + "word": { + "type": "string" + } + }, + "required": [ + "label", + "state", + "text" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "checked", + "rows", + "icons" + ], + "type": "object" + } + ] + }, + "openGraph": { + "oneOf": [ + { + "additionalProperties": false, + "properties": { + "checked": { + "const": false, + "type": "boolean" + }, + "reason": { + "type": "string" + } + }, + "required": [ + "checked", + "reason" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "card": { + "additionalProperties": false, + "properties": { + "description": { + "type": [ + "string", + "null" + ] + }, + "host": { + "type": "string" + }, + "image": { + "type": [ + "string", + "null" + ] + }, + "title": { + "type": [ + "string", + "null" + ] + } + }, + "required": [ + "title", + "description", + "image", + "host" + ], + "type": "object" + }, + "checked": { + "const": true, + "type": "boolean" + }, + "imageLoads": { + "type": [ + "boolean", + "null" + ] + }, + "rows": { + "items": { + "additionalProperties": false, + "properties": { + "label": { + "type": "string" + }, + "state": { + "enum": [ + "ok", + "fix", + "note", + "not-checked" + ], + "type": "string" + }, + "text": { + "type": "string" + }, + "word": { + "type": "string" + } + }, + "required": [ + "label", + "state", + "text" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "checked", + "rows", + "card", + "imageLoads" + ], + "type": "object" + } + ] + }, + "sitemap": { + "oneOf": [ + { + "additionalProperties": false, + "properties": { + "checked": { + "const": false, + "type": "boolean" + }, + "reason": { + "type": "string" + } + }, + "required": [ + "checked", + "reason" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "checked": { + "const": true, + "type": "boolean" + }, + "rows": { + "items": { + "additionalProperties": false, + "properties": { + "label": { + "type": "string" + }, + "state": { + "enum": [ + "ok", + "fix", + "note", + "not-checked" + ], + "type": "string" + }, + "text": { + "type": "string" + }, + "word": { + "type": "string" + } + }, + "required": [ + "label", + "state", + "text" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "checked", + "rows" + ], + "type": "object" + } + ] + }, + "url": { + "type": "string" + } + }, + "required": [ + "url" + ], + "type": "object" + }, + { + "type": "null" + } + ] +} - changed
Output schema / requiredPrevious value: -[ - "scanId", - "url", - "mode", - "status", - "done", - "phase", - "progress", - "outcome", - "error", - "issueCount", - "findings", - "truncated", - "reportUrl", - "shareUrl" -]New value: +[ + "scanId", + "url", + "mode", + "status", + "done", + "phase", + "progress", + "outcome", + "error", + "issueCount", + "findings", + "truncated", + "reportUrl", + "shareUrl", + "siteChecks" +]
3 tool updates
- First observed
get_scan - First observed
proofread_site - First observed
proofread_url
Related MCP Connectors
Website change monitor MCP: see what changed on any public page. Free 3 pages; $4.99/mo.
Review frontend code and live pages against 386 quality-gated web development rules.
Free check of one site for orphan pages, broken internal links and sitemap problems.
Technical SEO and AI-readiness audits for any page, plus a check that your fix worked.
Related MCP Servers
uxlintofficial
AlicenseAqualityBmaintenanceAudits any site's UX the way a design-literate reviewer would — contrast, tap targets, type scale, colour discipline, scan patterns, copy — and returns the rule, the source line and the exact fix.6Apache 2.0- FlicenseNot gradedqualityDmaintenanceFetches any public web page and provides SEO foundation snapshots and prose readability analysis.-
- AlicenseNot gradedqualityCmaintenanceEnables AI hosts to check text for grammar, spelling, and style errors, measure readability, and generate tone-adjusted rewrites through structured tool calls. Every tool returns predictable, typed output for reliable routing and results.MIT
Try in Browser
Let your AI agent see the webWeb-to-screenshot MCP for Claude, Cursor and Codex. No cookie banners. Free to start.snap-render.comAd
Glama MCP Gateway
Add one secure layer between your agents and this server.