Inspiration

I am a product manager, not a software engineer, and I am building an HR application called LiquidHR using AI-assisted development with Codex (luna model only).

I was preparing to explore a traditional MCP server for LiquidHR when the WebMCP Challenge appeared. I decided to change direction and spend a day answering a different question:

What happens if the web application itself can teach an AI agent what it is allowed to do?

LiquidHR Agent Workspace is the result.

What it does

The project demonstrates a people manager and a browser agent preparing the same employee development conversation together.

The application initially exposes three WebMCP capabilities:

  • find an employee within the manager's scope
  • retrieve that employee's development context
  • prepare a grounded development-conversation draft

The manager can ask, in natural language, for a development conversation to be prepared for Sophie.

The agent uses the capabilities exposed by the LiquidHR website to find Sophie, retrieve her current goals, open actions and skill-development signals, and create three grounded discussion topics.

The manager sees that exact same draft in the human interface.

This is not a chatbot creating a separate copy of HR data. The human interface and the agent operate on the same application state.

State-aware WebMCP capabilities

One of the ideas I especially wanted to explore was whether the capability surface itself could follow the workflow.

Initially, the application exposes three tools.

Once a valid conversation draft exists for the currently selected employee, LiquidHR dynamically exposes a fourth WebMCP capability:

add_follow_up_action

The agent can then add a bounded follow-up action to the existing draft.

When the manager finally reviews and saves the conversation, that temporary capability disappears again.

The capability lifecycle is therefore:

3 → 4 → 3

The application's state determines what the agent can do next.

Human judgment remains human

Final save is deliberately not exposed as a WebMCP capability.

The agent can retrieve context, organize information, prepare the draft and add a follow-up action, but the manager must perform the final Review & save action in the human interface.

That creates a deliberate human-confirmation boundary around the judgment-bearing transition.

The agent doesn't bypass the application. The application teaches the agent how to use it safely.

Why WebMCP

Without WebMCP, a general-purpose assistant often has to work through a second interface, copied data, brittle browser interaction or a separately designed API.

WebMCP lets the web application expose a structured capability contract directly to the browser agent.

The tool names, descriptions, input schemas, annotations, authorization rules and lifecycle are defined by the application itself.

That means the agent does not have to guess which buttons to click or infer hidden application state.

It receives capabilities that reflect what the application can safely do at that moment.

Shared application architecture

The human UI and the WebMCP callbacks use the same:

workspace facade → actor and manager-scope policy → domain service → shared draft state → synthetic repository

Employee lookup is restricted to the fictional manager's authorized scope. Direct employee context access is validated again before information is returned.

The project also contains an out-of-scope synthetic employee for authorization testing.

All company, employee and activity data is fictional.

Implementation

The project uses the imperative WebMCP API through:

document.modelContext.registerTool(...)

The application uses object JSON Schemas, tool descriptions, annotations, structured results and lifecycle-managed registrations.

The first three capabilities remain available for the workspace lifecycle.

The fourth capability is dynamically registered only when a valid matching draft exists and is removed after the draft is discarded or saved.

The application is built with Next.js, React and TypeScript and deployed publicly on Vercel.

No production HR backend, real employee data or external AI API is embedded in the challenge application.

What I proved

The live end-to-end flow demonstrates:

  • real WebMCP capability discovery and execution
  • natural-language interaction with application-defined tools
  • scoped employee access
  • grounded development context
  • shared state between human and agent
  • dynamic state-aware capabilities
  • a visible activity trail
  • a deliberate human confirmation boundary

The complete natural-language flow was also tested against the public application using ChatGPT's browser with a WebMCP-capable runtime.

Potential impact

Managers frequently spend time gathering goals, open actions and development signals before a useful conversation can even begin.

An agent can remove much of that repetitive retrieval and preparation without taking over the manager's judgment.

The same pattern can extend far beyond HR: applications can expose safe, contextual capabilities to agents while retaining their own business rules, permissions, workflow state and human approval boundaries.

Human judgment. Agent speed. One shared HR workspace.## Inspiration

Built With

Share this project:

Updates

Submission history