MCP

Not built

The four servers described in this section do not exist yet. What is written here is the part worth reviewing before any of it is implemented: what each one would do, where its boundary sits, and which decision it must hand back to a person.

Automation comes last in this hub on purpose. A model multiplies whatever discipline it finds: applied to an interface with two enforced contracts, it removes real mechanical work; applied to one without them, it produces plausible interfaces faster than anyone can review them.

The four servers

Server	Does	Must not decide
Token sync	Moves design decisions from the source into every consuming format, and reports drift	Whether a token should change
Component scaffolding	Generates a component, its stories, its tests and its docs from a contract	What the contract says
Journey to scenarios	Turns an example map into draft scenarios with the same values	Whether the scenario is right
Accessibility audit	Sweeps for the violations a rules engine cannot express, and explains them	Whether a finding is acceptable

The line

The same line in every case, and it is drawn per task rather than once:

The machine does the mechanical half. The human keeps the half where somebody has to be accountable for the answer.

The four rows above are all of one kind: they take a decision that has already been made and written down, and propagate it. None of them makes a decision that was not made.

That is why they sit at the end of this site. Every one of them requires a contract to work from — and a team that has the contracts already has most of the benefit, with these servers as an accelerator rather than a substitute.

Why semi-automated

Full automation of a design activity produces plausible output with nobody accountable for it. No automation wastes people on work a machine does better.

The interesting part is where the line falls, and it is not fixed. Scaffolding a component from a contract is fully mechanical. Deciding that a state exists is not, and never will be — it comes out of example mapping, from people looking at what happens to a person when a rule does not hold.

Reviewing generated interface code

One practice worth stating, because it is where this goes wrong first.

Generated code is reviewed against the contract, not against taste. Does it use the tokens rather than values? Does it implement every state in the contract? Does it announce what it is supposed to announce? Does it pass the interaction tests that were generated from the same contract?

Those questions have answers. “Does this look right” does not scale to the volume a model produces, and a reviewer asked that question repeatedly will start answering yes.