MCP and Computer Use

Sources#

• Anthropic's Boris Cherny: Why Coding Is Solved, and What Comes Next
• How Anthropic's product team moves faster than anyone else | Cat Wu (Head of Product, Claude Code)
• MCP Specification Changelog — 2026-07-28
• OpenID Foundation advances authorization for the agent era with new AuthZEN Working Group Drafts
• The Founder's Playbook: Building an AI-Native Startup
• Zero Trust for AI Agents

Summary#

Two complementary mechanisms for connecting models to external software, both built by Anthropic, both load-bearing across the Claude Code / Cowork / Chat product surfaces. MCP (Model Context Protocol) is structured, programmatic access — "the same connector you have in Claude AI" plugs into Salesforce, Google Docs, Google Calendar, Slack, Figma, Gmail, and increasingly niche industry systems. Computer use is the catchall for software that doesn't expose an MCP: the model drives the GUI directly (mouse, keyboard, screen), slow but increasingly competent on Opus 4.7. Boris Cherny's framing: "To the model, it's just tokens" — MCP / API / computer use are interchangeable substrates for the same capability.

What MCP is#

Created at Anthropic Labs (late 2024) alongside Claude Code and the desktop app by Boris's founding team. Structured tool-calling protocol with a server-client architecture:

• Server — runs alongside the external system (Salesforce, Slack, Gmail, internal CRM, niche industry SaaS); exposes available tools as typed function calls.
• Client — the Claude surface (Claude Code, Cowork, Claude AI, third-party agent) that consumes those tools.
• Same connectors everywhere. "The same MCP connector that you have in Claude AI, you hook up like Salesforce, you hook up Google Docs, Google Calendar. And then Cowork can use that. Claude CLI can use it. Claude Code everywhere can use it." — Boris Cherny

The structural property: connector logic is written once per system, consumed by every Claude surface. This is what makes Cowork viable across the existing knowledge-work tool surface (Salesforce, Docs, Drive, Slack, etc.) without Anthropic having to build per-tool integrations.

Protocol revision 2026-07-28: MCP goes stateless#

Everything above describes the connector pattern. This section dates the wire protocol, which until now the vault tracked only through what tools built on it could do. Revision 2026-07-28 (MCP Specification Changelog — 2026-07-28) is the first MCP spec version compiled here, and it is a large break from its predecessor 2025-11-25.

Evidence tier: vendor-claim. A specification is authoritative about what the protocol requires and is evidence for nothing else — not adoption, not whether any SDK or server complies, and not whether a stated requirement produces a security outcome. Read every line below as "the spec now says", never as "deployments now do".

The session is gone. Protocol-level sessions and the Mcp-Session-Id header are removed from Streamable HTTP, and the initialize / notifications/initialized handshake is deleted outright (SEP-2567, SEP-2575). tools/list, resources/list and prompts/list no longer vary per connection; a server needing cross-call state must mint explicit handles and pass them as ordinary tool arguments. MCP is now stateless by construction.

Version negotiation moved from once-per-session to once-per-request. Every request carries io.modelcontextprotocol/protocolVersion and io.modelcontextprotocol/clientCapabilities in _meta; clients SHOULD send clientInfo on each request and servers SHOULD return serverInfo in each result's _meta; a mismatch returns UnsupportedProtocolVersionError. A new server/discover RPC — servers MUST implement it, clients MAY call it — advertises supported versions, capabilities and identity up front, or acts as a backward-compatibility probe on STDIO.

The server can no longer initiate. Multi Round-Trip Requests (MRTR, SEP-2322) replace every server-initiated request — roots/list, sampling/createMessage, elicitation/create. A server needing more input returns an InputRequiredResult (resultType: "input_required") carrying inputRequests; the client supplies inputResponses on a retry of the original request. All results now carry a required resultType, and results from earlier-protocol servers that omit it MUST be treated as "complete". Change notifications move to a single opt-in long-lived subscriptions/listen stream (replacing the HTTP GET endpoint and resources/subscribe), with request-scoped notifications like notifications/progress still riding their own request's response stream.

