plate
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PLATE_HOME | No | Your Plate home directory. Defaults to ~/.plate. Stores captures, cache, and saved work. |
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 | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| plate_resolveA | Resolve every visual noun in a brief to a real asset, or to an honest null. Call this BEFORE writing a line of scene or page code. Live sources that need no account: Poly Haven for HDRIs and PBR materials, the Quaternius Universal Animation Library for rigged humans, Google Fonts for type. A noun with no real asset (a face, a photograph, a brand mark) comes back resolved:false with the reason. Draw only architecture; never draw a body, a material, a font or a mark. |
| plate_kitA | The manifest for a local Plate kit: every file with its size, licence and local path, the exact upstream download URLs, how to load it, and the gotchas that cost hours. Call with no name to list the kits. |
| plate_stackA | The finishing stack for an engine, in order: the exact script tags, the code for each step, why each step exists, and the gotchas. 'three-r128' for a 3D scene, 'web' for a landing page, 'video' for motion. The stack is not the last step; build it in before judging anything. |
| plate_checkA | The tell checker. Run it on the output, never on the prompt. Given an .html it counts primitives against loaded assets and flags the web tells: gradient hero backgrounds, emoji in headings, pill buttons, purple, a centred column under a nav, no font loaded, three.js with no post-processing. Given a .png it reports size and mean luminance and flags a dead frame. It says unknown where it cannot tell. |
| plate_pairB | Composite two frames into the before/after image the product ships everywhere: stacked vertically on black, a label above each, nothing else on the image. |
| plate_briefA | Create a structured design starting point from a prompt, domain, style and constraints. Deterministic templates, not image generation or visual analysis. Returns hierarchy, candidate visual nouns, next tool calls and verification criteria. |
| plate_catalogA | Search locally available finishing stacks, kits, paid-library presets and recipes. Reports missing or invalid library state honestly; no network or model call. |
| plate_licenseA | Report local Plate activation status without exposing the key. The Starter reports an unactivated install honestly. |
| plate_inspectB | Return an actual local screenshot as an MCP image block for the agent to visually inspect, plus objective image facts. |
| plate_captureA | Capture a running local website with an isolated Chromium browser. Returns an actual MCP image plus overflow, image loading and page error evidence. No authenticated sessions. |
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 10 tools
Most tools have clearly distinct purposes: resolve assets, inspect kits, get finishing stacks, check output, capture pages, pair frames. The only mild boundary is between plate_catalog and plate_kit (both deal with local kits) and between plate_inspect and plate_capture (both return images), but their inputs and outputs are different enough to avoid real confusion.
All tools share the plate_ prefix and snake_case style, which gives visual consistency. However, the second element mixes verbs (resolve, check, pair, inspect, capture) with nouns (kit, stack, brief, license), so there is no predictable verb_noun pattern across the set.
Ten tools is a well-scoped set for a design/build assistant. Each tool serves a distinct step in the workflow from brief through asset resolution, stacking, checking, capture, and final pairing, with no obvious dead weight.
The tool surface covers the full intended lifecycle: create a brief, resolve visual nouns, gather kits and stacks, validate output, capture/inspect results, and produce before/after composites. Minor gaps exist around explicit serving/building or license activation, but these seem outside the server's stated responsibility.