Box MCP server is a thin facade over a clean REST API. That pattern only works because Box ships three things almost no other vendor ships at once.

What Box MCP server actually is

The repository at github.com/box-community/mcp-server-box is a Python project. It runs locally (or as a hosted service Box operates on box.com/mcp-server), and it speaks MCP over stdio, SSE, or HTTP. Inside, every tool it exposes is a small wrapper around a Box REST endpoint. There is no business logic of its own. The MCP server is a typed, JSON-RPC-shaped projection of the same api.box.com surface a Box partner integration would already be using.

That shape is exactly what most readers expect when they hear "MCP server." Tools as named functions. Each tool maps to one HTTP call. Auth is whatever the vendor uses (OAuth here, but JWT and CCG also accepted). The host gets a clean tools/list, the agent picks one, the server makes the call, the response comes back. Done.

The shape of an MCP request, on both sides

Same JSON-RPC framing on the wire. Almost nothing else in common.

On the top, the MCP child is doing what reads as classic integration work: take a tool call, translate it to an HTTP request, parse the JSON, return the relevant fields. On the bottom, the MCP child is doing what reads as test automation work: click, paste, press a key, sleep, re-read the UI, and decide whether the UI now contains evidence that the action took. The second pattern exists because some vendors do not give you the option of the first.

The three preconditions Box MCP relies on

The Box pattern is a function of three properties Box happens to ship together. None of them are exotic, but the conjunction of all three is rarer than it looks. Drop any one and the whole shape stops working.

1. A public, documented HTTP API. The MCP server has to be able to call something from a process the user controls. Box has api.box.com, and the resource model has been stable for years. Without this, the MCP server has nothing to wrap.
2. A tenant-scoped credential the host can obtain. OAuth 2.0 here, with JWT and Client Credentials Grant available for service-account flows. The host (Claude, Cursor, Copilot Studio) walks the user through a sign-in once, gets a token, and from then on every tool call is gated by that token. Without this, you cannot let one MCP server be used by many people.
3. A vendor-enforced permission model that runs on every request. The MCP server can ask Box for a file id, but Box returns 403 if the OAuth user does not have access. The agent cannot accidentally read someone else's data because the wire protocol itself checks. Without this, "the AI agent has Box access" becomes "the AI agent has all of Box", which is not a shippable product.

What you do when one of those is missing

Take WhatsApp on macOS as a worked example. The vendor (Meta) does ship a public HTTP API, the WhatsApp Business Cloud API. So the first precondition technically holds. But the Business API is scoped to verified businesses, opted-in template lists, and phone numbers that are explicitly registered for that program. It does not cover the case of a single user routing inbound chat through their personal number, or an agent reading the operator's existing groups, or a small team whose customers all message a normal, non-Business WhatsApp account. For those cases, a Box-shaped MCP server is not buildable, because the vendor's API was not built for those cases at all.

What you can do is give the agent the same level of access the human user already has, by driving the desktop app the human is already signed into. macOS exposes every UI element of every running app through the accessibility framework as an AXUIElement tree. With the right permission grant, a process can read that tree, click elements by coordinate, paste into text areas, press keys, and re-read the tree afterwards to see what happened.

That is what the Swift binary at Sources/WhatsAppMCP/main.swift does. It imports ApplicationServices and AppKit, finds the running process for bundle id net.whatsapp.WhatsApp, walks its AX tree, and exposes eleven MCP tools on top: whatsapp_status, whatsapp_search, whatsapp_open_chat, whatsapp_get_active_chat, whatsapp_send_message, and the rest. Same MCP wire format Box uses. Different mechanism entirely on the other side of the JSON-RPC boundary.

The receipt is the chat itself

Here is the part that is hard to picture from a feature list. When Box MCP's file-upload tool succeeds, the proof is a 2xx and a file id. When WhatsApp MCP's send-message tool succeeds, there is no API to ask. The only place that knows whether the message arrived is the chat. So the server reads the chat back.

The relevant block runs from line 920 of main.swift. It presses Return on the compose field, sleeps one second, walks the AX tree again, collects every element with role AXGenericElement, and looks for one whose accessibility description begins with the literal prefix Your message, . If it finds one and the trailing text matches what the agent asked to send, the JSON-RPC response sets verified: true. If the prefix is found but the text does not match, it sets verified: false and includes the visible bubble in a warning field, so the agent knows what it is actually looking at.

That is the entire delivery confirmation. No webhook. No Meta endpoint. No DLR. The chat is the receipt. It is genuinely strange to read code that uses an OS accessibility API as the source of truth for whether a network operation succeeded, but if you accept that the network operation in question is "a desktop app sent something to its own backend on the user's behalf," the UI really is the most honest place to check.

Which one should you write?

If the system you want the agent to reach is a SaaS with a public REST or RPC API, OAuth, and per-object permissions, you should write something shaped like Box MCP. Often the vendor will already have shipped one and you can just install it. The list of vendors for whom this is true is long: Box, Stripe, Linear, Notion, Slack, GitHub, Salesforce, Atlassian, HubSpot, Cloudflare, AWS, GCP. The MCP layer there is genuinely thin.

If the system is a desktop app whose API is absent or hostile to single-user use, you should write something shaped like WhatsApp MCP for macOS. AX-tree walking, click by coordinate, paste through the clipboard, verify by re-reading the UI. The list of systems for which this is the right answer is also long: WhatsApp consumer accounts, iMessage, Apple Notes, Calendar.app, Music.app, most Catalyst apps, plus a long tail of Mac-only desktop tools. The MCP layer here is much thicker, because half of what looks like the vendor's API is missing and the MCP has to fill it.

The mistake is trying to write one when you needed the other. Trying to wrap a non-existent REST API in a Box-shaped MCP gets you stuck on auth. Trying to drive a Catalyst app in code when the vendor would have given you OAuth is a waste of accessibility permissions and a much larger maintenance surface. The first decision in an MCP project is which side of this line you are on.

Both can run in the same host

Worth saying explicitly: an MCP host does not care which side of this line a given server lives on. The host reads a JSON config, forks the stdio children, and opens HTTP connections to the remote ones. The agent sees one flat list of tools. So a workflow that looks like "pull the contract out of Box, summarize it, send the summary to the customer on WhatsApp" is just three tool calls in the same agent turn: box_tools_files, whatsapp_search, whatsapp_send_message. Two of those three travel over HTTPS to box.com. One of them travels over a Unix domain socket to a Swift process that walks an accessibility tree on the same Mac. The agent does not know.