What a finance team asks, and what it must never be able to do
A controller wants to ask which invoices are still unpaid, what a customer was charged in Q3, and why Friday's payout came in short. None of those questions needs the ability to issue a refund. Stripe MCP access for finance team work is therefore a scoping job rather than a connection job. Connecting the account takes a few minutes. Deciding what the AI client may run is the whole of the work.
Elaichi serves tools to AI clients at one address, https://api.elaichi.ai/mcp. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. Its catalog holds 650+ connectors of two kinds. Elaichi authors and runs most of them itself. The rest are native MCP connectors, where the vendor builds and runs its own MCP server and Elaichi handles sign-in, access and audit in front of it. Check the Stripe connector page and the wider connector catalog before you plan anything. Some vendors run a remote MCP server that Elaichi does not already publish. On Gold, an Org Owner or Org Admin can add that server as the organization's own connector.
Why Stripe MCP access for finance team is not an OAuth scope question
Elaichi's consent screen cannot hold an AI client to reading a connected app. When a person connects ChatGPT, they approve a grant. A grant is the OAuth authorization that ties one client to one organization and one set of permissions. Four boxes decide what that grant covers. "Run your connected tools" (mcp:tools) runs every tier of connected tool, writes and deletes in the connected app included.
"Delete data and remove access" (mcp:destructive) is the box people reach for, and it is the wrong one. It covers Elaichi's own destructive operations: deleting Elaichi data and removing people. It is not consulted when a connected tool deletes something in a payments processor. Leaving "Create and change data" unticked does not make a connected app read-only either. A connected app's create and update tools run on mcp:tools alone.
Two things do hold a client to reads. The first is the toolbox step at consent. With "Only the ones I pick", the person names up to 50 stored toolboxes. The grant then reaches exactly those, re-checked on every call. A toolbox is a named list of tool entries, each pinned to one connected account. The second is a restriction on the person's role. Get this wrong and the fix is expensive: a grant's scopes never change after consent, so the client has to be connected again.
How Elaichi tiers a refund, a payout and a delete
Elaichi works out a catalog tool's tier from its HTTP verb and its unified method name. A list or get method is read only when its verb is GET or HEAD, and otherwise counts as a write. An HTTP DELETE is destructive whatever the method is called, and a delete method is destructive. Everything else, custom methods included, is a write. Where a connector's method documents MCP annotations, the tier comes from those instead. It never drops below the destructive floor of a DELETE.
That rule has an awkward result in payments. A refund and a payout are usually created, not deleted, so they land in the write tier rather than the destructive one. Calling something destructive in Elaichi's sense does not gate it anyway, because mcp:tools covers read, write and delete alike. The tier decides the label at the front of the tool's description. It also decides the annotations Elaichi sends the client and the classification written to the audit log. It decides nothing about permission.
Elaichi re-derives the tier at call time rather than trusting the list a client cached. A custom tool edited from GET to DELETE is dispatched as a delete on its next call. If the tool or one of a composite tool's steps can no longer be resolved, the call is refused rather than run unclassified.
Which rule actually blocks a refund
A restriction does. A restriction names the connectors and single tools a role, or one named member, may reach. In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. So a finance-only rule goes on the role finance holds, or on each member. A rule aimed at a member can only narrow what their role allows, and never replaces or loosens a role rule.
Block rules and allow rules behave differently, and the difference matters here. A block rule matches by name or by stored operation, so renaming a tool cannot slip it past a block. An allow rule matches only the operation Elaichi pinned when the rule was saved. An allow rule also switches on an allowlist for its whole layer. Once a role carries one, every connector and tool that none of its allow rules names is blocked for that role, across every app. So a role held to an app's read tools needs whole-connector allow rules for each other app it uses. An allow rule that names nothing blocks everything for its target.
A block-only layer has the opposite failure. It leaves reachable every tool it does not name, so blocking three refund tools leaves the fourth one live. For a payments connector with dozens of write methods, the allowlist shape is the safer one. The toolbox route at consent is simpler still. Blocks beat allows wherever both apply. Read the mechanics of that asymmetry before writing the rule: why a block matches a tool's name and an allow does not, and choosing between one tool and the whole app.
A role, team or restriction change reaches every surface within about two minutes. Make the change, wait, then try a refund from the client and read the refusal.
The credential behind the connection sets the ceiling
Every call through a connection uses that connection's own bound account, whoever is calling. A connection shared with the team acts in the payments app as the person who connected it, with their permissions there. So the first control is the credential itself. Connect with the narrowest account the processor allows, not an owner account, and treat Elaichi's restrictions as the second layer.
Watch for two accounts of the same connector, such as a test account beside the live one. When several accounts back one tool, Elaichi gives that tool a required connection argument. For 2 to 12 accounts, the schema lists the account labels as an enum. A missing, ambiguous or unmatched value returns an error naming the matching accounts, and nothing is ever defaulted. To fix an argument rather than let the model choose it, pin it as a frozen parameter on a toolbox entry. That pattern is described in locking an agent's tool arguments.
Results are capped per value on the way out: 32,000 characters per string, 200 items per list, 200 keys per object. A cut is always flagged rather than silent, which matters when someone asks for a year of charges.
What the audit log holds after a finance question
Every connected-tool call that reaches execution writes one row. The row records the person, the toolbox the call went through, and the tool's advertised and catalog names. It also records the connector, the connection the call actually reached, the tier and how approval was given. The surface (mcp for an AI client), the client's id, the outcome and what the call touched are recorded too. The target id is the value of the one path argument that names the object, so an invoice id is recorded. Argument names and argument counts are not.
Calls refused before execution write no row: a tool a restriction withholds, a missing scope, an unknown tool name, a rate limit. That is the honest limit of the trail. It records what ran, not what a model tried and could not do. Elaichi keeps 90 days of audit history in the product. For a longer history, forward it to your own log service, where export to your own Datadog comes with the Black plan, which is launching soon. For what a reviewer will ask of these rows, see what an AI agent audit log must capture.
Does ChatGPT's own permission setting hold it to reads?
No. ChatGPT's own setting does not make a connected payments app read-only. OpenAI says full MCP support in ChatGPT, including modify and write actions, is rolling out in beta to the Business, Enterprise and Edu plans. On Business, only admins and owners can enable developer mode and deploy a custom MCP app (OpenAI's developer mode page, checked October 2026).
ChatGPT's app permission options are Always ask, Allow read actions, Allow low-risk actions and Allow all actions. OpenAI says those settings do not override action controls, provider authorization, workspace restrictions or safety protections (OpenAI's app permissions article, checked October 2026). On Elaichi's side, none of the tools that run a connected tool is marked read-only. A client setting that lets read-only tools run unprompted will still prompt on every connected-app call, reads included. It will not make the payments app read-only.
Other clients work the same way. Claude's connector tool permissions take one of three settings: Always allow, Needs approval or Blocked. Anthropic says a setting applies to a whole connector, a category of its tools or a single tool (Anthropic's connectors article, checked October 2026). Codex sets approval per server and per tool, and its writes mode prompts for any tool not marked read-only (OpenAI's Codex MCP page, checked October 2026). Elaichi's tool list never names a connected tool. A client can therefore act only on execute_tool, run_code and the two Elaichi operations that run connected tools, each as a whole. It cannot single out one connected app. Per-app and per-tool control is set in Elaichi.
The order to do this in
- Connect the payments account once, from a signed-in Elaichi session, using the narrowest credentials the processor issues.
- Decide which role the finance readers hold. A member holds exactly one role, so combine permissions into a custom role rather than asking for two.
- Write the restriction on that role: whole-connector allow rules for the other apps the role uses, plus an allow rule naming the payments connector's read tools. Save it, then wait about two minutes.
- Or take the simpler route: build a toolbox of read tools and have each person choose "Only the ones I pick" at consent.
- Have each person add Elaichi in ChatGPT and approve their own grant. The steps are in connecting Elaichi to ChatGPT.
- Test a refund from the client and read the refusal, then check the audit rows for the reads that did run.
When a restriction is the wrong tool
If one person in finance needs read access and your processor publishes its own MCP server, connect that server to their client directly. One person, one app, no second vendor to run, nothing to govern. Elaichi starts to pay for itself when several people need several apps. The case for that is one address, one set of rules and one audit log, made in MCP governance.
And if the answer from your own policy is that no AI client touches payments at all, do not write a restriction. Do not connect the account. A rule that blocks every tool on a connector is a worse version of not connecting it. It leaves a credential in place and a lockout to debug. The same reasoning applied to a ledger rather than a processor is in keeping Xero read-only in Claude.
