MCP vs REST API: what actually changes for a Microsoft 365 admin

When I deployed my own MCP for Microsoft 365, I inadvertently exposed five tools. Five, with the entire Microsoft Graph behind it. This was intentional on my part, and this is the most straightforward way to describe the purpose of MCP.

A REST API assumes somebody read it first

Graph is a good API. Graph is also designed for people who sit down, look through the documentation, determine what endpoint they need, read what was returned, and write code accordingly. Reading is done once at the time of designing by a human.

A model does not do any of that. No sitting occurs beforehand. At the point in time when a user asks a question, some entity needs to provide a model with a description of its capabilities at that moment in time, in a form for it to pick from.

Prior to MCP, every product had a different solution to this problem. One vendor produced a plugin manifest, another one created function definitions, the third developed a custom tool wrapper. Same API, three different integrations, and none of them portable.

What MCP actually is

It’s a wire protocol. JSON-RPC, using stdio to communicate with a local server and HTTP to communicate with a remote server. The client connects and makes a call tools/list, the server responds with a list of named tools, each accompanied by a description and a JSON schema for its arguments. The client makes a call tools/call when the model chooses which tool to invoke.

The field that deserves a closer look is description. It is the very text the model will read when deciding if it should use the tool.

{
  "tools": [
    {
      "name": "search",
      "description": "Search SharePoint and OneDrive content the signed-in user can already see.",
      "inputSchema": {
        "type": "object",
        "properties": {
          "query": { "type": "string" },
          "entityTypes": { "type": "array", "items": { "type": "string" } }
        },
        "required": ["query"]
      }
    }
  ]
}

Write those descriptions like code, not like documentation. They are part of what steers the model, and a sloppy one gets your tool called when it should not be.

The difference is that you can count it

A REST surface is many endpoints plus whatever you’re authorised to do according to your token. No-one in your organisation will be able to tell you what an app registration may access because they’ll have to read the scopes you’ve authorised and reason about their cumulative meaning.

An MCP server does this out of the box. Just call tools/list and get your entire surface in one page. Twelve tools with four writing capabilities. That is something an administrator can see and make a decision about.

It shows up in the admin centre now

It became real when, on Microsoft 365 Admin center, Agents > Tools, you have a Registry tab and a Requests tab. You register a remote MCP server and it is put into the queue here.

There are two roles who can approve the registration, AI Administrator and Global Administrator, since approving means tenant wide consent to the Entra permissions the server requests.

If the server is able to discover tools, you will have a Tools tab where each of the tools is listed and can be turned on and off individually. Microsoft itself recommends keeping write and delete tools blocked by default. Otherwise, you don’t have an option to either block everything on the server or allow everything on the server.

The latter situation needs some contemplation you are being asked for tenant wide consent to a set of capabilities you cannot even list.

MCP does not make anything safer

This is what annoys me. There is an awful lot of literature out there right now that views MCP as some kind of security control. It isn’t. The server acts on behalf of the logged-in user, inheriting the very same privileges the user was already privileged to have in the first place. No restrictions, no additions.

The thing that has changed is that the plumbing is now standardized, making it possible to manage the same standard rather than a different standard for each vendor out there.

Mirroring a whole API is the wrong instinct

The first go-to is wrapping all endpoints and shipping two hundred tools. I believe this is an error and that it will age very poorly.

Two hundred tools is not reviewable. No administrator will read that list, so they will either sign off or not based on the reputation of the publisher, which is precisely what the registry does not want to do. They will also complicate the process by putting too many options into the list of tools.

Five tools was not me being modest. It was the number that I could convince somebody to give tenant-wide consent to use them.