Caching becomes part of the contract. tools/list, prompts/list, resources/list, resources/read and resources/templates/list results MUST now carry ttlMs (a freshness hint) and cacheScope ("public"/"private") via a new CacheableResult interface, and servers SHOULD return tools in a deterministic order — both justified in the changelog as client-side caching and LLM prompt-cache hit rate, not security. They have a security side effect anyway; see MCP Tool Poisoning.

Feature lifecycle: the first dated capability ledger#

The revision adopts a feature lifecycle and deprecation policy — Active / Deprecated / Removed states, a minimum twelve-month deprecation window, and a registry of deprecated features (the only one of this revision's headline changes with its own spec page). That registry is what makes protocol capabilities datable at all: before it, "is this still in MCP?" had no answer short of diffing schemas.

Capability	State as of 2026-07-28	Migration the spec names
initialize / notifications/initialized handshake	Removed	per-request _meta version + server/discover
Protocol-level sessions, Mcp-Session-Id	Removed	server-minted handles as tool arguments
ping, logging/setLevel, notifications/roots/list_changed	Removed	per-request io.modelcontextprotocol/logLevel
SSE resumability / Last-Event-ID redelivery	Removed	re-issue the request with a new ID
Server-initiated requests (roots/list, sampling/createMessage, elicitation/create)	Removed	MRTR InputRequiredResult
Tasks	Moved out of core	official io.modelcontextprotocol/tasks extension
Roots, Sampling, Logging	Deprecated (≥12mo window)	tool params / resource URIs; direct LLM provider APIs; stderr or OpenTelemetry
HTTP+SSE transport	Deprecated (soft since 2025-03-26)	Streamable HTTP
includeContext: "thisServer" / "allServers"	Deprecated	omit, or "none"
OAuth 2.0 Dynamic Client Registration (RFC 7591)	Deprecated	Client ID Metadata Documents

Also new and small: an extensions field on client/server capabilities, OpenTelemetry trace-context conventions for _meta (traceparent, tracestate, baggage), required Mcp-Method/Mcp-Name headers on Streamable HTTP POSTs plus x-mcp-header for tool-parameter-supplied custom headers, looser JSON Schema 2020-12 support in inputSchema/outputSchema, an error-code allocation policy partitioning the JSON-RPC server-error range (-32020–-32099 reserved for the spec), and a PR-based SEP workflow with seps/ markdown files.

Authorization: the spec picks CIMD over DCR#

Four minor changes move MCP's authorization layer onto ground Agent Identity and Authentication and AIMS already occupy: authorization servers SHOULD include iss per RFC 9207 and clients MUST validate it against the recorded issuer before redeeming a code; client credentials MUST be keyed by issuer identifier, MUST NOT be reused with a different authorization server, and re-registration is MUST on AS change; DCR requires an explicit application_type; and RFC 7591 Dynamic Client Registration is deprecated in favor of Client ID Metadata Documents. CIMD is a primitive AIMS §10.10 already names under Discovery — so a shipping protocol and a standards draft converged on it independently, which is a real (if narrow) data point for the plural-governance question on that page.

What it does not change#

No change here addresses tool-return content, tool-behavior integrity, or server revocation. The deprecated-features registry tracks spec features, not servers or tools — it is not a revocation list, and nothing in the revision requires a client to re-validate a tool it already trusts. The security consequences, including the one incidental affordance this revision does create, are worked out on MCP Tool Poisoning.

What computer use is#

Generic GUI driving as a fallback when MCP isn't available. Model sees a screenshot, decides what to click/type/scroll, executes via accessibility/automation APIs. Operates on "pretty much any piece of software that you have on your computer" (Boris Cherny).

Properties as of Opus 4.7:

• Quality — "quite good… does it quite well now, especially with 4.7" (Boris). Anthropic "is like pretty far ahead on computers."
• Latency — "very slow." Costs more tokens than MCP for the same task because each action requires a screenshot round-trip.
• Coverage — universal. Computer use is what runs when the target software has no API, no MCP, no Python library — when the only interface is a human-facing UI.

Cowork is the deployment surface where computer use most matters today: many knowledge-work apps lack programmatic interfaces.

The "doesn't matter" thesis#

Boris's framing of the MCP-vs-API-vs-computer-use question:

"All this stuff just doesn't matter that much. It could be MCPs, APIs, just some sort of programmatic access cuz the model doesn't care. To the model, it's just tokens."

The substrate is fungible — the work is "expose capabilities to the model in a form the model can consume." MCP optimizes for structured / fast / cheap; computer use optimizes for universal / fallback / slow. Both reduce to token-level tool invocations.

This connects to The Bitter Lesson: as models improve, the boundary between "use an MCP" and "use computer use" should be a decision the model makes, not a decision a human harness designer makes. Boris's predictions for the next few years:

• "The model is just going to be doing all the code. It's going to be starting the agents. It's going to be building the environments." — Including, presumably, picking the right substrate to call a tool.
• Computer use specifically called out as a product area "going to get a lot better."

Cross-surface usage in the wild#

Surface	MCP examples	Computer-use examples
Claude Code (CLI)	GitHub, filesystem, Slack	Rare — engineering tools usually have CLIs/APIs
Cowork	Salesforce, Google Drive/Docs/Calendar, Gmail, Slack, Figma	Software without MCP; especially knowledge-work apps
Claude AI (chat)	Same connector set	Computer-use available
Mobile/web	Same MCP infrastructure	Browser-side, with screen-share permissions

Cat Wu's nightly slide-deck workflow (Cowork) explicitly uses MCP — Figma MCP, Slack MCP, Drive MCP — rather than computer use, because the latency cost is unaffordable for a workflow you want to complete by morning.

In the Founder's Playbook (AI-Native Startup Lifecycle)#

The playbook treats MCP as the primary integration mechanism at every stage:

• Idea stage — Cowork uses Gmail and Google Calendar MCPs to manage outreach threads, schedule customer interviews, run day-7 follow-ups.
• MVP stage — "The same MCP integrations that managed discovery logistics in the Idea stage apply here" for feedback-session scheduling, bug-report triage, iteration-cycle tracking.
• Scale stage — MCP integration with niche industry systems your competitors haven't heard of is named as a moat component (e.g., a generalist medical-billing AI breaks on 340B drug program claims; the vertical-specialist's MCP-wired competitor doesn't).

Two playbook case studies make the MCP-as-moat point concrete:

• Kindora ships an MCP connector that lets nonprofits access its prospecting tools inside Claude itself — the product is consumed via MCP, not just integrated with MCP.
• Anthropic Skills are referenced as the codification surface for recurring workflows ("how I audit a commercial lease," "how I triage a patient intake form") — Skills + MCP + memory together form the proprietary substrate the Compounding Data Moat concept describes.

Computer use is less prominent in the playbook itself, but Cowork is named as the operational layer that runs across "every stage" — and Cowork is where computer use covers the gaps that MCP doesn't.

Connection to harness-shrinkage#

Harness Shrinkage as Models Improve predicts that prompt scaffolding, permissions, and verification logic migrate inward as models improve. MCP and computer use are the opposite of harness — they are connectors between the model and the world. They don't shrink; they get broader (more systems, more interfaces) and faster (lower latency per action). The boundary that shrinks is the harness around the model's tool-selection decisions, not the toolset itself.

Caveat: as the model becomes better at picking when to use computer use vs. when to demand a real MCP, much of today's manual MCP-server-authoring effort may become "ask the model to build the connector you need." Still not a harness — more like model-authored infrastructure.

Connection to Agentic Misalignment (AM) and accountability#

MCP and computer use are exactly the substrate that turns an LLM into an agent capable of consequential action. Both extend the model's reach into:

• The customer's CRM
• The customer's email
• The customer's calendar
• Eventually, the customer's full desktop

Human-AI Accountability Redesign's "decision rights" subfront is what governs this — what does the agent do autonomously via MCP/computer use vs. what requires explicit human approval. Claude Code Auto Mode is one concrete instance: classifier auto-approves safe MCP/tool calls, blocks risky ones.

MCP as a security surface#

Zero Trust for AI Agents treats MCP as one of the highest-risk tool surfaces in agentic deployments, and supplies the concrete threat data the earlier sources lacked:

• Tool poisoning — attackers compromise MCP tool descriptors, schemas, or metadata so the agent invokes a tool based on falsified capabilities; a malicious tool can hide commands in its metadata to exfiltrate data without user knowledge.
• Rug pulls — a legitimate tool is silently replaced with a malicious version. The first documented in-the-wild malicious MCP server impersonated a legitimate email service and secretly copied all sent emails — the concrete realization of the attack-surface-scales-with-adoption worry.
• Tool chaining — combining legitimate tools (internal CRM + external email) into a harmful sequence neither would enable alone; because every call runs through trusted binaries under valid credentials, host-centric monitoring sees no malware. This is what Least Agency (capability restrictions per tool) and parameter validation are meant to contain.

The framework's prescriptions: run/host the MCP server yourself on an immutable platform after verifying and self-signing the code (Agent Supply Chain Risk); authenticate tool access with short-lived tokens bound to the calling agent's identity, never static API keys (Agent Identity and Authentication); and gate high-risk invocations behind approval escalation. Claude Code's OAuth 2.0 with auto-refresh for MCP connections and session-scoped "ask" permissions are cited as a reference implementation.

The threat model is now empirically sharpened by MCP Tool Poisoning (the dedicated concept page for this attack class). ShareLock (Liu et al., arXiv 2606.27027) demonstrates that scanning each MCP tool description — the intuitive mitigation implied above and in the open question below — is not just incomplete but provably insufficient: it uses Shamir threshold secret-sharing to fragment a malicious instruction into benign-looking tool_id/checksum shares spread across multiple tools, so each descriptor is information-theoretically clean (fewer than t shares reveal nothing), then a rug-pull server update plants a trigger that reconstructs the payload at runtime — >90% ASR while every LLM safety classifier and entropy detector rates the tools Safe. Detection has to become cross-tool and stateful; per-server vetting alone cannot discharge the risk.

A real-world incident closes off the other mitigation from the opposite side. Agentjacking (Tenet Security, June 2026, case-study; also on MCP Tool Poisoning) hijacks coding agents through a completely legitimate MCP server — Sentry's own — by injecting fake error events (via public, intentionally-write-only Sentry DSNs) that the server faithfully relays to the agent as trusted diagnostics; the agent reads a fake ## Resolution and runs the attacker's npx command. The lesson for this section is precise: vetting or self-signing the MCP server would not have helped here, because the server was never compromised. ShareLock breaks per-tool description scanning; Agentjacking rides in on a genuine server's data. Together they show the MCP attack surface has two orthogonal branches — poisoned tool metadata vs malicious data via a legitimate server — and neither is closed by "run/verify your own server." (Vendor-COI: Tenet sells agent-runtime security, so its scale claims are attributed inline on the dedicated page; the mechanism is the durable part.)

The standards-track defense at the tool-invocation point. The action-layer authorization these attacks push toward is now getting an interoperability standard. The OpenID Foundation's AuthZEN Working Group approved COAZ (AuthZEN Profile for MCP Tool Authorization, a Working Group Draft, 2026-06-15), which maps an MCP tool invocation into AuthZEN's Subject-Action-Resource-Context decision model so an API/AI gateway or downstream PDP can authorize each tool call against a policy — letting an MCP tool expose the authorization checks required to call it. This is the standards-body version of the per-call authorization gates (ScopeGate, aiAuthZ) — see AIMS. Scope caveat: COAZ authorizes the call, so it bounds a reconstructed or injected action that falls outside policy — but, like every value gate, it can't catch a poisoned call that stays within an allowed policy (the same corrupt-legitimately-variable-data residual, and it doesn't address Agentjacking's within-capability npx-if-the-package-is-allowed case). Proposed standard, practitioner-opinion — weighted below the empirical per-call-authz work; fuller treatment on AIMS.

Connections#

• Claude Code / Cowork / Anthropic — surfaces and vendor
• Harness Build-vs-Buy — rung 2 of OpenHands' customization ladder: an MCP tool server keeps an internal-systems integration outside the agent, so upgrading upstream doesn't mean reapplying the integration to a fork
• Zero Trust for AI Agents — treats MCP as a top-risk tool surface; supplies the tool-poisoning / rug-pull / tool-chaining threat model
• MCP Tool Poisoning — the dedicated concept for the TPA attack class; ShareLock's threshold-secret-sharing variant proves per-tool description scanning is information-theoretically blind, and its Agentjacking case study (legitimate Sentry MCP server relaying attacker-injected data) proves server-vetting/self-signing is equally blind — both sharpen this page's MCP-security open question from opposite sides. It also carries the security read of the 2026-07-28 revision above: per-request checking arrived for the protocol version, not for tool behavior, and the one thing that genuinely changed for rug-pulls is a side effect of the new caching fields
• Codex App Server Protocol — the comparable protocol, now diverged on statefulness: the App Server keeps the initialize/initialized handshake, thread_id continuation and session lifecycle that MCP 2026-07-28 deleted, which turns the tool-plane/session-plane split into the MCP spec's own explicit position rather than an observed division of labor
• Agent Supply Chain Risk — MCP servers are a named tool-supply-chain vector; run-your-own-server + self-signing is the mitigation; the ShareLock reconstruction trigger is a rug-pull planted via server update
• Agent Identity and Authentication — short-lived identity-bound tokens replace static keys for MCP/tool authentication
• Agentic Prompt Injection — MCP-connected browsing/email/document tools are the indirect-injection entry points
• Boris Cherny — co-created MCP; frames the "doesn't matter" thesis
• Cat Wu — articulates daily MCP usage and the Cowork integration story
• Harness Shrinkage as Models Improve — what does not shrink; complementary infrastructure
• The Bitter Lesson — model-decides-substrate is the bitter-lesson endpoint
• AI-Native Startup Lifecycle — MCP across all four founder stages
• Compounding Data Moat — Skills + MCP + memory as moat substrate
• Claude Code Auto Mode — decision-rights gating for tool use
• Claude Code Best Practices — MCP-based extension is one mechanism for "scaling patterns"
• Agentic Misalignment (AM) — MCP/computer use as the action surface; risk increases with reach
• Human-AI Accountability Redesign — governance layer for MCP/computer-use deployments
• Agent Harness Engineering — MCP-as-connector vs. harness-as-scaffold distinction
• Hermes Agent — third-party agent product that consumes MCP (mentioned in cross-tool capability table in Claude Code Best Practices)
• Symphony — alternative orchestration where MCP-style tool exposure runs through codex-app-server-protocol instead
• Agentic Work Systematization — plugins bundle MCP/connector integrations alongside skills; connectors are the tool-reach half of systematization (the loop touching real tools, not just the filesystem)
• Agent-Native Infrastructure — MCP is what makes a service agent-legible (structured); computer use is the GUI-driving fallback when it isn't — together they're the substrate Karpathy's "describe it to agents first" world requires
• Agent Identity Management System (AIMS) — AIMS treats MCP tools as the resource surface OAuth authorizes and aligns its human-in-the-loop model with MCP's user-solicitation pattern — but insists a local MCP approval is not authorization and must map to a verifiable authorization-server grant; it now also hosts the OpenID AuthZEN COAZ draft (the proposed standard for authorizing each MCP tool invocation, MCP→SARC) and AARP (the prerequisite/approval "not yet" step)
• Loop Engineering — connectors/plugins (MCP) are one of its five primitives: the reason a loop can act inside your real tools (open the PR, update the ticket, ping the channel) instead of only seeing the filesystem

Open Questions#

• The MCP ecosystem's growth rate vs. computer use's quality curve: at what point does computer use become good enough that the marginal value of building an MCP server drops? Boris implies this is years off but doesn't quantify.
• Is computer use a sustainable interface or a transition technology? If most knowledge-work software adds MCP support in the next 24 months, computer use's role shrinks to legacy/desktop-only systems.
• MCP security model: as the playbook prescribes wiring MCP into Salesforce, Gmail, Calendar for solo founders, the attack surface scales with adoption. Partially answered by Zero Trust for AI Agents (tool poisoning, rug pulls, the first in-the-wild malicious MCP server) — see "MCP as a security surface" above. Open residual: how does a solo founder realistically run/host and self-sign every MCP server the framework recommends, given that the appeal of MCP was zero-integration-effort? Sharpened by ShareLock: the cheaper alternative to self-hosting — scan the tool descriptions with a guard model — is information-theoretically defeated by threshold fragmentation, so the lightweight mitigation doesn't hold and the burden falls back on run-your-own-server or downstream action-layer authorization. And Agentjacking shows run-your-own-server itself isn't sufficient: when the server is a legitimate observability platform relaying attacker-injected data (fake Sentry errors), self-hosting/vetting the server catches nothing — the untrusted input rides in on its data, so the residual burden falls squarely on the downstream data/action layer (provenance tracking + an out-of-band action gate), not on server hygiene.

Resolved Questions#

• How does Cowork's computer-use guardrail compare to Claude Code's auto-mode classifier? Different deployment context, possibly different risk profile. Answered: Classifier Gates vs OS Sandboxing: The Defense-in-Depth Story for Auto Mode and Cowork — same mechanism, inverted role. Cowork's guardrail is auto-mode-style classifier gating on the browser/computer-use surface (the Opus 5 card's browser row is measured on the Cowork harness: 31.5% bare → 3.70% → 0/129 scenarios with auto mode). The risk-profile difference is which layer can be load-bearing: Claude Code's blast surface is local and containable, so the sandbox can be primary and the classifier a convenience; Cowork drives the user's authenticated live SaaS sessions, where no sandbox equivalent exists and actions are less reversible — so the classifier carries the defense alone on the surface with the worst bare-model injection rate. Caveats: vendor-measured on a bounded suite, still a model-based gate (the D2 critique and the ADI forged-data failure shape apply), and the deterministic out-of-band action gate the research points to exists for neither surface yet.

