OneDrive MCP access for ChatGPT, per person

What does OneDrive MCP access for ChatGPT actually connect?

OneDrive MCP access for ChatGPT, built on Elaichi, connects one Microsoft account at a time. MCP (Model Context Protocol) is the protocol an AI client uses to discover and call tools exposed by a server. Elaichi serves that protocol at one address, https://api.elaichi.ai/mcp, and the same address serves every organization on the platform. Which organization and which person a given client call reaches is determined by the OAuth grant behind its token, not by the URL.

An OAuth grant is the approval a person gives in a browser, naming the app and the scopes it may use. Elaichi's OneDrive connector authenticates with OAuth 2.0 against a Microsoft account. Every call made through a given connection runs as the account that connection was created with, whoever triggers the call from the client side. The identity boundary is fixed at connect time, not at ask time. That single fact determines everything else in this post.

Why does each person need their own Microsoft account connection?

A connection determines whose files get reached; the person making the request does not. If a connection is shared at the use level, every person using it still executes calls under its owner's Microsoft sign-in.

Four structures exist in Elaichi, and only three give each person their own account:

The rollout rule follows directly: one OneDrive connection per person. In Elaichi's Add connection dialog, sharing defaults to Private ("only you can use this connection"). For OneDrive, leave it there. Do not promote it to a team-shared toolbox with a pinned connection.

This lines up with how Microsoft Graph enforces delegated access. In delegated mode, the app's permissions and the signed-in user's permissions are calculated and intersected, so the app never exceeds what that specific user could already do. See Microsoft Learn: Overview of permissions and consent (checked October 2026). If an employee cannot open a finance spreadsheet in OneDrive through their own Microsoft account, no Elaichi connection can read it for them, because the connection is that account.

What can Elaichi's OneDrive connector do, and what can it not?

The OneDrive connector exposes 20 tools:

• 15 read tools
• 1 create tool, 1 update tool and 1 delete tool, all scoped to change-notification subscriptions rather than to file content
• 2 remaining tools: list_all_onedrive_search (search sent as an HTTP POST) and onedrive_subscriptions_reauthorize

Elaichi assigns each catalog tool a risk tier (read, write or destructive) from its HTTP verb and method semantics, not from a human review of what the tool does. list_all_onedrive_search sends its query as a POST body rather than a GET with query parameters. So it is tiered as a write, even though it only reads data. This matters operationally. A blanket restriction rule written against "everything that writes" will also block OneDrive search.

Net capability: nothing in this connector creates, edits, shares, moves, or deletes a OneDrive file. The five non-read tools only manage subscription objects used for change notifications. If the requirement is "ChatGPT drafts a document into a OneDrive folder," this connector does not do that. No permission or restriction change adds that capability, because the tool does not exist in the connector.

In the client's tool list, connected tools are never listed one by one, however few there are. The model finds a OneDrive tool with search_tools and runs it with read_tool (a read) or execute_tool (anything), or with run_code under Code Mode. Each search result says which of the two to use.

How does this compare with Microsoft's own admin consent path?

Three distinct consent models are relevant to anyone deciding how to connect OneDrive to an AI client. Each trades off blast radius against setup friction differently:

The line to watch in Microsoft's own model is Files.Read.All as a delegated permission versus as an application permission. Delegated keeps the signed-in person's own ceiling. Application removes it: a single grant lets an app read any file in the organization whoever triggers the call.

Elaichi's catalog contains 650+ connectors split into two kinds. Most are connectors Elaichi authors and runs itself, OneDrive included. The rest are native MCP connectors, where the vendor runs its own MCP server and Elaichi sits in front of it for sign-in, access control and audit. One Elaichi address is what Claude, ChatGPT, Cursor and Microsoft Copilot all authenticate against. That consolidation matters when an organization runs more than one AI client at once rather than standardizing on a single vendor. Each additional client otherwise means a separate consent flow and a separate place to check what it can reach.

How do you set up OneDrive and ChatGPT, in order?

Two steps below are admin work; the rest belong to each individual user. This sequence assumes the organization is on Elaichi's Gold or Black plan, because restrictions and private sharing controls require one of those tiers.

1. Each person opens Connections in Elaichi, selects Add connection, picks OneDrive, and signs in with their own Microsoft account. Sharing stays set to Private.
2. Elaichi auto-generates a toolbox for each new connection, named after it, kept in sync as the connection changes.
3. An admin adds Elaichi to ChatGPT once, as a single custom MCP app.
4. Each person signs in through Elaichi's consent screen, selects their organization, and approves the requested scopes.
5. An admin writes restriction rules for any role that should not reach OneDrive.
6. An admin reviews the audit log after the first few calls to confirm behavior matches expectation.

On ChatGPT Business, only admins and owners can enable developer mode and deploy a custom MCP app. The path is Workspace settings, then Apps, then Create. Supply the server endpoint and metadata, choose an authentication mechanism, click Scan Tools, complete the authorization prompt, then click Create. Publishing is a separate step: Workspace settings, then Apps, then Drafts, then Publish. See OpenAI help: Developer mode and MCP apps in ChatGPT (checked October 2026). After the first approval, ChatGPT caches a frozen snapshot of the app's tool list. New tools or permission changes require an admin to click Refresh before ChatGPT sees them.

That snapshot behavior is one practical reason to register Elaichi once rather than one custom MCP app per vendor connector. To ChatGPT, Elaichi is a single app. Its visible tool list does not change when a user connects OneDrive, because individual connected tools are never listed by name at the ChatGPT-app level. They are resolved at call time through search_tools, then read_tool or execute_tool, or run_code under Code Mode.

