MCP reference
Everything the Sprout MCP server exposes. If you just want to connect, the Connect page is the shorter read.
The endpoint
Open, read-only, no login. Everything it serves is already public on this site.
claude mcp add --transport http sprout https://aceve.design/api/mcp
Anything that speaks MCP over HTTP works the same way — Cursor, Windsurf, Claude Desktop, VS Code, a claude.ai custom connector. Point it at https://aceve.design/api/mcp.
Prompts
Five workflows. The design team's method, runnable.
A prompt is a ready-made workflow with arguments. In Claude Code each one is a slash command, /mcp__sprout__build_ui and so on; elsewhere they appear in a prompt picker.
Worth understanding, because it explains what you will see happen: a prompt returns instructions, not an answer. It cannot call a tool itself. So each one hands the model a numbered plan of which tools to call and in what order — which is why invoking one is followed by a burst of tool calls before any output appears. That plan is the part the design team controls.
Designs or builds a screen. Fetches the prototyping playbook narrowed to your platform and persona, the ready-component list, the theme CSS and the anti-slop checklist before writing anything. Refuses to start until platform and persona are known.
Reviews against WCAG 2.2 AA, the ten Nielsen Norman heuristics layered with the eight Aceve principles, tone of voice, Simple First and the ethics checklist. Every contrast ratio is measured with check_contrast, never estimated.
Rewrites copy for a specific surface — button, error, empty state, label, toast, dialog, notification. Returns current, proposed and why, one row per string.
Applies the visual identity to a deliverable. Resolves the right logo file for the background, the right typeface for the format, and every colour to a token.
Finds hardcoded hex, pixel spacing and hand-written shadows, and maps each to the token it should have been.
Every argument is optional. Leave one out and the prompt asks for it rather than guessing — and a value it does not recognise becomes a note telling the model to check with you, never an error.
Tools
Sixteen. The model calls these itself; you rarely name one.
| search_tokens | query, category | Every token by name, CSS variable or role. Light and dark values. |
| get_theme_css | theme, format, prefix | The whole custom-property set, ready to paste. Light by default; both is around 20 kB. |
| find_token_for_hex | hex, tolerance | Which token a raw colour should have been. Ranked by perceptual distance, so near-identical shades sort first. |
| check_contrast | foreground, background, size, theme | The measured WCAG ratio and whether it passes AA and AAA. Takes token names as well as hex. |
| search_icons | query, limit | Find the exact name. There are 522, and the names are rarely what you would guess. |
| get_icon | name | SVG markup for one icon, with a did-you-mean on a miss. |
| list_components | status | The coverage board — what is ready, beta, planned or deprecated. |
| get_component | id | Status, shipped-in version and docs URL for one component. |
| get_component_source | id, include | The real prop API of a React primitive, plus where the Figma component and the code disagree. |
| get_persona | id | One of the four people Aceve designs for — environment, goals, pains, input habits. |
| get_product | id | An Aceve product, with a starting guess at platform and primary persona. |
| get_logo | brand, lockup, background | The right logo file for a given background, and its URL. |
| get_playbook | topic, platform, persona, product, scope, format, surface, section | How we prototype, review, write or brand — narrowed to what you asked for. Returns markdown. |
| get_checklist | kind, severity | Accessibility, anti-slop, ethics, release or review-dimensions. Each item carries severity, reason, fix and source. |
| get_version | releases | Current version, links and recent changelog. |
| get_guidelines | topic | The seven voice rules and the type scale. |
Resources
The same material, addressable as documents.
For clients that surface documents rather than tool calls. These are the default views — when you want a playbook narrowed to a platform and persona, call get_playbook instead, which takes arguments.
| sprout://version | application/json |
| sprout://playbook/{prototyping | ux-review | brand | content} | text/markdown |
| sprout://checklist/{accessibility | anti-slop | ethics | release} | application/json |
| sprout://tokens/light.css and dark.css | text/css |
| sprout://personas | application/json |
| sprout://component/{id} | application/json |
| sprout://icon/{name} | image/svg+xml |
What the playbooks replace
These used to be personal claude.ai skills.
Four playbooks were ported into this repo from skills that lived on one person’s account, where nobody else could update them and no product team could reach them.
| Prototyping playbook | The Aceve UI Builder skill — intake, platform rules, anti-slop, quality gates. |
| UX review playbook | The UX Reviewer skill — six dimensions, severity flags, output contract. |
| Brand playbook | The Aceve Branding skill — palette, logo usage, typography by format. |
| Content playbook | The tone-of-voice reference — microcopy patterns per surface, market emphasis. |
They are ordinary source files now, so changing how we review or what counts as done is a merge request in the design system repo. Everyone gets the new version on the next deploy. That is the whole point of moving them.
The port also settled four places where the old skills disagreed with this site or with each other — three drifted hex values, the minimum touch target, how many design principles there are, and whether the palette contains any purple. The site won each time, which is why the playbooks read tokens at call time rather than restating values.
Logging and privacy
What is recorded when you use it, and what is not.
Each call writes one line to the Vercel runtime log: the tool name, how long it took, how large the response was, and any arguments that are fixed choices — a topic, a platform, a format.
Free-text arguments are never logged. Whatever you paste into a brief, a review target or a search query is recorded only as its length, because those fields can contain anything and the logs are readable by everyone with project access. Nothing identifies you: no IP address, no user agent, no account.
It is worth being plain about the limit. Runtime logs are live-tailable and searchable for a short window, so this answers “is anyone using it” and “what is slow”. It does not answer “how many reviews did we run last month”. That would need somewhere to keep the data, which we deliberately have not built.