MCP apps extend MCP from text responses to interactive, branded interfaces that can run across hosts such as Claude, VS Code, Cursor, and ChatGPT.
2
Context engines, registries, gateways, sandboxes, and platform standards are needed to make MCP useful and safe in enterprise environments.
3
The summit presented MCP as a foundation for composable agent systems, while also exposing unresolved issues around authorization, discovery, streaming, client differences, and security.
Summary
Day 2 of MCP Dev Summit focused on how MCP is moving beyond simple tool calls. Ido Salomon and Lead Ysef presented MCP apps, which let servers return interactive HTML-based interfaces that preserve a company's branding and let users act through the host. Ryan Cook described WorkOS's context engine, which resolves identity, permissions, integration instructions, and semantic definitions before an agent calls a model. Other sessions covered MCP gateways and Docker sandboxes, enterprise registries at Nordstrom, procurement orchestration at PwC, and trustworthy AI infrastructure at Bloomberg. Speakers also explored code-mode alternatives, streaming MCP over Kafka, graph queries through Neo4j, Kubernetes-based agent platforms, and operational interfaces for PagerDuty. Security researchers demonstrated DNS rebinding risks in local MCP servers. The day was practical and exploratory, with repeated warnings that MCP alone does not provide governance, authorization, observability, or reliable production behavior.
MCP apps turn tool responses into interactive branded interfaces
Ido Salomon and Lead Ysef argued that text is a poor interface for many agent tasks. MCP apps let a tool point to an HTML resource, which the host renders inside a sandbox. The UI can preserve the identity of the company behind the tool, such as PostHog, and can be interactive. A click sends a message to the host, which can decide to call another tool, send a notification, or issue a prompt request. They described support across Claude, VS Code, Cursor, Copilot, ChatGPT, Postman, Goose, and other hosts, while presenting MCP apps as an open standard with a public working group.
A context engine should assemble task-specific context before model reasoning
Ryan Cook described WorkOS's context-first architecture. Its pre-reasoning pipeline resolves the human identity behind an agent, determines the resources that identity can access, and injects relevant tool information before an LLM call. Static integration instructions explain how an agent should use a tool, while dynamic instructions are fetched only when the tool is invoked and are discarded after the task. WorkOS also maintains semantic definitions, such as what a sales transaction means in its own systems, and exposes those definitions as MCP resources so agents use consistent language.
MCP systems need governance and isolation outside the agent
Cecilia Lou presented two Docker security scenarios. In one, an employee installs an unapproved server found online, leading to a data leak with no audit trail. In another, an approved agent is allowed to merge pull requests, delete branches, and close issues, but does exactly what it was permitted to do while destroying work the user intended to keep. Her proposed controls are an MCP gateway, a sandbox, and an operationally simple deployment model. The gateway controls server catalogs, authentication, policies, access, and audit logs. Sandboxes impose OS-level limits on filesystems and networks, including separate containers and microVM isolation.
Enterprise MCP adoption depends on existing engineering foundations
Ola Hungerford and Sandeep described Nordstrom's approach as an extension of existing engineering practice. The team reused deployment pipelines, container platforms, internal SDKs, documentation, registries, and community groups instead of creating a separate AI platform from scratch. Their registry records ownership, data touched, compliance status, and enterprise metadata. Teams graduate from local experiments to sandbox environments and then production, with governance proportional to risk and maturity. Office hours create a feedback loop that exposes duplicated work and reveals which experiments should become shared standards.
MCP can orchestrate enterprise skills across applications
Jacob Wilson showed a procurement example in which a GPT app sends a request to an MCP orchestrator. The orchestrator uses skills to classify a request as direct or indirect procurement, then routes it to the appropriate procurement agent and backend MCP server. The direct path could handle robotic arms or GPUs, while the indirect path could handle office purchases. After the backend completes the request, the orchestrator returns both structured data and the UI resource that the GPT app should display. Wilson also described MCP gateways as a way to add finer-grained policies when backend systems expose weak authentication such as API keys.
Code mode reduces context, but declarative graphs can make orchestration inspectable
Bob Dickinson explained that code-mode papers showed how generated code can orchestrate multiple tool calls while keeping intermediate results out of the main context. He objected to making generated source code the only solution because it is difficult to inspect, govern, and secure. His MCP Graph project uses YAML-defined directed graphs, JSONata for data transformation, JSON Logic for conditions, and explicit nodes for tool calls and exits. A visual interface can show inputs, outputs, breakpoints, and execution times. Dickinson also found that agents needed tools to inspect available servers, test individual transformations, run graph steps, and deploy the resulting graph.
Streaming MCP addresses stale context in monitoring workflows
Harshit Kohli described a streaming MCP architecture for real-time logs and anomaly detection. A log producer sends events through Kafka, a streaming MCP server consumes them, and agents receive updates through WebSockets. The server also supports interactive queries such as asking for recent anomalies or current status. Kafka provides durability, replay, and back-pressure handling. The demo used a bounded queue of 500 events to detect slow agents and remove them from the real-time pipeline. Kohli also described Cedar authorization, with default-deny policies applied to individual requests so different agents can receive different permissions.
Local MCP servers remain exposed to browser-based DNS rebinding attacks
Jonathan Leitschuh demonstrated how malicious websites can use browser networking behavior to reach local or private-network servers. DNS rebinding can make a browser first load content from an attacker-controlled domain and then send requests to localhost, bypassing the same-origin policy. He tested this against MCP servers and tools, including MCP Inspector, database tooling, Docker's MCP gateway, and AWS-related servers. The MCP specification warns that streamable HTTP servers must validate the Origin header, but SDK defaults and server configurations have historically left this protection disabled. His practical advice was to test local servers with unexpected Host headers and verify that the SDK's DNS-rebinding protections are enabled.
"Just because you're running a local server locally doesn't mean the browser can't be used as an attack vector to attack your server."Jonathan Leitschuh6:56:59
Who should watch
You are building MCP servers or apps and need to understand how interactive UI, state, sessions, and multiple hosts change the design.
Your company is moving from MCP experiments to production and needs registries, gateways, sandboxes, identity controls, audit logs, or a graduation path.
You operate agents, developer tools, or monitoring systems where stale context, excessive permissions, weak observability, or local server security could cause real damage.
![Thumbnail for MCP Dev Summit [Day 2]](https://i.ytimg.com/vi/7UVZnJ9iHdU/maxresdefault.jpg)