Derived#

• The Future of Agent Interfaces — places MCP, computer use, app protocols, native interaction models, and agent-native infrastructure at separate interface boundaries
• Classifier Gates vs OS Sandboxing: The Defense-in-Depth Story for Auto Mode and Cowork — the Cowork-vs-Claude-Code guardrail comparison: same classifier architecture, opposite containment context
• App Server vs MCP, and the Claude-Side Equivalent: Three Boundaries for Driving Agents — places MCP as the model↔world tool plane against the App Server's session plane; the dynamic-tool-call overlap and the credential-isolation case where an orchestrator-injected tool beats an MCP server

Sources#

• Anthropic's Boris Cherny: Why Coding Is Solved, and What Comes Next — Boris's MCP/computer-use Q&A (Sequoia AI Ascent 2026)
• How Anthropic's product team moves faster than anyone else | Cat Wu (Head of Product, Claude Code) — Cat's daily Cowork+MCP workflow
• The Founder's Playbook: Building an AI-Native Startup — MCP across Idea/MVP/Launch/Scale + moat framing
• OpenID Foundation advances authorization for the agent era with new AuthZEN Working Group Drafts — OpenID Foundation, …advances authorization for the agent era with new AuthZEN Working Group Drafts, 15 June 2026, practitioner-opinion. COAZ (AuthZEN Profile for MCP Tool Authorization — the proposed standards-track authorization decision at the MCP tool-invocation point); proposed Working Group Draft, weighted below the empirical per-call-authz work
• MCP Specification Changelog — 2026-07-28 — Model Context Protocol project, Key Changes changelog for spec revision 2026-07-28, vendor-claim, ~1,200 words. 9 major / 12 minor / 4 deprecated / 1 schema / 1 governance / 1 process entries, all four watched changes explained inline (mandatory server/discover, per-request version negotiation, the _meta protocolVersion key, the deprecated-features registry). Date caveat: the publication date is not independently verifiable beyond the revision path in the URL and the document's own opening reference to the previous revision 2025-11-25 — there is no on-page byline date. Evidence caveat: first-party spec text, so authoritative on protocol requirements and worthless as evidence of adoption, implementation compliance, or security outcome. Discharges both standing MCP-spec revision-watch rows in _system/research-channels.md