AGNTCon + MCPCon NA 2026: Recap for MCP Builders

In speaking to MCP builders at AGNTCon + MCPCon North America last week, one theme stood out: MCP is becoming a default component of the broader agent stack.

An MCP server is no longer just a list of tools behind an endpoint. Companies want to give AI agents the context and capabilities to carry out workflows, and they're deploying these through MCP skills, WebMCP, and commerce protocols like UCP.

Pamela Fox wrote a great summary of the conference that's a starting point for understanding where the chatter was focused. Here, we're diving into the developments we think matter most to MCP server builders today, what's changing in the specs, and what MCP developers should test as they build around these changes.

Your tool list is still the first thing to get right

Thomas Sarlandie works on ChatGPT's plugins team at OpenAI. According to Pamela's notes, his advice for server authors was:

• Don't worry much about exposing a lot of tools.
• Don't hide tools behind a discovery meta-tool.
• Keep tool descriptions short, because ChatGPT truncates long ones.
• Mark tools as read-only or destructive, and make those marks accurate.
• Use server instructions. About half of servers don't.

The last two need almost no explanation. In the MCP spec, readOnlyHint and destructiveHint are hints. Clients shouldn't trust them blindly, and the spec defaults destructiveHint to true. OpenAI's Apps SDK reference makes readOnlyHint, destructiveHint, and openWorldHint required for apps, and notes that they only change how ChatGPT frames a call to the user. Your server still has to enforce its own authorization. Server instructions are a single instructions string. In the 2026-07-28 spec it comes back from server/discover, and it is the cheapest place to tell a model how your tools fit together.

The first two tips are about what clients can cope with, and that varies by host and model. A tool list that works well in ChatGPT may behave differently in Claude or Cursor, so treat them as a starting point and check them against the clients your users actually use. For more on the instructions field, see our post MCP server instructions.

What to test: run the same prompts against your full tool set and against a consolidated version, across the models and hosts your users actually use. Check whether the right tool gets selected, whether the arguments are correct, and how many tokens each version costs. In MCPJam, an eval suite runs each case against each model you pick and records the transcript, tool calls, and tokens. See the Evals docs.

Auth now depends on who the agent is

Aaron Parecki's talk traced how MCP sped up three OAuth specs that had been in progress for years:

• Protected Resource Metadata (PRM, RFC 9728) tells a client which authorization server protects your MCP server.
• Client ID Metadata Documents (CIMD) let a client identify itself with an HTTPS URL it controls, so it doesn't have to register with every server ahead of time.
• The Identity Assertion JWT Authorization Grant (ID-JAG) lets an enterprise identity provider broker access.

All three now show up in the 2026-07-28 authorization spec. Here is what the spec actually requires:

• MCP servers MUST implement PRM, and MCP clients MUST use it to discover the authorization server.
• Authorization servers and MCP clients SHOULD support CIMD.
• Authorization servers and MCP clients MAY support Dynamic Client Registration (DCR, RFC 7591), but the spec states that DCR "is deprecated and retained for backwards compatibility with authorization servers that do not support Client ID Metadata Documents."
• Before starting the flow, a client MUST get a client ID through one of three mechanisms: CIMD, pre-registration, or DCR.

In practice, CIMD is the recommended way for a client to identify itself, and DCR is now a compatibility fallback. Nothing breaks today if you still support DCR, but new work should not depend on it:

• If you maintain an authorization server, add CIMD support: accept a URL-formatted client_id, fetch the metadata document from it, and validate its redirect_uris. Keep DCR running only for older clients that need it.
• If you maintain a client, publish a client metadata document and use its URL as your client_id. Fall back to DCR only for authorization servers that don't support CIMD.
• If you maintain an MCP server, PRM is your part. Your server doesn't register clients itself, but which mechanisms your users' clients can use depends on the authorization server you point to.

If you added DCR last year, it's time to add CIMD.