At consent time, a person who ticks "Run your connected tools" then chooses either "All my tools" or "Only the ones I pick," selecting from up to 50 stored toolboxes. There is no consent checkbox that limits a client to read-only calls, because that checkbox governs access to every tier at once. For OneDrive this is moot, since the connector has no write tool. But the same consent screen is reused for connectors that do write, so do not generalize the "it's fine, it's read-only" assumption to other apps. Step-by-step client setup is covered in connecting Elaichi to ChatGPT.

Which roles should not reach OneDrive at all?

Write a block rule naming the OneDrive connector against the role that should be excluded. In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. Excluding a team therefore means identifying the role its members hold and restricting that role.

A contractor on a Guest role is the typical first case. An admin selects that role, adds OneDrive to its block list, and any OneDrive call from that role is stopped inside Elaichi before it reaches Microsoft. The caller sees a refusal stating the tool is restricted for their role by organization policy, with a note that an admin can grant an exception via access request.

The clamp runs on every path that reaches a connected tool: a direct tools/call by name, execute_tool, read_tool, run_code, the toolbox execute operation and each step of a synthetic tool. It is evaluated for the person the call acts as.

Mechanics that determine how a rule resolves:

• Within one layer, all applicable blocks merge, and any block overrides any allow.
• A block on a connector propagates to every fork declared as descending from it.
• Writing or editing restriction rules requires the restriction:manage permission, which among built-in system roles only Org Owner and Org Admin hold.
• A restriction change takes effect about two minutes.

An allow rule that names nothing is a lockout, not a no-op: it blocks every connector and tool for its target. That failure mode is covered in the allow rule that blocks all tools.

If the goal is "allow OneDrive reads, but not the subscription-management tools," name those specific tools in the rule. Do not write a blanket block against write-tiered tools. list_all_onedrive_search is tiered a write despite being read-only, so a blanket write-block silently removes search too.

A restricted tool is not hidden from discovery. A restricted tool is left out of the tools Elaichi offers a client and cannot be called. Search still names it, flagged restricted, with no schema. What a tool restriction looks like end to end traces this from the client's perspective.

execute_tool is only a naming indirection. It unwraps to the tool name and arguments it was handed, then meets the same gates as a direct call by that name. read_tool unwraps the same way and meets the same gates, and then refuses anything that is not a connected read. Neither is a lower permission level, and the caller's restrictions apply to both.

What does the audit log show after a OneDrive call?

Elaichi writes one row per connected-tool call that reaches execution. More precisely, one entry for each connected-tool call that reaches execution (a call refused earlier writes none). For a single-file read, the row also records what the call touched. That target is extracted from the one URL-path argument that names the object.

In the Elaichi console, the summary sentence opens with where the call originated, for example "Using ChatGPT,". The approval line for a read shows "Didn't need approval because it only read data". A call originating from an MCP client shows "Allowed by the access ChatGPT was granted".

One filtering trap: connected-tool calls live in the audit log's assistant category, not the MCP category, because their recorded action name is assistant.toolbox_tool. Filtering to MCP will show client authorization grants, not individual tool calls.

Two limits matter before an audit:

• A call refused at the MCP scope check writes no row at all. The refusal happens before any executor runs, so there is no execution event to log.
• Elaichi retains 90 days of audit history by default. Longer retention requires forwarding to an external log service, which comes with the Black plan, with Datadog as the supported destination.

Audit log read access: every member can see their own events plus events on connections they own or can edit. A member with audit:view can see the entire organization's log. What an AI agent audit log must capture lists the fields to check against your own control requirements.

When you do not need Elaichi for this

If OneDrive is the only application being connected, and ChatGPT is the only AI client in use, a vendor-native connector is fewer moving parts and one less system in the authentication path. The same logic applies if the organization is standardizing on Microsoft Copilot for Microsoft 365 and does not want a second control plane in front of Microsoft Graph. The same decision for the rest of the Microsoft 365 surface is worked through in the Microsoft Teams rollout.

Two cases where Elaichi's OneDrive connector is the wrong tool regardless of client count:

• Write access is required. If ChatGPT must create or edit files in OneDrive, this connector cannot do that. No restriction or permission change adds that capability, because the write tools do not exist in it. That requires either Microsoft's own application-permission path, with its tenant-wide blast radius, or a different connector.
• Free Personal plan. Restriction rules and private connection sharing are not available on Elaichi's free plan. Both are required for the governance model described above, which needs Gold or Black. Gold lists at $15 per user per month in USD, or $10 per user per month billed annually; see pricing. 14-day Black trial, no credit card to start. Buying Gold sets the paid trial to the remaining days rather than granting a fresh 14, so it is one continuous trial rather than two, while buying Black charges immediately. A workspace that buys nothing moves to the free Personal plan

The decision generally changes once a second or third application enters the picture. At that point the open questions become which roles reach which tools across multiple vendors, whose account each call runs as, and what a unified audit record looks like. Three AI clients, each independently connected to different SaaS apps, is where that question gets sharp. That tradeoff is discussed directly in MCP governance. SharePoint, part of the same Microsoft 365 surface, carries a much larger set of write tools and is covered separately in governing SharePoint with delegated OAuth. Broader rollout mechanics are in rolling out Claude and ChatGPT. The full connector list is in the connector catalog, and the underlying access model is documented in governance use cases.