Build journey
Teaching web apps to speak agent.
What WebMCP is, why it matters, and how we built a Strands-powered WebMCPify Core Agent without handing an AI unchecked control of the repository.
Let the agent do the repetitive work. Keep approval, execution, and evidence under human control.
First: what is WebMCP?
A small menu of actions for an agent.
A web page already knows how to search its catalogue, submit its form, or check an order. An AI agent usually sees only the interface and has to guess its way through buttons and fields.
WebMCP proposes a structured alternative. A page can publish named tools such as search_products or check_order, with clear descriptions and strict inputs. The website still performs the action and updates its visible state; the agent gets a dependable handle instead of a pixel hunt.
The missing layer
A callable website still has to be built carefully.
Someone must discover the real user actions, design honest schemas, place each tool on the right page, identify authentication and backend requirements, test the implementation, and prove the result. A generic coding agent can draft code, but it should not silently approve and apply its own changes.
That is the job we chose for WebMCPify Core Agent: make a web developer dramatically faster at preparing an existing application for agents, while preserving a real decision point.
The build journey
From a CLI workflow to a professional agent.
Core already had the hard workflow pieces: repository discovery, isolated generation, security review, exact-patch approval, build validation, browser testing, repair, and evidence. For the Agents for Humans Hackathon, we added Strands Agents SDK as the orchestration layer.
Discover
Read routes, forms, handlers, APIs, auth signals, and existing WebMCP tools.
Draft
Generate the smallest grounded change inside a disposable repository copy.
Review
Show the proposed tools, tests, security findings, and exact source patch to a person.
Why Strands
The agent gets tools, not a skeleton key.
The Strands agent connects to Core through MCP and receives a deliberately small tool surface: analyze, generate, audit, open review, read review status, apply, and test. It maintains the workflow and conversation, but it does not receive unrestricted shell access or a direct repository editor.
This separation matters. Strands decides which allowed workflow step comes next. Core owns the disposable workspace, patch identity, approval evidence, target build, browser execution, and verification artifacts.
The decision that shaped the build
The agent cannot approve itself.
A chat message saying “approved” is not enough. Core opens a separate local review page containing the tools, tests, security findings, and exact source diff. Only that interface can persist approval. The agent can check the resulting status, and Core will apply only the patch identifier bound to that decision.
If the draft changes, the old approval becomes stale. If the build fails, Core rolls back. After a successful build, browser checks verify observable application state rather than trusting a confident model response.
What works today
A tested workflow, with honest limits.
The Strands package, MCP bridge, non-blocking review handoff, approval-status tool, architecture, and setup documentation are implemented on the public hackathon branch. Focused agent tests, Core's MCP verification, and the complete Core test suite pass locally.
A live agent run needs credentials for a Strands-supported model. Our current demo path uses Amazon Bedrock. The automated safeguards can be tested without cloud credentials; the live model loop cannot.
What comes next
Make the web actionable—and keep people in charge.
WebMCP can give agents a clearer way to use websites. Our work is to make that path practical: Core creates and verifies, Search discovers, Guard protects the connection and execution, and Cloud monitors what changes.
Sources and code