Inspiration
A contract can tell you exactly what you are owed.
That doesn't mean getting it is easy.
When an obligation is missed, the person on the other side suddenly has another job: find the right clause, verify the breach, calculate the remedy, prepare the notice, submit the action, and keep enough evidence to prove what happened afterward.
AI can already explain a contract.
We wanted to see if the browser could do the harder part:
turn the obligation into action.
But that immediately created a second question.
If an agent can take consequential actions on your behalf, where should its authority stop?
That question became Advocate.
We built Advocate to let an agent do the tedious work of investigating and preparing an enforcement action, while reserving the final consequential decision for the human.
What it does
Advocate is a browser-native WebMCP enforcement simulation.
Our demo starts with a contract requiring an approved invoice to be settled within 15 calendar days. The invoice has remained unpaid for another 32 days, with $12,840 in principal at stake.
From there, Advocate runs one complete workflow:
Contract → Entitlement → Approval → Action → Receipt
The website exposes four WebMCP tools:
fetch_contract_clause(clause_id)
Finds the controlling contractual obligation.
compute_statutory_penalty(jurisdiction, delay_days, base_amount)
Calculates the simulated entitlement from structured claim data.
generate_enforceable_demand_notice(claim_payload)
Prepares the action the agent intends to take.
file_dispute_record(action_id, proof_hash)
Executes the simulated filing after authorization.
The first part can happen autonomously.
Advocate can inspect the contract, determine the breach, calculate the claim, and prepare the next step without repeatedly interrupting the user.
Then it stops.
Immediately before notice generation and filing, Advocate requires explicit human authorization.
That approval generates a SHA-256 proof tied to the exact execution intent, timestamp, and nonce.
Only after that authorization can the filing continue.
The completed run produces a receipt containing the action ID, filing timestamp, claim hash, authorization proof hash, statutory citation used by the simulation, ledger sequence, and final receipt hash.
So Advocate doesn't end with:
"The agent says it did it."
It ends with a record of what the user approved and what the system executed.
How we built it
The most important technical decision was to build the workflow around WebMCP instead of browser automation.
A traditional browser agent has to inspect a page, guess which DOM elements matter, click through the interface, and hope the website has not changed.
With WebMCP, Advocate exposes the underlying capabilities directly as typed tools.
Each of our four tools has a JSON schema defining exactly what the agent can provide and what operation the website will perform.
We register those tools against the current document.modelContext WebMCP producer API, with a compatibility path for the earlier navigator.modelContext surface.
We deliberately did not create one giant enforce_contract() tool.
Splitting the workflow into four tools makes every transition visible:
evidence → calculation → preparation → execution
It also gives the website a natural place to apply authorization before the consequential operation.
Every invocation feeds Advocate's telemetry stream with schema validation, typed inputs, execution state, outputs or errors, and latency.
Human authorization
The approval step is separate from the agent's reasoning.
When the user approves the proposed enforcement action, Advocate creates a SHA-256 proof from the execution intent, timestamp, and nonce.
That proof is carried into the filing step so the executed action can be associated with the authorization that permitted it.
Replay protection
Agent workflows retry.
Networks fail. Tools can be called more than once. An agent may even repeat an operation while reasoning.
For a consequential action, "just don't call it twice" is not a sufficient safety mechanism.
file_dispute_record is therefore idempotent by action ID.
Calling the same filing again does not create another record.
Receipt
After execution, Advocate generates a final receipt containing the important identifiers and hashes from the completed run and provides a downloadable PDF representation.
Verification
We added automated checks for syntax, WebMCP schemas and flow behavior, idempotency, and the production build.
The application has no runtime package dependencies and is deployed over HTTPS on Vercel, giving WebMCP the secure browser context it requires.
The result is intentionally small:
4 browser tools.
1 human authorization boundary.
1 consequential action.
1 inspectable receipt.
Challenges we ran into
The hardest problem was not getting WebMCP tools to execute.
It was deciding where the agent must stop.
If we asked for permission before every tool call, the agent would become little more than a complicated button sequence.
If we let the agent continue through the filing step without interruption, the user would no longer meaningfully control the consequential action.
The boundary we arrived at was:
Preparation can be autonomous. Execution requires authority.
That lets Advocate do the boring work while asking the human for a decision only when that decision actually matters.
The second challenge was making approval specific enough to be useful.
A boolean like approved = true tells us almost nothing. What was approved? Was it the same action that eventually executed? Could an old approval be reused?
We therefore bind authorization to the execution intent, timestamp, and nonce and carry the resulting proof into the filing.
The third challenge was retry safety.
Web and agent workflows are not perfectly reliable, so we had to design the consequential tool assuming duplicate calls could happen. That led us to make filing idempotent by action ID rather than treating retries as an edge case.
Finally, WebMCP itself is an emerging browser capability. We wanted the project to use the real producer model while remaining inspectable and testable during development, so we built a compatibility surface and a local runtime mirror alongside the canonical API.
Accomplishments that we're proud of
The thing we're most proud of is not any individual feature.
It is that the entire loop works together.
A single run can move from a contractual obligation, through four typed WebMCP operations, through an explicit human authorization boundary, into an idempotent filing, and finally into a receipt.
We also made the normally invisible parts of an agent workflow visible.
Judges and users can watch the tool name, schema validation, payload, latency, returned result, authorization point, and final receipt instead of having to trust a loading spinner.
And WebMCP is not decorative in Advocate.
If you removed WebMCP, you would have to redesign how the agent interacts with the application.
That was one of our goals from the beginning: build something where WebMCP changes the product itself rather than simply appearing in the technology list.
What we learned
The biggest thing we learned is:
A tool schema is not an authorization model.
WebMCP can tell an agent what a website is capable of doing.
It does not automatically answer whether the agent should be allowed to do it.
For consequential workflows we found ourselves thinking about four separate questions:
What can the agent do?
What does the agent intend to do?
What did the human authorize?
What actually happened?
Those sound similar, but they are different parts of the system.
We also learned that human-in-the-loop does not have to mean human-in-every-step.
The agent should be able to perform reversible investigation and preparation without constant confirmation. Human attention should be reserved for the boundary where authority actually changes hands.
Finally, we learned that retries and observability are not boring implementation details once agents can act.
A duplicated tool call or an invisible failure means something very different when the operation creates a real effect.
What's next for Advocate
Advocate today is a controlled enforcement simulation, not legal advice or a production dispute-filing service.
The next meaningful step is not adding more AI.
It is replacing the simulated boundaries with real ones.
That means connecting WebMCP tools to authenticated account and dispute APIs, moving authorization and receipt storage to a trusted server-side environment, using independently maintained jurisdiction-specific rules, strengthening receipt verification, and adding durable identity and policy controls.
We would also like to explore a reusable authorization pattern for consequential WebMCP actions so that the same idea could apply beyond contracts—to refunds, account changes, purchases, bookings, claims, and other actions where an agent can prepare the work but a person should retain final authority.
The larger idea behind Advocate is simple:
The web already knows what many of our agreements say.
WebMCP can help it act on them.
Advocate asks how we do that without giving away the final decision.
Built With
- javascript
- openai
- sha-256
- web-crypto-api
- webmcp
Log in or sign up for Devpost to join the conversation.