Build For The Agent's Toolbox

Ship the product as a tool an AI agent calls, not a destination a human has to remember to open.

On January 26, 2026, Anthropic and OpenAI shipped MCP Apps, a joint extension to the protocol that lets a tool render its own interface right inside the chat instead of returning a wall of text. Nine launch partners went first: Asana, Figma, Canva, Slack, Amplitude, Box, Clay, Hex, and monday.com. Draft a Slack message or build a Figma diagram and you never leave Claude to do it. This is the same land grab Zynga ran when it built FarmVille for Facebook's early, uncrowded platform APIs, before every studio piled onto the same feed and the channel filled up. The shelf inside Claude's and ChatGPT's app directories is still that uncrowded, and being the tool an agent reaches for beats being a tab a human has to remember to open.

What to do: Publish an MCP server for your product under your own verified namespace in the official MCP registry, not a name a third party claims first, and ship one MCP App that renders your single highest-value screen inline. Pick the one action people open your product to do, checking a dashboard, approving a request, building a chart, and make that the first thing an agent can call and see, not just read about.

Why it works: An agent routes work to whatever tool answers the call fastest, and if you have not claimed your name, someone else's wrapper answers in your place.

Example: Linear already ships itself this way. Its MCP server sits in the official registry under the app.linear namespace, a claim Linear had to prove by passing a DNS or HTTP ownership challenge, live at mcp.linear.app, so any MCP client, Claude, ChatGPT, Goose, or a coding agent in your terminal, calls Linear directly instead of a human opening linear.app.

Walk it through

I checked this in July 2026. Here is exactly what came back.

1. See what actually shipped.

That is the announcement page, still live. "Open Asana, Slack, Figma, and more in chat with MCP Apps." Read it as a map of who moved first, and treat every name not on it as a company that has not shown up yet.

2. Check the official registry for a company that already claimed its name.

curl -s "https://registry.modelcontextprotocol.io/v0/servers?search=linear&limit=1"

{
  "servers": [
    {
      "server": {
        "name": "app.linear/linear",
        "description": "MCP server for Linear project management and issue tracking",
        "version": "1.0.0",
        "remotes": [
          { "type": "sse", "url": "https://mcp.linear.app/sse" },
          { "type": "streamable-http", "url": "https://mcp.linear.app/mcp" }
        ]
      },
      "_meta": {
        "io.modelcontextprotocol.registry/official": {
          "status": "active",
          "publishedAt": "2025-09-18T15:51:15Z",
          "isLatest": true
        }
      }
    }
  ]
}

The name is app.linear/linear, not io.github.someone/linear-server. That prefix is the tell. Linear proved it controls the linear.app domain and published under its own namespace, so this listing is Linear speaking for Linear.

3. Now search for a company that has not claimed its own name yet.

curl -s "https://registry.modelcontextprotocol.io/v0/servers?search=asana&limit=20"

That returns four servers: com.mcparmory/asana, the same package at a second version, and io.github.pipeworx-io/asana, described as a wrapper that "wraps the Asana REST API." No com.asana or app.asana entry exists. Asana is on the MCP Apps launch list above, with a real interactive connector live inside Claude today, and it still has not claimed its own name in the open registry that every other MCP client reads from. Claude's connector directory and the public MCP registry are two different shelves, and being on one does not put you on the other.

The read

• The registry is public and it costs nothing to check. Search your own product name before you build anything. If a wrapper already has it, you are already behind.
• The namespace prefix tells you who is really talking. app.yourcompany behind a DNS or HTTP proof means the company itself. io.github.someone means a developer who may or may not still maintain it next year.
• A proprietary connector and a registry listing are not the same claim. Shipping inside one company's app directory, however prominent, does not register your name on the open standard every other agent client reads.

Steal it

Run the same two curls against your own product name today. If nothing comes back, you have an open field. If a third-party wrapper comes back instead, that is your competitor for the agent's attention, and you did not build it. Claim the namespace, publish an official listing, and point it at one real capability, not a stub. Then pick the single screen a human opens your product to see and ship it as an MCP App, so an agent can render it instead of describing it in text.

Defend the claim once you have it. A verified namespace is closer to a domain name than a listing, first mover wins and squatters are hard to dislodge once an agent has already learned to trust a given server. Do the DNS challenge the week you read this, even before the MCP App itself is ready. The empty listing with your real domain behind it is worth more than a perfect product with someone else's wrapper standing in front of it.

Gotchas

• A listing is not usage. Agents surface tools by relevance and recent success, not by registry presence alone. Publishing gets you on the shelf. It does not make the agent reach for you.
• MCP Apps is real engineering, not a badge you slap on. You are building a second front end that has to run in a sandboxed iframe, handle auth, and pass whatever review the host platform requires. Budget it like a product surface, not a config flag.
• Wrappers are not automatically hostile. Someone building io.github.pipeworx-io/asana before Asana claims its own name is often just a developer solving their own problem, not an attacker. The honest fix is to ship your own official listing, not to go after theirs.