Agent-Native Concierge for WebMCP

Inspiration

Most websites are still designed as pages for humans first, then agents are expected to interpret menus, labels, buttons, and layout after the fact. That creates friction: agents can miss context, users do not want to learn every tool, and high-risk actions need clear boundaries.

Agent-Native Concierge explores the reverse design pattern: start with an agent-readable action contract, then render a clean human interface from that structure.

What it does

The demo is a WebMCP-enabled concierge website. A user starts from a simple goal, such as creating a birthday card set. Instead of showing a long tool menu, the site shows outcome cards: different possible results, what each one produces, and what level of confirmation is required.

The page exposes structured WebMCP tools for agents:

• get_agent_contract describes the site purpose, allowed actions, limits, and confirmation rules.
• get_action_risk_ladder returns a five-level safety ladder, from read-only actions to actions that must be handled by a human.
• get_outcome_gallery returns result-first examples so the user can choose outcomes, not tool names.
• create_action_dry_run creates a safe simulated action plan before anything risky is executed.

How we built it

The project is a static HTML, CSS, and JavaScript demo with WebMCP metadata and tool handlers. The human interface stays intentionally minimal: a concierge input area, outcome cards, and a safety panel. The agent interface is explicit: tools expose stable names, risk levels, expected inputs, outputs, and confirmation requirements.

Challenges we ran into

The main challenge was avoiding a normal website-with-chatbot pattern. The goal was not to make an agent guess where buttons are. The goal was to let the website declare its action structure clearly enough that an agent can operate safely and explain its choices back to the user.

Accomplishments that we're proud of

The demo shows three product principles:

1. Result-first interaction: users choose visible outcomes instead of learning tool names.
2. Agent-readable safety: every tool has a risk level and confirmation rule.
3. Dry-run before action: the agent can show what it plans to do before any external effect.

What we learned

WebMCP is useful because it gives websites a way to expose their capabilities in a structured, inspectable form. That makes agent use more reliable than screen-reading alone, and it makes human oversight easier.

What's next

Next, this pattern can be expanded into more vertical demos: education, legal intake, design workflows, and customer service. Each vertical can keep the same safety ladder while exposing its own domain-specific outcome gallery and WebMCP tools.

Built With

• css
• html
• javascript
• webmcp