pixelpact
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| extract_contractA | Extracts a visual contract from a reference URL and saves it as JSON at outputPath. Call this once per reference design, before check_implementation or diff_pixels can be used, since both need a saved contract to compare against. Pass screenshotDir to also capture reference screenshots, which diff_pixels requires later. Returns a summary: the element count per viewport, any extraction warnings, and the path the contract was written to. |
| check_implementationA | Measures an implementation URL against a previously saved visual contract: box position and size, computed styles, hover and focus states, and pseudo-elements. Call this after building or changing a UI to verify it matches the reference without a human looking at it. Needs contractPath from a prior extract_contract call. Returns a formatted deviation table (capped at 40 rows, with a note on how many were left out) plus the numeric totals, the pass rate, any missing selectors, and ok, which is true only when nothing deviated and nothing is missing. |
| diff_pixelsA | Renders the implementation URL and compares it pixel by pixel against the reference screenshot stored in the contract. Use this for a stricter visual check than check_implementation, after the structural check passes or when a subtle rendering difference is suspected. Requires the contract to have been extracted with screenshotDir set. Returns the percentage of differing pixels, the threshold it was compared against, ok, and the filesystem path of the generated diff image. |
| read_contract_summaryA | Reads a saved contract file and describes it without opening a browser or making any network request. Use this to inspect what a contract covers, for example before deciding whether diff_pixels is possible, since that needs screenshots to already exist. Returns the original source URL, when it was extracted, the viewports it covers, the element count per viewport, whether reference screenshots exist, and any warnings recorded at extraction time. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
Each tool has a distinct role in a clear pipeline: extract_contract (capture), check_implementation (structural compare), diff_pixels (pixel compare), and read_contract_summary (inspect metadata). The descriptions explicitly differentiate the two comparison tools and state their prerequisites, leaving little chance of misselection.
All four names follow a consistent snake_case verb_noun pattern (extract_contract, check_implementation, diff_pixels, read_contract_summary). The convention is predictable and readable throughout.
Four tools is a tight, well-scoped set that maps cleanly onto the extract-then-verify workflow, with no redundant operations. It is slightly lean — no management tools (list/delete/update contracts) — but each tool clearly earns its place.
The core lifecycle is covered end to end: extract a contract, structurally verify, pixel-verify, and inspect a saved contract. Minor gaps exist (no way to list or delete contracts, no threshold/viewport configuration tool), but these are workarounds an agent can manage.