Komers Sites

Check the draft

check_site

Read-only

Check the draft before publishing: broken links and missing files, pages that will look wrong on phones (missing viewport, sideways scrolling), JavaScript that fails, accessibility problems found by axe-core (WCAG A/AA: contrast, labels, alt text, headings), and with lighthouse: true a Google Lighthouse report (scores and what to fix), forms that point at collections that do not exist or do not allow it, missing alt text, http:// resources and big images. Also gives design hints (info level) when the draft has the generic AI-made look: only default fonts, the stock purple gradient, no design tokens, emoji icons. Also returns agent_readiness: a 0-100 score (with graded breakdown and ranked fixes) of how well AI search and AI agents can find, cite and transact with the site. When browser checks are set up, also loads the pages in a real browser and returns phone and desktop screenshots of one page. Fix the errors (edit_files), then check again. Issues with quick_fix can be fixed in one call with the quick_fix tool.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "site": "<site>"
    },
    "name": "check_site"
  }
}

Input Schema

Name	Required	Description	Default
`page`	No	Page to screenshot, e.g. "/" or "/contact"	/
`site`	Yes	Site slug (e.g. "kopitiam-muar") or id
`browser`	No	Also run the browser pass when available (includes accessibility checks with axe-core on every page)
`lighthouse`	No	Also run Google Lighthouse on that page with phone settings: performance, accessibility, best practices and SEO scores (0-100), the main speed metrics, and what to fix first. Adds 10-30 seconds; use it before publishing or when the owner asks about speed or Google scores.

Output Schema

Name	Required	Description	Default
`note`	No
`issues`	Yes
`checked`	Yes
`summary`	Yes
`lighthouse`	No
`agent_readiness`	No
`preview_comments`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 11, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": {},
+  "properties": {
+    "agent_readiness": {
+      "additionalProperties": {},
+      "properties": {
+        "grade": {
+          "type": "string"
+        },
+        "score": {
+          "type": "number"
+        }
+      },
+      "type": "object"
+    },
+    "checked": {
+      "additionalProperties": {},
+      "properties": {
+        "browser": {
+          "type": "boolean"
+        },
+        "pages": {
+          "items": {
+            "type": "string"
+          },
+          "type": "array"
+        }
+      },
+      "required": [
+        "pages",
+        "browser"
+      ],
+      "type": "object"
+    },
+    "issues": {
+      "items": {
+        "additionalProperties": {},
+        "properties": {
+          "code": {
+            "type": "string"
+          },
+          "fix": {
+            "type": "string"
+          },
+          "message": {
+            "type": "string"
+          },
+          "page": {
+            "type": "string"
+          },
+          "severity": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "severity",
+          "code",
+          "message"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "lighthouse": {
+      "additionalProperties": {},
+      "properties": {},
+      "type": "object"
+    },
+    "note": {
+      "type": "string"
+    },
+    "preview_comments": {},
+    "summary": {
+      "additionalProperties": {},
+      "properties": {
+        "errors": {
+          "type": "number"
+        },
+        "info": {
+          "type": "number"
+        },
+        "verdict": {
+          "type": "string"
+        },
+        "warnings": {
+          "type": "number"
+        }
+      },
+      "required": [
+        "errors",
+        "warnings",
+        "info",
+        "verdict"
+      ],
+      "type": "object"
+    }
+  },
+  "required": [
+    "summary",
+    "checked",
+    "issues"
+  ],
+  "type": "object"
+}

Changed2 schema fields changedNov 10, 2026

changedInput schema / properties / browser / description

Previous value: -"Also run the browser pass when available"New value: +"Also run the browser pass when available (includes accessibility checks with axe-core on every page)"

addedInput schema / properties / lighthouse

Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "enum": [
+        "true",
+        "false"
+      ],
+      "type": "string"
+    }
+  ],
+  "description": "Also run Google Lighthouse on that page with phone settings: performance, accessibility, best practices and SEO scores (0-100), the main speed metrics, and what to fix first. Adds 10-30 seconds; use it before publishing or when the owner asks about speed or Google scores."
+}

First observedNov 7, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already declare a safe read operation (readOnlyHint true, destructiveHint false, closed-world), and the description adds substantial context beyond them: that browser checks load pages in a real browser and return phone/desktop screenshots, that lighthouse adds 10-30 seconds, and that the result includes a graded 0-100 agent_readiness breakdown. Latency cost and return content are exactly the traits annotations cannot express.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is front-loaded with the core purpose, which is good, but the body is one very long enumerative sentence that mixes finding types, hint levels, scoring outputs and timing notes, making it hard to scan. There is also redundancy, e.g. missing alt text appears both inside the accessibility list and again as a standalone item.

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 diagnostic tool with four parameters, full schema description coverage, annotations and an output schema, the definition is complete: it covers what is checked, cost of the expensive passes, the follow-up repair loop, and the headline return value (agent_readiness). Nothing an agent needs 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.

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 real meaning: 'lighthouse: true' produces a Google Lighthouse report with scores and fixes, the browser pass runs axe-core on every page when available, and page selects which page gets screenshotted. It stops short of explaining the site slug/id format beyond what the schema already says.

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 names a specific verb and resource ('Check the draft before publishing') and then enumerates exactly what is verified: broken links, missing files, mobile layout, JavaScript failures, axe-core WCAG A/AA issues, Lighthouse scores, form/collection mismatches, http:// resources, oversized images, design hints and an agent_readiness score. An agent can tell this is a pre-publish diagnostic tool without opening the schema.

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?

It gives a clear workflow ('Check the draft before publishing', 'Fix the errors (edit_files), then check again') and routes simple fixes to quick_fix in one call, plus conditional guidance for lighthouse ('use it before publishing or when the owner asks about speed'). The only gap is that it does not state when NOT to use it, e.g. how it differs from the sibling get_site_health.

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

All Komers Sites tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?