Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Squint open http://localhost:5173 and tell me which element is visually broken"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Squint is an MCP server that examines a rendered web page by crossing what the browser reports (DOM/CSS) with what is actually painted (pixels), and reports the visual problems it finds without needing a baseline.
It is built for coding agents that have just produced UI and need to know whether the page actually looks right: which element is broken, and what the evidence is.
Pre-release. Squint is not on PyPI yet, so uvx squint-mcp does not work today. For now it runs from a checkout.
The server currently exposes one tool:
Tool | Input | Output |
|
| server |
inspect_element and detect_visual_bugs are next. See docs/ROADMAP.md for the delivery slices and docs/SPEC.md for what v0.1 will contain.
Related MCP server: UI Analyzer MCP Server
Requires uv. uv installs Python 3.12 for you if it is missing.
git clone https://github.com/sh4wty1/squint-mcp.git
cd squint-mcp
uv sync
uv run squint-mcpThe server speaks MCP over stdio, so started by hand it just waits for a client. To use it from an MCP client, register the command with the path to your checkout:
{
"mcpServers": {
"squint": {
"command": "uv",
"args": ["run", "--directory", "/path/to/squint-mcp", "squint-mcp"]
}
}
}Then call ping to confirm the connection.
One command each:
uv run pyright # typecheck (strict)
uv run ruff check # lint
uv run ruff format --check # format check
uv run pytest # testsTests drive the server through an in-memory MCP client, the same surface a real client uses. See CONTRIBUTING.md.
CONTEXT.md: domain glossary (Capture, Check, Finding, Profile, Audit)
docs/SPEC.md: v0.1 specification
docs/adr/: architecture decision records
Confirm the server is alive.
Returns the server name and version, and echoes `message` when given.
| Name | Required | Description | Default |
|---|---|---|---|
| message | No |
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| message | Yes | |
| version | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the agent knows this is a safe, purely local read. The description reinforces that nothing is mutated, and the mention of the echo behavior adds modest context, but it doesn't discuss auth, rate limits, or failure modes beyond what the annotations and output schema already imply.
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?
Two short sentences, the purpose first and the return/echo behavior second. Nothing is padded and no sentence is wasted.
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 one-parameter, zero-required liveness tool with an output schema documenting the return payload and annotations covering the safety profile, the description supplies everything an agent needs: what it checks, when it is useful, and how the input is handled.
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 description coverage is 0%, so the description must compensate for the single `message` parameter — and it does, explaining that the value is echoed back when supplied, which clarifies it is an optional round-trip probe rather than a filter or identifier. It stops short of noting the null default explicitly.
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 object ('confirm the server is alive') plus the observable effect ('returns the server name and version'). An agent immediately understands this is a liveness/health probe, and there are no siblings to disambiguate against.
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?
The name and description jointly signal the use case: verifying server availability before or after other operations. There are no alternatives to name and no explicit when-not condition, but for a single sibling-less health-check tool the context is unambiguous.
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.
v0.1.0pingScored across 1 tool
With only a single tool there is no possibility of overlap or misselection, so the lone tool is trivially unambiguous. However, there is no meaningful set to disambiguate among, so it does not demonstrate strong design.
The single name 'ping' is clear and conventional for a health-check, but with only one tool there is no pattern to establish consistency and no verb_noun structure to evaluate.
A server exposing only one trivial liveness tool is far too thin for any real purpose. The count is essentially a minimal stub rather than a scoped toolset.
The surface offers only a ping with no domain operations at all, leaving no create/read/update/delete or lifecycle coverage. Any actual task would be a dead end.
Playwright selector risk checks with healing suggestions and receipts.
Browser-backed QA with evidence and fix-ready reports for coding agents.
Capture screenshots, detect visual regressions between page versions, and analyze with AI.
Browser-based QA for AI-built software. Test pages with real browsers via agents.