ID-JAG is the basis of MCP's Enterprise-Managed Authorization extension. You will also hear it called XAA (Cross App Access), which is Okta's name for the same flow. The employee signs in to the company's identity provider. The IdP issues an ID-JAG for your MCP server, and your authorization server exchanges it for its own access token. The user never sees a consent screen, and the IT admin controls which agents can reach which servers.

Den Delimarsky covered what comes next: DPoP (RFC 9449, which binds tokens to a key so a stolen token is useless on its own) and workload identity. These are not in the spec yet. DPoP (SEP-1932) and Workload Identity Federation (SEP-1933) are open proposals. They aim to let agents call MCP servers under their own identity, not only on a user's behalf.

Michael Grinich's auth.md solves a different problem. It is a WorkOS protocol that lets an agent learn from a Markdown file on your domain how to register for your service. In Pamela's account of the demo, Claude signed up for a Neon account and got a temporary identity that expires after 72 hours unless a human claims it. auth.md is not part of the MCP authorization spec, and it doesn't replace ID-JAG.

What to test:

• Does your PRM resource value match your server's actual URL?
• Does your authorization server accept CIMD clients?
• What happens to clients that still rely on DCR, and what happens to a CIMD-only client if your authorization server only supports DCR?

In MCPJam, the OAuth Debugger runs the handshake one step at a time against the 2026-07-28 spec and older versions. It shows each HTTP request and response, supports DCR, CIMD, and pre-registered clients, and warns when your PRM resource doesn't satisfy RFC 9728.

For enterprise auth, the XAA Debugger plays both the identity provider (it signs the ID token and the ID-JAG) and the agent:

1. Copy the issuer URL and JWKS URL from the XAA Flow header.
2. Configure your authorization server to trust them.
3. If MCPJam runs locally and your server is in the cloud, enable "Use hosted issuer".
4. Run the flow.

Skills can now come from your server

Agent Skills are folders of instructions and files that a model loads only when it needs them. Anthropic's Agent Skills format is now one of four projects the Agentic AI Foundation took in at this conference. Skills over MCP is a separate thing. It is an MCP extension, SEP-2640, which has reached Final status. With it, a server publishes skills as MCP resources, and hosts that support the extension list them alongside their local skills. In short, Agent Skills defines what a skill is, and Skills over MCP defines how a server delivers one.

The part that matters most for server authors is authenticated skills. David Soria Parra pointed out that an authenticated server knows who the user is, so it can send skills for that user. A sales rep and a support engineer at the same company could get different playbooks from the same server. So could a customer in the EU and one in the US, or an admin and a read-only user on the same account. The instructions the model receives can match what that user is allowed to do and what their account contains.

A plugin bundled with a client can't do that. It ships the same files to everyone, and changing them means shipping a new version. A server-delivered skill comes from the same place as the tools and data it describes, behind the same auth. That also means it fails in the same places. If your server sends a user the wrong skill, it is giving the model instructions for tools that user can't call or data they shouldn't see.

The spec has one detail to plan for. Each skill entry lists its files with digests, so a host can verify the content and tie the user's approval to it. A server that generates skill content per request can mark it "dynamic" instead, but the spec lets hosts decline to load dynamic skills. If you tailor skills per user, serving a small set of stable variants is more portable than generating each one on the fly.

What to test: treat a skill like a tool description, because it is text that changes how the model behaves. Check four things:

• Is the skill discovered?
• Does the model load it for the prompts it was written for?
• Does it stay unloaded for prompts it wasn't written for?
• Do two different users get the skills they should, and not the ones they shouldn't?

In MCPJam, Skills lists skills over MCP next to local skills. In the Playground, you can let the model infer which skill to use, or invoke one directly with /. You can then see whether loadSkill and readSkillFile were called. To check per-user skills, connect to your server as two different test users and compare the lists.

Our post MCPJam now supports Skills over MCP covers the setup.

WebMCP puts tools in the page

