Anthropic Simon Test Exposes the Friction Behind Custom MCP Connections

Anthropic observer Simon Willison connected one custom MCP server to Claude and ChatGPT, but the experiment exposed two very different setup paths. His July 29 test showed that standard chat interfaces can use developer-built tools, despite product gates, remote hosting requirements, and authorization work.

The anthropic simon experiment matters because Model Context Protocol is moving beyond coding agents and desktop configuration files. MCP, an open protocol for connecting AI applications with external tools and data, is reaching everyday chat windows. That expands its audience while making product-level restrictions harder to ignore.

Claude presents the connection as a custom connector. ChatGPT places comparable functionality behind its apps system and developer controls. Both can reach a remote server, yet neither turns that server into a universally portable plug-in. The protocol standardizes communication, while each host still controls discovery, permissions, approvals, and availability.

What Simon Willison’s MCP Test Actually Changed

A custom MCP server can now serve both Claude and ChatGPT without requiring users to leave their standard web conversations.

Willison documented the process in a custom MCP test published on July 29, 2026. The central result was straightforward. A developer can host an MCP server, register it with both services, and expose its tools inside their regular chat interfaces.

That outcome separates this experiment from earlier MCP demonstrations centered on Claude Code, desktop configuration files, or developer-focused clients. Those environments already made tool connections relatively natural. Standard consumer chat products apply another layer of account rules and interface controls.

The server must be remotely reachable. A local process using the standard input and output transport cannot simply appear inside a browser session. The host needs an internet-accessible HTTP endpoint that implements the parts of MCP expected by each client.

Remote access changes the deployment model. A developer is no longer configuring one application to launch one trusted process on a personal computer. The developer is operating a network service that must handle transport security, identity, authorization, availability, and potentially multiple users.

Claude describes these integrations as custom connectors. Anthropic says they can connect Claude with hosted tools and data sources through remote MCP servers. Its current connector guidance lists Claude and Claude Desktop support for eligible individual and workplace accounts.

ChatGPT describes the same broad capability through custom apps and MCP connectors. OpenAI’s interface also distinguishes between creating an app, testing it, approving it, and making it available within a workspace.

That naming difference is more than cosmetic. “Connector” suggests a bridge to an existing service. “App” suggests something packaged, reviewed, and distributed through a host-controlled product surface. MCP can support either model, but the labels shape user expectations.

The server also needs useful tool definitions. Those descriptions tell the model what each tool does, when it should be called, and which inputs it accepts. A technically valid endpoint can still perform poorly when its tools overlap or use vague descriptions.

Willison’s test therefore demonstrated interoperability at the protocol layer, not identical behavior across products. Claude and ChatGPT can discover the same basic capabilities. They can still select tools differently, request different approvals, and present results through different interfaces.

For developers, the memorable fact is not that both companies support MCP in some form. The important change is that one hosted implementation can now reach users inside both mainstream chat products. That makes cross-product testing practical without maintaining two completely separate integration protocols.

Why the Anthropic Simon Result Pressures Both AI Platforms

MCP shifts part of the competitive contest from model intelligence toward control over tools, permissions, and distribution.

The anthropic simon result puts pressure on Anthropic because it created MCP and has promoted the protocol as an open standard. Claude must remain a convincing reference client. If outside servers work more predictably elsewhere, protocol authorship will not guarantee platform preference.

OpenAI faces the opposite pressure. It did not originate MCP, but ChatGPT has an enormous role as an application platform. Developers will expect it to support integrations that already work with Claude and other MCP clients.

This creates a clear contest between protocol portability and platform control. Developers want to describe a tool once and connect it across compatible products. Platform operators want to decide which accounts can connect servers, which actions are permitted, and how risky calls are reviewed.

Claude currently offers a direct custom-connector concept across several account types. Workplace use introduces administrator controls because a connector can expose company data or execute actions. An owner can configure availability, while individual users still authenticate against their own permissions.

ChatGPT applies a more explicit deployment structure. OpenAI’s current developer mode guide says full MCP support is available for Business and Enterprise or Edu customers on the web. It also describes narrower read and fetch access for Pro users.

