MCPation

What I built

MCPation is a browser-native WebMCP pre-flight gate for Codex. It is a deliberately scoped MVP exploring a new category of agent-native DevTools: many of the useful, structured interactions people associate with an installed MCP can happen directly in a web page, without installing a server, daemon, extension, or API key. The user grants access to exactly one workspace folder, and the agent works inside that visible boundary.

Why WebMCP is a good fit

Agent configuration tends to grow quietly. Duplicate MCP servers, disabled entries, invalid endpoints, package drift, and layered Codex instructions can make it hard to know what an agent will inherit before it runs. MCPation turns that uncertainty into a shared, inspectable pre-flight step. The first pass is read-only: it reads an allowlisted set of configuration, package, and instruction metadata, then returns a readiness score, concrete findings, and an evidence graph connecting artifacts to those findings.

This creates a better experience for both sides. A person gets an understandable report instead of guessing through configuration files. Codex gets a structured tool surface instead of having to click through an unfamiliar UI. They see the same state, while the person stays in control of every write.

What the real demo shows

The demo workspace is intentionally seeded with reproducible problems so the workflow has something meaningful to solve. The browser flow itself is real, not a mocked result: MCPation scans the selected folder, identifies duplicate JSON server entries, an invalid endpoint, and a disabled server, explains the evidence, and builds a supervised hardening plan. I choose the exact duplicate cleanup, explicitly approve it, grant the browser write permission, and MCPation creates one sibling backup before removing only those selected keys. It then rescans and shows the new readiness score and the restorable snapshot. More complex commands, TOML, policy, and instruction changes remain review items rather than being silently changed.

The important collaboration is that a person can decide what is safe while an agent can inspect, explain, and verify the result through the same page. That combination would be difficult with a normal UI-only workflow and risky with an unbounded local tool.

How WebMCP is implemented

The page registers a concrete document.modelContext surface with tools for scanning the workspace, reading the declared MCP/package inventory, reading the instruction chain, explaining findings, building a hardening plan, requesting a bounded host handoff, submitting a sanitized host snapshot, applying the selected deterministic cleanup, verifying the result, and explaining the exact access scope. Read-only tools are annotated with readOnlyHint; the apply tool accepts only action IDs from the latest plan and requires confirm: true. The visible browser control owns the permission prompt, backup, write, and rescan. When a browser cannot expose native WebMCP, MCPation says so explicitly and shows a local preview instead of pretending that native tools are available. The same app works in Codex's in-app browser and in Chrome with WebMCP enabled.

Scope and honesty

This is a deliberately scoped MVP for a new category of agent-native DevTools, built under a short hackathon deadline. I chose one deterministic, reversible cleanup and a strong evidence trail instead of pretending to support every possible workspace utility. With more time, the same pattern could extend to onboarding, compliance checks, migrations, review gates, and other supervised workflows. The point is that a useful MCP-like experience does not necessarily need installation when WebMCP can publish a scoped page surface and the user grants explicit permission.

A note about the English text

English is not my native language. I understand and speak it fluently, but expressing myself precisely in written English takes me much longer. I used AI to help draft, translate, and polish this description so it would be clear to the judges; the product decisions, implementation, testing, and claims in this submission are based on the project that is actually running. I am genuinely grateful to be able to participate in this hackathon. I discovered it rather late and would have loved more time to explore richer utilities, but I am very happy to share this concept and what I managed to build.

Built With

• webmcp