AidPath Agent Bridge

Inspiration

Rule-heavy support and public-service websites are difficult for both people and browser agents. A person may need to understand many conditions, while a generic agent often has to scrape rendered text, guess what controls mean, and automate fragile clicks. We wanted a safer collaboration model: the human controls the facts, while the agent receives explicit, typed capabilities.

What it does

AidPath Agent Bridge is a WebMCP-native, privacy-first support navigator. It exposes six structured tools that let an agent discover illustrative support options, analyze a structured case, explain one option, compare alternatives, load a safe demo case into the visible UI, and prepare a next-step checklist.

The agent does not decide eligibility. Both the human interface and the WebMCP tools call the same deterministic JavaScript rule engine. Matched and missing conditions remain visible and auditable, and meaningful agent actions are shown in an activity log.

Why WebMCP is the right fit

Without WebMCP, an agent must infer intent from DOM structure, scrape result cards, and depend on brittle selectors. With WebMCP, the website publishes stable domain capabilities with JSON Schema contracts. The human can inspect or correct facts while the agent performs structured orchestration. This makes the experience faster, more reliable, and easier to audit.

A workflow that previously required repeated reading, copying, clicking, and re-checking can become a collaboration: the person reviews sensitive inputs and final evidence; the agent lists options, evaluates the same deterministic rules, compares alternatives, and prepares actionable next steps.

How we built it

The application is a standalone HTTPS static web app. It registers six tools with document.modelContext.registerTool(...), uses typed JSON Schemas, and annotates read-only operations with readOnlyHint. A local intent layer helps organize free text, but authoritative conditions remain deterministic. There is no backend, account, or persisted user profile.

The app degrades gracefully when WebMCP is unavailable and remains fully usable as a normal website. We also created a visible capability status and agent activity log so the user can understand when structured agent interactions occur.

Challenges

The key design challenge was avoiding an architecture where the LLM silently becomes the decision-maker. We separated agent orchestration from rule evaluation and made the same deterministic functions serve both the human UI and the WebMCP layer. We also documented the distinction between prior AidPath work and the new WebMCP extension with timestamped commit history.

Native WebMCP verification

On September 3, 2026, the deployed HTTPS app was tested in Chrome 151 on Windows with chrome://flags/#enable-webmcp-testing enabled and Chrome relaunched. Chrome's native document.modelContext.getTools() discovered all six tools, and native document.modelContext.executeTool(...) successfully executed all six: 6/6 discovery and 6/6 execution PASS. The student case produced Student Stability Bridge 3/3 as the top deterministic result; Housing Stability Support 2/3 exposed Core documents ready as the missing condition; visible agent activity was recorded in the workbench log.

What we learned

WebMCP is most valuable when a site exposes meaningful domain actions rather than simply mirroring buttons. A small set of well-designed tools can replace a large amount of fragile UI automation while preserving human review.

What's next

This challenge build uses explicitly illustrative programs. A production version would connect to verified official sources, attach source URLs and effective dates to every rule, version rule changes, and require human review before consequential use.

Built With

• github
• html5
• javascript
• pages
• webmcp