Sarah Drasner gave an overview of WebMCP. It lets a web page register tools in JavaScript with navigator.modelContext.registerTool(). A browser agent can then call a real function instead of scraping the DOM. WebMCP is a W3C Web Machine Learning Community Group draft, and Chrome shipped it as an early preview behind a flag. It is not a standard yet, and it is not MCP's JSON-RPC protocol. Chrome's own docs describe it as "MCP-inspired" APIs, not an extension or replacement of MCP. It borrows MCP's tool model and applies it to the browser tab.

It is easy to confuse WebMCP with MCP Apps, since both involve tools and web UI. They run in opposite directions:

• MCP Apps is an official MCP extension. Your MCP server returns a UI resource (ui://), and the host renders it in a sandboxed iframe inside the chat. The app talks to the host over postMessage with JSON-RPC. The UI comes to the agent.
• WebMCP is a browser API. Your existing website registers tools, and an agent with access to the rendered page calls them while the user has that tab open. The agent comes to your UI.

Put another way, MCP Apps lets an MCP server show UI in a chat, and WebMCP lets a web page offer tools to an agent. They are not equivalent and neither one replaces the other. A team could reasonably ship both: an MCP server (with an MCP App) for chat hosts, and WebMCP tools on their website for browser agents. We haven't found a spec that connects the two, so don't assume that tools a page registers with WebMCP will be available inside an MCP App iframe, or the other way around.

For developers, WebMCP means your web app becomes a tool server, with the same design questions as above: clear names, honest descriptions, and actions that are safe to retry.

What to test:

• Are the tools registered when the agent arrives?
• Are they removed when the page state changes?
• Does the model call them correctly from a natural-language request?

In MCPJam's Playground, WebMCP inspection works once you turn on Allow Browser, and page tools follow the chat's tool-approval setting. Our posts WebMCP Testing: How to Test and Debug Tools and What Is WebMCP? go into more detail.

UCP runs on top of MCP

Ilya Grigorik of Shopify presented the Universal Commerce Protocol (UCP). Pamela's notes say he often gets asked whether to use UCP or MCP, and that his answer is "Yes!", meaning UCP over MCP. The spec bears this out. UCP defines the commerce semantics: catalog, cart, checkout, orders, and payments. MCP is one of its transports, alongside REST and A2A.

The flow works like this:

1. A merchant publishes a profile at /.well-known/ucp.
2. The agent sends its own profile with every request (in MCP, under meta["ucp-agent"]).
3. The two sides settle on the capabilities they share.
4. Checkout runs as ordinary MCP tools: create_checkout, update_checkout, and complete_checkout.

What to test: this is MCP, so the familiar failures apply. They hit harder here because money is involved.

• Does the agent ever call complete_checkout without the user confirming?
• Is the idempotency key reused when the agent retries?
• Does the agent stop and hand off to continue_url when the merchant needs the buyer?

These are questions about agent behavior across models, which is what eval suites are for. MCPJam has no UCP-specific tooling. Its general evals and multi-model runs apply to any MCP server, including one that exposes UCP.

Also worth knowing

MCP Tasks. David Soria Parra announced Tasks support in Claude Code. Tasks is an official MCP extension: a call can return a task ID, and the client polls it, answers input requests, or cancels it. Pay attention to how each client behaves while a task is running. See How to work with MCP Tasks.

AAIF's new projects. Open Responses, Agent Skills, OpenSandbox, and OpenEnv moved under neutral governance (announcement). They are existing projects, not new releases.

Buzz. Block's open-source, agent-native communication platform: github.com/block/buzz.

What to do this week

Pick the one section above that touches your server and run its test before you change anything. If you build for enterprise customers, run the OAuth Debugger and XAA Debugger against your staging authorization server, and check whether it accepts CIMD clients. If you ship skills, connect as two test users and compare what each one received. If you are about to reorganize your tools, write five realistic prompts first and run them across the models your users actually use.