The distinction becomes important when a server exposes write operations. Searching a document collection carries one risk profile. Updating customer records, publishing content, or deleting a project carries another.

OpenAI says write and modify actions can trigger confirmation, depending on the permission, context, and potential impact. Some especially risky actions can be blocked. Workspace administrators also control whether an app moves from private testing into approved availability.

Anthropic similarly advises users to inspect tool requests and enable only the tools relevant to a conversation. Its warning reflects a basic limitation of agentic interfaces. A natural-language request does not always reveal every external action that a model might consider necessary.

These controls weaken the simplest portability promise. A developer can reuse the server, schemas, and authorization foundation. The developer cannot assume matching access, user flows, confirmation behavior, or model decisions.

That fragmentation is not necessarily a protocol failure. MCP defines a shared language between clients and servers. It does not require every host to adopt the same product policies.

Still, product friction can determine whether protocol compatibility matters in practice. A connection hidden behind administrator settings will reach fewer users than one available from a personal settings screen. A read-only implementation cannot replace a competitor that permits carefully approved writes.

Tool invocation quality adds another source of pressure. The model must choose the correct tool, produce valid arguments, interpret errors, and communicate results. Supporting an MCP transport does not guarantee reliable completion of the user’s task.

Developers should therefore test the same prompts across both platforms. A server might expose identical tools while producing different call patterns. Those differences can reveal whether a description is ambiguous or whether one host applies stricter controls.

The broader competitive question is no longer whether Claude or ChatGPT can call an API. Both platforms can. The issue is which one makes outside capabilities understandable, governable, and dependable for ordinary users.

One Protocol Still Produces Two Setup Experiences

MCP reduces duplicated integration code, but it does not remove the operational steps surrounding a secure connection.

For Claude, the basic route runs through Settings and Connectors. A user adds a custom connector, supplies the remote server address, and completes authentication when the server requires it. Workplace owners may need to enable or configure the connector first.

Anthropic’s server documentation points builders toward the protocol’s authorization specification and official SDK examples. It also notes support for current remote authorization patterns.

For ChatGPT, the route runs through Apps and advanced settings. The user or administrator enables developer access, creates an app, enters the remote MCP URL, chooses authentication, and accepts the warning associated with a custom server.

Business workspace administrators can create and deploy apps for their workspace. Enterprise and Edu environments add role-based controls for developers and users. These rules make the connection part of organizational governance, not merely personal configuration.

The shared technical center is a remote MCP endpoint. Modern remote servers commonly use Streamable HTTP, a transport that carries MCP messages through HTTP requests and streaming responses. That endpoint must support the initialization and tool-discovery exchanges expected by compatible clients.

MCP messages use JSON-RPC 2.0, a structured format for requests, results, notifications, and errors. The protocol defines how a client discovers tools and invokes them. It does not define the underlying business logic behind each tool.

Consider a private research server. It might offer one tool for searching stored documents and another for retrieving a full record. Claude and ChatGPT can discover those definitions from the same endpoint.

The developer still must decide who can search which records. That decision belongs in the server and its authorization layer. Hiding a tool in one client interface is not a substitute for enforcing access at the data source.

OAuth becomes central when the server handles user-specific data. The client sends the user through an authorization flow, receives an access token, and presents that token when calling the protected MCP server. The server then validates the token before returning data.

The MCP authorization specification requires protected-resource metadata for compliant HTTP authorization deployments. That metadata tells a client where authorization services are located. It supports discovery without hard-coding every client-server pairing.

This is where a quick proof becomes a real engineering project. The server needs a stable HTTPS address, correct metadata, redirect handling, token validation, and suitable scopes. It also needs error messages that clients can interpret when authorization fails.

Client registration can create another compatibility issue. Some systems support dynamic registration or client metadata documents. Others expect a client identifier created in advance. A server designed around one assumption might need adaptation before both chat products authenticate cleanly.

A practical implementation should start with a narrow, read-only tool. For example, a team could expose approved project notes through one search function. Users could ask either assistant to find prior decisions without granting update or deletion rights.

That use case also creates a natural bridge to a personal or team knowledge base. MCP can provide the access layer, while the underlying system remains responsible for indexing, permissions, retention, and source quality.

