site-kit

Overview Schema Source Related Servers Discussions Admin

Review a site against the whole rulebook

review_site

Read-onlyIdempotent

Scans every page and stylesheet in a folder, then returns an annotated critique ranked by visitor impact, with evidence, sources, and a better alternative for each finding.

Instructions

Read every page and stylesheet in a folder and return an annotated critique.

Each finding carries: WHAT was found with the evidence, WHY it matters, what it is teaching, WHO says so with a confidence tag and that source's caveat, WHERE the line is drawn, and the better MOVE. Findings are ordered by how fast a visitor would notice them and annotated the way a chess game is: ?? clocked in five seconds, ? felt but not named, ?! a habit worth dropping.

Rules that could not run are listed as prominently as the ones that failed, with the reason each one could not run. They are never counted as passes.

Use explain_rule with any rule id from the output to read the full teaching note, every source, every caveat, and what that rule measured across the corpus it was built from.

Input Schema

TableJSON Schema

Name	Required	Description
`skip`	No	Rule ids to leave out of this run.
`tier`	No	Only one tier: 1, 2, 3, "floor", "honesty", "structure", "craft", "trap" or "ledger".
`focus`	No	Only run these rule ids. Leave empty to run the whole rulebook.
`ignore`	No	Folder or file names to skip. Defaults cover node_modules, .git, dist, build and friends.
`directory`	Yes	Full path to the site folder, for example /Users/brian/Sites/chess-lessons.
`concept_site`	No	Declare this an unsolicited concept page rather than a live site. A few rules are right on a real site and wrong on a concept one; they suppress themselves rather than firing wrongly.
`max_per_rule`	No	How many times one rule may report before the rest are summarised. Default 4.

Output Schema

TableJSON Schema

Name	Required	Description
`fix`	No
`why`	No
`tool`	Yes	Which tool produced this.
`clean`	No
`pages`	No
`counts`	No
`status`	Yes	pass = checked and clean. fail = checked and found problems. skipped = nothing was measured. error = the tool could not run.
`problem`	No
`findings`	No
`headline`	Yes	One sentence verdict, safe to show a non-technical user.
`directory`	No
`rules_run`	No
`error_code`	No	Set only when status is "error".
`files_read`	No
`not_checked`	No
`stylesheets`	No
`rules_available`	No
`missing_stylesheets`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv2.0.0Sep 17, 2026

TDQS

A4.4/5.0

Behavior5/5

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

The description goes far beyond the readOnly/idempotent annotations: it details the exact structure of each finding, the visitor-notice ordering, the chess-style annotation meaning, and the prominent handling of rules that could not run. It also states these are never counted as passes, which is a behavioral subtlety an agent must know.

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?

The description is longer than the ideal minimal definition, but every sentence carries distinct information about output structure, ordering, failed-rule behavior, or follow-up guidance. The main purpose is front-loaded in the first sentence, and the rest is justified by the tool's complexity.

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?

Given the tool's complexity, the description is thorough: it explains the output format, ordering principles, failure handling, and how to get deeper explanations. With a rich output schema, 100% parameter coverage, and clear annotations, nothing an agent needs to invoke review_site correctly is missing.

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 the description does not add any parameter-specific meaning beyond what the schema already provides. The reference to using explain_rule with rule ids is the only parameter-related context, but that is a follow-up action rather than a semantic clarification of skip or focus.

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 opening sentence uses a specific verb-resource pair ('Read every page and stylesheet in a folder and return an annotated critique') and immediately scopes the action to the whole rulebook. This clearly distinguishes it from the sibling check-specific tools like check_copy or check_responsive.

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?

The title and description make clear this is the comprehensive whole-rulebook review, so the context for using it over per-check siblings is evident. It does not explicitly state when not to use it or name alternatives, but the 'whole rulebook' framing and the mention of using explain_rule as a follow-up provide solid situational guidance.

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

Deploy Server