Open Application Desk

A WebMCP application workspace that audits live drafts, requests applicant-owned facts, stages visible fixes and submits only the exact hash-bound revision the applicant authorizes.

Comment

Inspiration

Near a real submission deadline, I was reconciling official rules, deployment links, repository evidence, test results, and draft claims across several tabs. One stale claim nearly survived into the final submission.

That experience exposed a deeper problem: application portals are built for clicking, not collaboration. An AI agent must scrape text and imitate UI actions, even when one invented fact or accidental submission could cost someone an opportunity.

I built Open Application Desk around a safer idea: the agent prepares, the applicant supplies the facts, and only the applicant authorizes the exact submission.

What it does

Open Application Desk lets an applicant and an AI agent work on the same live application. The agent can inspect the requirements, find blockers and propose corrections, but it cannot apply changes, invent applicant facts, approve the application or even submit an unapproved draft.

The page publishes five typed WebMCP tools that let an agent:

  1. Read the program requirements and exact live draft.
  2. Run a deterministic readiness audit without editing anything.
  3. Stage a bounded patch as a visible before-and-after diff.
  4. Prepare a passing revision for exact review.
  5. Submit only a review already authorized by the applicant.

The reference journey begins at 3/10 ready with seven blockers. The agent proposes three bounded corrections and the page previews the result as 3/10 → 7/10, but nothing changes until the applicant clicks Apply proposed changes.

When an applicant-owned fact is missing, a contextual tool temporarily appears. Instead of allowing the agent to invent an answer, the page asks the applicant directly. After the applicant shares the answer, that tool disappears.

When all 10 checks pass, the page creates a five-minute approval tied to a digital fingerprint of that exact draft. Any later edit cancels the approval. The applicant approves that version and only then can the agent submit it and receive one receipt.

The OpenAI API supplies the reasoning; WebMCP lets the page publish its live tools, state and boundaries.

How we built it

I built the application with React, TypeScript, Vinext, Zod, WebMCP, Vitest, Playwright, and OpenAI Sites.

The human interface and WebMCP tools use the same workspace controller and domain rules. There is no separate agent-only state. Tool inputs use closed JSON Schemas and runtime Zod validation.

The deterministic audit checks the live revision and performs bounded verification of public GitHub repository metadata and license availability. Proposed edits are evaluated against an in-memory candidate before the page shows their projected readiness, without mutating the real draft.

prepare_submission re-audits the expected revision and creates a short-lived review bound to its SHA-256 draft hash. Any later edit invalidates that review. Submission also uses a browser-provided exclusive lock so repeated calls for the same approved review reconcile to one receipt.

For the Chrome demonstration, I built an optional open-source developer inspector. It discovers the page’s registered WebMCP tools, maps their schemas to OpenAI Responses API functions, and returns structured tool results to the model. The API key remains in the local Chrome session.

Challenges we ran into

The hardest challenge was separating assistance from authority. It was easy to build an agent that could change fields; it was much harder to prove that it could not apply its own proposal, invent applicant facts, attest, or authorize submission.

The contextual human handoff also required careful design. A WebMCP call should not remain open indefinitely while waiting for a person. The tool therefore returns an immediate awaiting_human result, the page collects the answer, and the agent re-reads the updated live state.

WebMCP is still an emerging browser capability, so I also had to distinguish between ordinary browsers, ChatGPT’s supported in-app browser, and Chrome with WebMCP enabled. The developer inspector made discovery and every tool call visible during testing and recording.

Accomplishments that we're proud of

  • A deterministic audit that changes zero application fields.
  • A visible readiness projection before any proposed edit is applied.
  • A contextual tool that appears only when a specific human-owned fact is missing.
  • An agent that asks instead of inventing.
  • A five-minute review bound to the exact draft revision and SHA-256 hash.
  • Native human authorization before submission becomes possible.
  • A single receipt recording seven blockers caught, 10/10 readiness, and the reviewed hash.
  • One shared controller for both the human interface and WebMCP tools.
  • Automated domain, component, WebMCP-registration, and browser-journey testing.

The project was created during the submission period, beginning August 26, 2026. Its public commit history documents the implementation through the final challenge build.

What we learned

The most important lesson was that WebMCP is not the reasoning engine. Its value is allowing a webpage to publish a precise contract for what an agent can see and do.

Structured tools are also not enough by themselves. Meaningful safety comes from combining typed capabilities with deterministic validation, state-dependent availability, visible human controls, revision checks, expiration, and exact-artifact authorization.

I also learned that a tool disappearing can be as meaningful as a tool appearing. Once the applicant supplies the missing fact, the agent no longer needs permission to request it.

What's next for Open Application Desk

The current challenge sample intentionally stores its state in the visitor’s browser and uses a fictional reference program, making it easy for judges to reset and reproduce without an account.

The next step is to replace that persistence layer with authenticated server storage while preserving the controller, five WebMCP contracts, deterministic gate, visible patch review, and human authorization boundary.

Foundations, accelerators, admissions offices, fellowship programs, and procurement teams could publish their own requirement sets while applicants and agents work safely against the same authoritative state. Future versions could also support additional evidence providers, organization-defined policies, durable receipts, and accessible multi-user review.

Built With

  • chromeextension
  • githubapi
  • openaiapi
  • openaisites
  • playwright
  • react
  • responsesapi
  • sha256
  • typescript
  • vinext
  • vite
  • vitest
  • webcryptoapi
  • webmcp
  • zod
Share this project:

Updates

Submission history