Why ViewCue exists

WebMCP gives a page a structured way to expose capabilities to an agent. That makes tool use more reliable than asking an agent to infer every action from pixels and DOM structure.

It creates a different human problem: a person can see the page change, but may not know what the agent is referring to, why a term matters, or which region is relevant.

ViewCue fills that small gap with UI clues.

The product boundary

ViewCue owns visual communication:

• target highlights;
• connector placement;
• short explanations;
• terminology context;
• validation and result clues;
• optional activity indicators.

The host application owns behavior:

• WebMCP tool definitions;
• the execute() callback;
• clicks, typing, and form submission;
• API calls;
• business-state changes;
• consent and destructive-action policy.

That boundary lets a tool remain useful to both an agent and a human without turning the clue layer into an automation controller.

Why not a tour library?

A tour assumes a predefined sequence and temporarily frames the product around the tour. WebMCP interactions are dynamic: the relevant target depends on the tool, input, current page, and result.

ViewCue therefore uses semantic target registration and small, event-driven clues instead of a tour script.