What a read-only grant actually depends on#
MCP has no idea what read-only means. The protocol hands a client a list of tools and a way to call them. It does not label a tool safe or destructive, and a client cannot reliably withhold the destructive half on its own, because it only sees names and JSON schemas. So the boundary an IT team can set from outside the vendor's product is the one carried by the access token, and that boundary is described by the scope list the vendor's authorisation server publishes in its protected-resource metadata.
That turns an architecture question into a checkable one. Does this server's discovery metadata offer a scope that reads and a separate scope that writes? We asked it of every server in the catalogue by connecting without credentials on 19 September 2026 and reading what came back. These are observed claims from our own probe, not vendor statements, which matters here: a vendor can describe its permission model in a blog post, but the scope list is what the token will be minted against.
Across all 33 servers, 24 returned HTTP 401 to an unauthenticated initialize, five accepted the connection and answered, and four ship no remote endpoint at all, so there was nothing to probe. Of the 24 that required a token, 16 returned a scope list we could enumerate. Eight of those 16 include a separate read scope. Eight do not. The remaining eight require a token and publish no scope list we could enumerate, so from outside the question stays open.
That last group is the one most often misread. No scope list is not a finding that the server writes everything, or that it is careless. It means the evidence to answer the question is not published, and the answer has to come from the vendor rather than from the wire.
The connectors where you can draw the line#
Separation is not one thing. Among the eight servers that offer it, the published list runs from two scopes to thirty-two, and that range decides whether a grant can match a job or only a mood.
Atlas Verified has the longest list we recorded: 32 scopes covering suppliers, shipments, inventory, verification, documents, signatures, opportunities, intelligence and employees, plus paperwork:write, tradedata:read, ingestion:write and search:read. Fourteen entries end in :read and fourteen end in :write. The remaining four are mcp:*, readonly, chat and documents. Two entries in the same list represent opposite postures, an explicit readonly scope and an mcp:* wildcard, so the grant you request is a deliberate decision rather than a default.
Atlassian is the fullest case among the mainstream office systems: 22 scopes, observed, including read:jira-work and write:jira-work, read:page:confluence and write:page:confluence, read:comment:confluence and write:comment:confluence, plus read:space:confluence, read:hierarchical-content:confluence and search:confluence. Thirteen entries carry a read: prefix and six carry a write: prefix. An IT team can therefore issue a grant that reads the tracker and the knowledge base and creates nothing, which is the shape most first pilots want.
Airtable separates on a second axis that is easy to miss. Its seven scopes are data.records:read, data.records:write, schema.bases:read, schema.bases:write, data.recordComments:read, data.recordComments:write and workspacesAndBases:read. Data and structure are distinct. An assistant can be allowed to read rows in a promotional calendar or a spec tracker while schema.bases:write is withheld, so it cannot add a field, rename a table or restructure a base. Structural writes are the ones that quietly break the reports built on top.
Supabase publishes 13 scopes: organizations:read, projects:read, projects:write, database:read, database:write, analytics:read, secrets:read, edge_functions:read, edge_functions:write, environment:read, environment:write, storage:read and storage:write. Read the list rather than the summary. secrets:read is a read scope, and what it reads is secrets. Read-only on Supabase is not one decision but a choice about which reads, and an evaluator who grants the whole read half has granted more than the phrase suggests.
Linear and Amplitude sit at the other end. Linear publishes read and write. Amplitude publishes mcp:read and mcp:write. The boundary exists and is real, but it is one bit. Neither published list contains a scope that names a team, a project or any other object, so if the scoping you need is by object rather than by verb, it has to be done in the account behind the connector.
Two smaller servers complete the eight. FoodPhoto publishes studio:read, studio:write and billing:checkout, which puts payment authorisation in a scope of its own. Spoonjoy publishes nine: account:read, account:write, cookbooks:read, kitchen:read, kitchen:write, public:read, recipes:read, shopping_list:read and shopping_list:write. Both are small services rather than systems of record, but they show the same pattern: the useful separation is per resource, not per tool.
The ones that do not separate, and the ones that do not say#
Eight servers publish a scope list that contains no separate read-only scope: Figma, GitLab, Microsoft Sentinel Data Exploration, Notion, PayPal, Sanity, Vercel and Zapier. The lists are short and blunt. Notion returns ["default"]. Sanity returns ["global"]. GitLab returns ["mcp"]. Figma returns ["mcp:connect"]. Vercel returns ["openid"]. Microsoft Sentinel Data Exploration returns a single Entra-style scope, 4500ebfb-89b6-4b14-a480-7f749797bfcd/.default. One scope, and no narrower alternative offered alongside it.
PayPal and Zapier are a different case again and deserve to be read carefully. PayPal's observed scopes are openid, email and profile. Zapier's are openid, profile and email. Those are OpenID Connect identity claims, not resource permissions. The read/write boundary for those products is not absent; it is simply not expressed in the OAuth scope list, so it is not something you set when you approve the connection. For Zapier in particular, whose registry description claims 9,000 or more apps and 40,000 or more actions, the permission surface is therefore set somewhere other than the token. Where exactly, and who may change it, is not documented in our data.
Then there are the eight that require a token and publish no scope list we could enumerate: DAG Studio, Cloudflare, crisphive, fmcg.network, January AI Nutrition, monday.com, Stripe and Webflow. Six of them returned both protected-resource metadata and an authorization-server document with a registration endpoint, so the machinery is there and the scope list is just not something we could read from outside. Two behaved differently under probe: January AI Nutrition returned a 401 with a WWW-Authenticate header but no discovery document at either well-known location, and DAG Studio returned a 401 with no WWW-Authenticate header at all.
For anything in either group, the reliable control is not the token but the account behind it. Create a dedicated principal in the source system with exactly the permissions the job needs, and connect the server as that principal. A token cannot exceed what the identity it represents is allowed to do, so a connector with one coarse scope attached to a read-only service account is a tighter arrangement than a granular scope list attached to an administrator. This is unglamorous and it is the move that actually holds.
Two other things are worth doing before a pilot rather than after. Ask each vendor in writing for the scope list and the name of the read-only scope; for the eight above that is eight emails, and the reply is the artefact your security review will want anyway. And where a server can run on your own infrastructure, consider doing so: Supabase and crisphive both declare a package and a hosted remote endpoint, which is the only configuration in the catalogue that lets you choose.
What it costs an IT team to adopt#
Twenty-nine of the 33 declare a hosted remote endpoint. Those 29 servers resolve to 28 registrable domains, 44 distinct hostnames and 64 endpoint URLs in total, so the count of servers is not the count of things egress control has to know about. Cloudflare alone accounts for much of the gap: its single registry entry declares 30 remote endpoints across 15 subdomains, one pair per product surface. Adding that one server can mean approving fifteen destinations.
Twenty-one of the 33 advertise a dynamic client registration endpoint. That makes onboarding pleasant, because a user completes a browser consent flow rather than waiting on a ticket. It also relocates the approval. The moment the grant is decided is a consent screen in front of whoever is setting the connector up, which is fine when the scope list is granular and reviewed, and less fine when the only option is one scope with no narrower alternative.
The sharpest practical constraint is that you cannot inspect the action surface before you authorise it. We captured tool names for four of the 33 servers, and all four were servers that accepted an unauthenticated connection: Microsoft Learn with three tools, RecallRadar with four, ArgusHQ with five, offerhopper with two. For every connector that requires a token, no tool list is recorded, so the action surface only becomes visible once a grant exists. Any review process that assumes you can enumerate capabilities first needs redesigning around a short, revocable trial grant instead.
Source evidence is thinner than the vendor-published label suggests. Twenty of the 33 declare a public repository and 15 declare a licence, so for 13 there is no code to read before connecting. Among those with a recorded push date on 19 September 2026, Stripe, Supabase, Azure and Microsoft Fabric were pushed to that same day, while Vercel's and Microsoft Sentinel Data Exploration's repositories had not been pushed to in 248 days. Eight servers declare credential inputs in their registry record, all marked as secrets.
Only six of the 33 declare an installable package: Supabase, crisphive, Auth0, Azure, Microsoft Fabric and Power BI Modeling. Four of those six declare no remote endpoint at all, which flips the problem. There is no OAuth scope list to inspect for Azure, Fabric, Power BI Modeling or Auth0, because there is no hosted authorisation server in front of them. What the process can reach is whatever the host identity grants it, and that is a question for your own directory rather than for the publisher.
The four questions none of them answer#
Four claims in our schema cover the things a security review asks about a connector: whether tool calls are audit logged, whether an administrator can control who may use it, where data is processed, and how long prompts and returned rows are retained. Across all 33 published servers, all four are undocumented. Not partially, not mostly. Zero of 33, four times over.
This is the finding that ought to change how an evaluation is sequenced. You can often establish, from the wire and in minutes, that a connector will accept a read-only grant. You then cannot establish from any published source whether the resulting reads are logged anywhere you can see, whether a colleague in another region can attach the same connector, or whether the contents of the rows the assistant read are retained by the vendor and for how long. The cheap part of the assessment is the part that can be automated; the expensive part is still a questionnaire.
Near misses are worth naming so they are not mistaken for answers. Amplitude declares two remote endpoints, one of them at mcp.eu.amplitude.com. That is a URL in a registry record. It is not a residency commitment, and data residency is undocumented for Amplitude exactly as it is for the other 32. Cloudflare's catalogue entry includes auditlogs.mcp.cloudflare.com among its 30 endpoints, but that is a Cloudflare product surface the connector can read, not a statement that the connector's own calls are logged.
For a food or beverage business, the practical reading is that the technical work of connecting an assistant to Jira, Confluence, Airtable or a Supabase database is small and the evidence for the boundary is good, while the governance work is unchanged and unautomatable. Budget for the questionnaire. Nothing in the published metadata will shorten it.