After the read path works, developers can add more precise actions. Each write tool should have an obvious purpose and limited scope. “Update one task status” is easier to review than “execute an arbitrary project operation.”

Tool descriptions deserve the same care as an API contract. The model sees those descriptions when deciding whether to call a function. Vague names increase the chance of incorrect selection, repeated calls, or unnecessary data access.

Input schemas should also reject ambiguity. A tool that changes an account should require a stable account identifier. It should not rely only on a customer name that might match several records.

Responses should return enough structured information for the model to explain what happened. A write tool can include the changed object, its previous state, and the new state. That helps the host present a meaningful confirmation.

Testing must cover more than successful calls. Developers should test expired tokens, revoked permissions, unavailable dependencies, malformed inputs, and attempts to access another user’s records. The two hosts may surface those failures differently.

This explains why adding a custom server can feel long despite an open protocol. MCP removes one category of integration duplication. It does not remove deployment, identity, security review, product configuration, or quality assurance.

The Real Tradeoff Is Portability Versus Trust

The same openness that lets one server reach multiple assistants also gives that server a privileged position between users, models, and sensitive systems.

A custom MCP server can see inputs sent through its tools. It may return content that the model treats as context. If it exposes actions, it may also change external data under the user’s identity.

That combination creates several trust boundaries. Users must trust the chat provider, the MCP server operator, the connected service, and the authorization implementation. Organizations must also trust the descriptions that guide model behavior.

Prompt injection is a major concern. A malicious instruction can be embedded inside data retrieved by a tool, such as a document, support ticket, or web page. The model might interpret that content as a direction rather than untrusted material.

The risk grows when multiple tools are available. Retrieved content could try to persuade the model to call another tool with sensitive arguments. A read operation can therefore become the opening step in an unintended write sequence.

Both Anthropic and OpenAI warn users to connect only trusted servers. That advice is necessary, but trust is not a complete security control. Even a well-intentioned server can contain authorization mistakes or overly broad actions.

The server must validate every request independently. It should never assume that a call is safe because Claude or ChatGPT generated it. Host confirmations can help users, but they do not replace server-side access checks.

Token handling requires particular care. The MCP specification prohibits token passthrough, where a server forwards a token intended for one service to another. Tokens should have a defined audience, and the receiving server should verify that audience.

Least privilege offers the clearest starting point. A research connector should request read access before asking for write access. A calendar tool should not request deletion rights when it only needs to list availability.

Write operations also benefit from narrow semantics. A tool called delete_everything is obviously dangerous, but broad administrative functions can hide similar exposure behind friendlier names. Each action should map to a reviewable user intent.

High-impact operations should support idempotency, which prevents accidental repetition from producing multiple changes. A model might retry after an unclear response. Without safeguards, one requested task could create duplicate records or messages.

Audit logs are equally important. Operators need to know which user authorized a call, which tool ran, what object changed, and whether the host reported confirmation. Logs should avoid retaining unnecessary prompt content or secrets.

Server operators should separate user-facing data from control instructions. Tool results can label untrusted text clearly and return structured fields when possible. Models remain vulnerable to manipulation, but careful output design reduces ambiguity.

The host platforms also face unresolved questions. Their approval prompts must provide enough information for users to understand an action. A generic request to “allow tool access” offers little protection when the tool can perform several operations.

Tool behavior can change after connection. Anthropic explicitly notes that server developers may alter tools without warning. A user who approved a harmless search connector could later encounter broader capabilities from the same endpoint.

Versioning and review can reduce that risk. Organizations can pin deployments, monitor schema changes, and require another review when a tool gains write access. Public server operators can publish change logs and keep scopes stable.

There is also a privacy question around data movement. A company may permit its assistant to search internal records while prohibiting those records from reaching another processor. The MCP server’s hosting location and retention policy become part of the decision.

A secure deployment therefore needs more than a valid connection. Teams should document data categories, permitted actions, authentication scopes, retention rules, incident contacts, and revocation procedures. They should also test how each host reports tool use.

The anthropic simon demonstration proves that cross-platform connectivity is possible. It does not prove that every reachable server is suitable for production. Compatibility is the start of evaluation, not the end.

