One action, two interfaces: keep WebMCP and your UI in sync

Copying a button handler into a tool callback feels quick, but the copies diverge when validation, pricing, permissions, or telemetry change. The agent path may skip confirmation or update the server without updating the page. The UI path may gain an important constraint the tool never receives.

Drift is both a reliability and security problem. Reviewers can no longer reason about one action boundary, and evidence from one path says little about the other.

Define a domain operation that accepts validated intent plus trusted actor context. The UI adapter translates form state; the WebMCP adapter translates structured tool input. The domain operation makes the authorization and state decision exactly once.

When a tool changes application state, update the same store or query cache the UI uses. If the server is authoritative, re-fetch or invalidate the relevant record. Avoid maintaining a private agent-only shadow state that the person cannot inspect.

Make loading, conflict, and error states visible. An agent call that is still pending should not leave the UI looking idle, and a rejected mutation should not be represented as a completed optimistic update.

WebMCP is an enhancement, not the only door. Feature detection should decide whether tools are registered without hiding or disabling the human workflow. This protects users in unsupported browsers and keeps the product testable with ordinary accessibility tooling.

The complete UI also provides an ethical fallback when an agent cannot establish intent or permission. A person can take over at the exact visible state instead of restarting the task somewhere else.

Run equivalent journeys against a deterministic fixture. Assert that both paths enforce the same constraints and reach the same postconditions. The action counts can differ; the business outcome and safety rules should not.