Describe the server by what an agent can accomplish

[robertjamesprior]

Summary

• Rewrote the server.json description around what the server lets an agent do, using the full 100 characters the schema allows. The previous sentence spent 30 of its 83 on "via MCP (remote HTTP + OAuth)", which every entry in the registry shares.
• Added server instructions, returned on initialize. That is where the longer framing fits: when to reach for Kernel, and what order to try WebMCP, Playwright and computer use in.
• Pointed repository.url at the current org, replaced the onkernel.com links (they now 301 to www.kernel.sh), added websiteUrl since that is the field the current schema defines, and moved $schema to the 2025-09-29 version the registry actually stores entries under.

What I checked before choosing the wording

The registry's search parameter matches the server name only. Searching captcha returns five servers that all have it in the name and misses the one that has it only in its description. stagehand returns nothing despite appearing in a description, and cloud-based browsers returns nothing despite being our current description verbatim.

Two consequences:

• Keyword-stuffing the description does nothing for registry retrieval, so it is written for humans scanning a catalog and for third-party catalogs that do index description text. "cloud browser" stays in for those.
• Our findability problem is the name, com.onkernel/kernel-mcp-server, which matches kernel and onkernel and nothing for browser, web, automation or scrape. Out of scope here, but worth a separate decision.

Length is also a convention: the registry median is 91 characters and 57% of entries sit at 90 or above.

Notes for review

• title, tags, categories, homepage_url, documentation_url and license are not in the registry schema and are not published. Left in place rather than widen the diff, but they are not a lever.
• Publishing is manual. publish-mcp.yml has its push trigger commented out, so the live entry needs a workflow_dispatch run to pick this up. It has not changed since 2025-09-09.
• Tool-level descriptions are unchanged. Applying the same framing there is worth doing, and it is a much bigger review than this one.

Testing

bun test: 605 pass, 0 fail. Two new tests: one pins the 100-character limit, which fails registry publication rather than CI if exceeded, and one pins the escalation order stated in the instructions.

🤖 Generated with Claude Code

---

Note

Low Risk
Metadata and initialize-time instructions only; no auth, transport, or tool behavior changes.

Overview
Reframes how the Kernel MCP server presents itself to agents and the registry: server.json gets a capability-focused description (within the 100-character registry cap), bumps $schema to 2025-09-29, adds websiteUrl, and updates homepage/docs/repo links from onkernel.com to kernel.sh / the kernel GitHub org.

Adds MCP_SERVER_INSTRUCTIONS (built from the registry description plus guidance on when to use cloud browsers and the webmcp → execute_playwright_code → computer_action escalation) and returns it on MCP initialize via the transport serverInfo.

Tests lock the description length and the stated tool escalation order.

^{Reviewed by Cursor Bugbot for commit a8940a5. Bugbot is set up for automated code reviews on this repo. Configure here.}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
mcp	Ready	Preview	Sep 18, 2026 7:41pm UTC

[robertjamesprior]

Low priority, and copy judgment more than code.

The registry caps description at 100 characters and never searches it. I tested this: search matches the server name only, so stagehand returns nothing despite being in Browserbase's description, and cloud-based browsers returns nothing despite being our own current description. So the description is written for humans scanning a catalog and for third-party catalogs that do index text, and the longer framing goes in the instructions string instead.

The real question is whether those two pieces of text say what you would say. Everything else is a JSON edit and two lines in the handler.

Behind the CUA-TS work. No rush on this one.

[masnwilliams]

two small copy changes before merge: make the execution ladder a per-step preference rather than a one-time choice, and apply the KERNEL brand rules to the new model-facing prose. the implementation itself looks clean.

[masnwilliams]

stop at the first one that works is too strong. a task can use webmcp for one step and still need playwright or computer control for another; awaiting_submission already requires that handoff. can we frame this per step instead? for example: for each step, prefer these layers in order. move to the next when the current layer is unavailable or insufficient.

[masnwilliams]

can we give all of this new model-facing prose a KERNEL brand pass? use KERNEL, lowercase sentence starts and technical terms (chromium, dom), and replace fastest and least brittle with the mechanism that earns the preference, such as prefer this when available because the site defines the action contract.

[masnwilliams]

same brand requirement here: KERNEL-authored prose should start lowercase, so this should begin with use.

[robertjamesprior]

both addressed.

per-step, not a one-time choice. reframed to "for each step, prefer these layers in order. move to the next when the current one is unavailable or insufficient", and added the awaiting_submission case explicitly, since that is the handoff that proves the point.

brand pass. lowercase throughout including sentence starts and chromium and dom, KERNEL uppercase, and the registry description now starts lowercase. replaced "fastest and least brittle" with the mechanism: the site defines the action contract rather than the caller inferring it from the dom.

625 tests pass.