This distinction matters for knowledge workers who want their preferred assistant to reach private notes or project history. A connector can reduce copying between tools. It can also widen the path through which sensitive context travels.

Teams evaluating that tradeoff should begin with information they can afford to expose under controlled access. A searchable collection of approved engineering documentation is safer than an unrestricted gateway into every internal system.

They can then measure whether the assistant finds correct sources, respects permissions, and explains tool use clearly. Expansion should follow evidence, not the mere availability of an MCP endpoint.

What the Anthropic Simon Experiment Says to Watch Next

MCP’s next test is whether cross-platform servers become routine products instead of specialist integrations assembled through advanced settings.

The first signal is convergence around remote authorization. Claude and ChatGPT both need to connect users securely without custom registration work for every pairing. Broader adoption will strengthen if one standards-compliant OAuth deployment works reliably across both.

If authorization remains full of client-specific exceptions, the portability claim weakens. Developers will still reuse parts of the server, but they will maintain separate setup instructions, metadata, and troubleshooting paths.

The strongest evidence will come from ordinary services publishing one remote endpoint with verified instructions for several assistants. Those services should not require users to paste long-lived API keys into chat settings. Browser-based consent should grant narrow, revocable scopes.

The second signal is how OpenAI expands full MCP access. Current documentation distinguishes full support for managed workplace accounts from more limited Pro capabilities. A broader personal route would place direct pressure on Claude’s custom-connector experience.

A continued emphasis on administrator deployment would point toward a different strategy. ChatGPT apps would function primarily as governed workplace software, while Claude could retain a more direct path for individual experimentation.

Neither route is automatically better. Enterprises often need approval, auditability, and role controls. Independent developers value a short route from a deployed server to a working conversation.

The third signal is how both platforms handle write actions. Search and retrieval make useful demonstrations, but actions determine whether MCP becomes a true application layer. They also create the hardest security and interface problems.

Watch for clearer permission summaries, action previews, confirmation policies, and audit records. A host that explains external effects well can make write tools more usable without pretending they are risk-free.

Developers should also watch whether hosts expose better diagnostics. Connection failures often collapse several possible causes into one error. The problem might involve transport negotiation, authorization metadata, redirect configuration, token audience, or tool-schema validation.

Better diagnostics would shorten the path from a working local server to a dependable remote integration. They would also reduce pressure on server operators to reverse-engineer different host expectations.

Registry and discovery systems represent another important layer. An open protocol does not tell users which servers are trustworthy. Curated directories can help, but they also give platform owners another point of control.

A server listed by one host might remain a manual custom connection in another. Developers then face a distribution problem even when their implementation is portable. Review timelines and listing rules can become competitive differentiators.

Users should therefore distinguish server compatibility from server availability. A service can technically work with Claude and ChatGPT while remaining difficult to find or restricted by workspace policy.

The same distinction applies to interface support. MCP Apps can return interactive interfaces in compatible hosts, while basic tool servers mainly exchange structured data and text. Different support levels can make one integration feel richer despite using the same underlying protocol.

For builders, the immediate strategy is conservative. Host a standards-compliant remote server, start with one narrow read tool, and test identical prompts in both products. Record every difference in authentication, discovery, invocation, and error handling.

Next, introduce a limited write action behind explicit authorization. Confirm that retries do not duplicate changes and that revocation works. Review exactly what each platform shows before the action runs.

For organizations, the decision should begin with the workflow rather than MCP enthusiasm. Identify one repeated task where chat-based access reduces real switching or search effort. Then define the smallest data and action scope needed to complete it.

A good candidate might search approved technical documents and return source links. Another might draft a project update without publishing it. Both create value while keeping final changes under human control.

The anthropic simon search phrase will probably bring readers looking for Simon Willison’s specific experiment. Its lasting value is broader than the setup sequence. The test reveals where protocol standardization ends and platform policy begins.

MCP has crossed an important boundary into the standard interfaces of Claude and ChatGPT. The next question is whether connecting a trusted server becomes boring, predictable, and visible to ordinary users.

Developers can help answer that question now. Choose one low-risk workflow, build a remote endpoint with narrow permissions, and compare both hosts under the same test prompts. The differences will show whether MCP is delivering practical portability or merely a shared technical foundation.