When the Host Sets the Boundary

“Supports MCP” is not the whole answer

After six modules you have a working MCP server on your own computer. It exposes two tools, one resource, and one prompt, and it works in MCP Inspector.

MCP itself is not the obstacle, but connecting that server to an AI application introduces another question: will this particular AI environment accept this particular kind of MCP connection?

And at Stanford there is one more: what has the managed Stanford environment made available?

Three words to learn

Three layers, three separate answers

1. Protocol — what can MCP support? Tools, resources, prompts, and communication between MCP components.
2. Product — what does this AI application implement? Different applications may expose different MCP capabilities and connection methods.
3. Managed environment — what is available here? Stanford can provide managed editions whose available connectors and settings differ from a personal account or another product surface.

A “yes” at one layer does not guarantee a “yes” at the next.

Step 1 — Look at Stanford Claude’s connections

Open Stanford’s Claude for Education in your browser and go to Customize → Connectors.

Inspect only. Do not connect an account, authorize a service, or enable anything. You are reading, exactly as you did in Module 1.

You will see a table headed Your connectors, with four columns: Connector, Type, Authorization, and Status.

Say that precisely, because the precise version is the useful one: this Stanford Claude environment exposes an organization-managed set of web connectors. It does not give this user a control for adding the local Practice Resource Desk.

That is not the same as saying Stanford bans custom MCP. It is a statement about what this interface offers.

Step 2 — See a different product boundary

Now open Stanford’s ChatGPT Edu and look at Settings.

The first thing to notice is vocabulary. Where Claude says Connectors, this product says Plugins. Same underlying idea, different word — which is exactly why Module 1 taught you to read the interface in front of you rather than memorize names.

At the bottom of the plugin list is an entry called Developer mode. Open it and read it. It lives under Security and login.

The product marks this as an elevated-risk feature and warns that it allows unverified connections that could modify or erase data permanently.

Why can’t we just add the Practice Resource Desk?

Here is the part that surprises people. Even with every permission in the world, the practice server still would not appear in either web application — and the reason has nothing to do with policy.

The Practice Resource Desk runs locally on your computer, and communicates through the local process connection you have been using since Module 1. The Inspector starts it with node server.js and talks to that running program.

The Stanford web environments work with remote web connections — services reachable at an address on the internet — rather than launching a program on your machine.

The Practice Resource Desk and the Stanford web applications are speaking MCP, but they are not using a connection method that lets these web applications start our local server.

Transport is simply the way the MCP messages get from one side to the other. You do not need to know the names of the options; you need to know that two things can speak the same protocol and still have no way to reach each other.

Protocol compatibility is not the same thing as connection compatibility.

Same standard, different doors

MCP Inspector

Can launch and inspect our local Practice Resource Desk directly.

Stanford Claude web

Shows a managed catalog of remote web connectors; this user has no control for adding the local practice server.

Stanford ChatGPT Edu

Exposes developer functionality for unverified remote connections, but the capability is risk-badged and remains off for this exercise; it does not launch our local server.

Stanford Claude Code

Can connect to a local MCP server, but it is a developer-oriented surface and is not required for this tutorial.

Hosts do not have to expose MCP the same way

In Inspector you saw all of it: Tools, Resources, Prompts, and annotations such as the green READ-ONLY badge.

In the tested Claude Code connection to the same server:

• the two tools were surfaced;
• the resource and the prompt were not surfaced in the same direct way;
• the tool annotations were not visible to the model in its initial view of what was available.

The server did not change. The host changed.

That is worth sitting with. The same save_practice_note you ran in Module 6 — the one whose consequence you checked in a file — can appear to one host with its full description and to another as little more than a name. This is one observation about one host, not a rule about all of them; the habit it should build is to ask what this host is showing you.

Stanford also manages which integrations are offered

Stanford publishes approved connector availability for its AI services: Approved Connectors for AI Services↗ (opens in a new tab).

Read that page for what it is. The published list tells you which supported connectors Stanford has documented. It is not evidence that every unlisted connection is prohibited — or approved.

Treating a documentation page as a complete set of rules is a common mistake, and it cuts both ways: people assume permission from silence just as often as they assume prohibition from it. When it matters, ask.

What to notice

The MCP server did not change. The environment around it did.

• Inspector can launch our local server.
• Stanford Claude web presents managed remote web connectors.
• Stanford ChatGPT Edu exposes a risk-badged developer pathway for remote connections, but we left it off.
• Stanford Claude Code can use the local server, but it is a different product surface.

Understanding MCP includes understanding the host and the environment — not just the server.

Checkpoint

You are ready for Module 8 if you can:

• distinguish protocol support from product support;
• explain what a managed AI environment adds to the picture;
• distinguish a local MCP server from a remote web connector;
• explain why our local practice server works in Inspector but cannot simply be added to the Stanford web applications;
• recognize that different hosts can expose the same server differently; and
• explain why a visible developer feature is not the same as a recommendation to enable it.