WebMCP: make human selection the agent handoff - #56
Conversation
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 667b0efcdb
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| <p class="eyebrow">WebMCP Challenge · live public surface</p> | ||
| <h1 id="webmcp-title">The Interdependency WebMCP</h1> | ||
| <p><strong>The page is the provider.</strong> Humans can browse and operate the skill registry here; WebMCP-capable browsers receive the same five operations through <code>document.modelContext.registerTool(...)</code>; remote MCP clients connect to the website-owned Render runtime.</p> | ||
| <p><strong>The page is the provider.</strong> Human and agent use the same commit-pinned skill material. A human chooses the skill; the page records that exact selection; the agent can then use the selected canonical skill with its separately authorized tools to deliver the requested change.</p> |
There was a problem hiding this comment.
Running node --test tests/webmcp.test.mjs tests/mcp-server.test.mjs now fails because this replacement removes document.modelContext.registerTool from the page while tests/webmcp.test.mjs still requires that phrase. This makes the repository's npm test suite fail on every checkout; either preserve the API reference in this paragraph or update the assertion to match the intended copy.
Useful? React with 👍 / 👎.
| <p>These are the skills exposed by the same commit-pinned registry used by WebMCP and the remote MCP server. The description shown here is the registry's human-readable statement of when and why each skill is used.</p> | ||
| <p class="eyebrow">Human selection surface</p> | ||
| <h2 id="skill-catalog-title">Choose the skill the agent should use</h2> | ||
| <p>The public human catalogue is deliberately narrow: msdmd and its metadata-block applications first, followed by the METAPAT meta skill. Other <code>skill-lib</code> skills remain canonical and available to agents, but are not presented as primary human choices here.</p> |
There was a problem hiding this comment.
For every non-meta procedural skill, such as repo-audit-repair, this statement is false for both advertised agent surfaces: browser WebMCP and the remote MCP server both use createSkillRegistry, whose new isPresentedSkill filter removes those records from list, find, inspect, and closure operations. The updated test even verifies that searching for repo-audit-repair returns nothing, so either retain these skills in the agent-facing registry or clarify that they are not available through this site's agent APIs.
Useful? React with 👍 / 👎.
| url.searchParams.set('skill', skill.name); | ||
| globalThis.history.replaceState(null, '', `${url.pathname}${url.search}${url.hash}`); |
There was a problem hiding this comment.
When a visitor uses the advertised remote MCP path, setting ?skill= only modifies that visitor's local page URL and DOM; the remote server is stateless and its inspect/closure tools still require callers to supply an exact name. Consequently the remote agent receives no selected skill identity despite the page depicting the selection as flowing to remote MCP, so this path needs an actual handoff mechanism or must be described as browser-local only.
Useful? React with 👍 / 👎.
| for (const skill of skills) { | ||
| for (const dependency of skill.depends_on) { | ||
| if (!byName.has(dependency)) { | ||
| throw new Error(`presented skill dependency is not presented: ${skill.name} -> ${dependency}`); |
There was a problem hiding this comment.
If a future metadata-block skill declares a dependency on a procedural skill other than meta, the source projection remains valid under normalizeRegistry, but this new check makes createSkillRegistry throw. Because both the browser page and remote server construct this adapter at startup, one valid cross-scope dependency from the automatically refreshed upstream registry would disable the entire public surface; either include such prerequisites when resolving closures or enforce the restriction during refresh so the verified fallback can be used.
Useful? React with 👍 / 👎.
1 participant
Purpose
Make the WebMCP page a true shared human/agent skill-selection surface rather than a machine-oriented registry console.
Changes
metaskill to both humans and MCP agents<details>controls?skill=..., and enables click-only inspect/closure actionsskill-libas canonical source; the public adapter derives one shared curated viewhmmm
Selection is instruction, not permission. The agent still needs its own authorized tool boundary to deliver change.