What the Plaid MCP servers do today
Plaid runs two MCP servers, and they do different jobs. The Dashboard MCP server is hosted by Plaid at https://api.dashboard.plaid.com/mcp/ over Streamable HTTP. Plaid describes it as a server that "provides Production diagnostics and analytics tools, including tools for debugging Items, reviewing Link conversion data, and checking usage metrics." It works with Production data only, and your team must already be approved for Production with at least one Plaid product.
The second is the local server in the Plaid AI coding toolkit, published as mcp-server-plaid and started with uvx mcp-server-plaid. It runs as a subprocess of Claude Code, Cursor, Codex, VS Code or Zed, and it uses Sandbox credentials. Its four tools search the Plaid documentation, return a prompt for generating mock financial data, fetch a Sandbox access token and simulate webhooks.
So when someone searches for a Plaid MCP for Claude, the official answer is one of these two. Plaid's own setup page is clear that the hosted server "is under active development. Breaking changes may occur, and Plaid currently provides limited support." Community servers that wrap the full Plaid API also exist on directories such as mcp.so and Glama. They are not Plaid products, and they usually expect your Plaid client ID and secret in an environment variable.
How we measured Plaid, with a control for every check
On 24 October 2026 we sent unauthenticated requests to the hosted server and to the standard OAuth discovery paths, and paired each with a request that should fail. We then downloaded Plaid's public OpenAPI specification from the plaid/plaid-openapi repository on GitHub, version 2020-09-14_1.778.0, last committed on 23 October 2026, and parsed it with a script rather than reading it by eye.
The specification describes 350 API operations, 2,476 schemas and 8,443 schema properties. Forty-three operations sit under /transfer, with another 11 Sandbox-only transfer simulators. We ran one regular expression for spend vocabulary (approval, limit, max, budget, threshold, cap, ceiling, daily, monthly, cumulative, velocity) across every Transfer schema, and the same expression across unrelated product areas as a control.
The control matters because a pattern like this can be blind or can match everything. It did neither. It found 20 hits in 665 Transfer properties, 1 hit in 325 Link properties, 1 in 501 Credit properties and 0 in 75 Institution properties. Plaid models money limits in Transfer and almost nowhere else, which is what you would expect. The question is who can set them.
Nine MCP tools and none of them move money
The hosted server's tool list, as Plaid documents it, is plaid_debug_item, plaid_get_link_analytics, plaid_get_tools_introduction, plaid_get_usages and plaid_list_teams. All five read. The local server's four tools work only against Sandbox. Across both, there is no tool that creates a transfer, refunds one, moves funds to or from the Plaid Ledger, or changes a bank account.
The authorization metadata confirms how narrow the hosted server is. Its OAuth authorization-server document, which answered with HTTP 200, lists exactly one scope, mcp:dashboard. In the whole Plaid API, the OAuthScope schema accepts only four values: user:read, user:write, exchange and mcp:dashboard. There is no transfer scope at all. For the API integration flow, your backend requests the token with your client ID and Production secret using the client_credentials grant, and the token expires after 15 minutes.
That is good design for a diagnostics tool, and Plaid deserves credit for keeping money out of it. It also means the MCP server is not where your risk lives. The risk lives one layer down, in the API your agent will be given when someone wants it to actually pay or collect.
Where money really moves is the Plaid Transfer API
Plaid Transfer is Plaid's money movement product. A transfer takes two calls. First /transfer/authorization/create asks Plaid to approve a proposed amount, with a decision of approved, declined or user_action_required. Then /transfer/create sends the money, for the exact amount or, if the amount is left blank, for the maximum that was authorized. Recurring schedules go through /transfer/recurring/create and refunds through /transfer/refund/create.
The TransferNetwork enum lists five rails: ach, same-day-ach, rtp, wire and rfp. RTP and wire settle fast and are hard to claw back, which is exactly why the controls around them matter more once software decides when to call the endpoint.
These endpoints authenticate with your Plaid client ID and secret, not with a scoped OAuth token. Any process holding the Production secret can call any product enabled on your account. If an agent framework, a community MCP server or a tool function wraps /transfer/create, the agent inherits that whole reach.
Transfer is sold only on Plaid's Custom plans, and every authorization and every transfer carries its own fee, which our Plaid pricing plans and Transfer fees guide breaks down.
Plaid Transfer limits are one ceiling for the whole company
Plaid Transfer does have limits, and they are real. /transfer/configuration/get returns eight of them: a maximum single transfer, a maximum single credit, a maximum single debit, a daily credit and daily debit maximum measured over the last 24 hours, and three monthly maximums. A transfer that would exceed them is declined with the rationale code TRANSFER_LIMIT_REACHED.
Three facts about those limits shape what they can do for you. They are set at onboarding by Plaid as part of underwriting your program, alongside reserves and debit hold time. They are read-only through the API: the only configuration endpoint in the specification is the one ending in /get, and changes are requested through the Transfer Dashboard, where Plaid may ask for additional reserves before approving them. And they apply to the whole originator, which is your company, not to a user, an agent, a key or a payee.
That makes them a risk ceiling for Plaid, not a spend policy for you. If your approved daily debit limit is 250,000 dollars, an agent with your secret can use all 250,000 dollars of it in one day without breaching anything Plaid enforces. /transfer/metrics/get will tell you afterwards how much of the limit has been used, which is useful, but it is a meter, not a brake.
The caller chooses the ruleset that judges the transfer
Plaid Signal rules run during transfer authorization, and they are genuinely useful for the risk they were built for: whether the end user's account has the balance to cover a debit and how likely the payment is to come back. You build rulesets in the Dashboard, and you pick one per request with the optional ruleset_key field. If you leave it out, Signal uses the default ruleset.
For agent spend, two details matter. The ruleset is chosen by whoever makes the call, so an agent that builds its own request can name the most lenient ruleset you have. And Plaid documents that its default balance ruleset "is designed to let you proceed with processing transfers by default. When Plaid is unable to fetch the account balance, the default ruleset produces an ACCEPT result." Items verified by micro-deposits or imported with /transfer/migrate_account are approved by default because there is no live data connection to check.
There is also a field that sounds like what you want and is not. user_present on /transfer/authorization/create is meant to separate a person clicking a button from an automated payment, but Plaid's own description says: "This field is not currently used and is present to support planned future functionality." Today, Plaid cannot tell an agent-initiated transfer from a human one by that flag.
Dashboard permissions do not reach the API
Plaid's Transfer Dashboard has proper role-based permissions, including Manage Transfer Limits, and Signal adds a Rule Service Write Access permission for editing rulesets. Plaid's documentation then adds the sentence every security reviewer should read twice: "these permissions only impact Dashboard access and do not apply to actions initiated via the API. A user who has the Production Keys permission or otherwise has access to Plaid Production API keys can still use the API to move funds in and out of the Ledger or initiate a refund, regardless of their Transfer Dashboard permissions."
Read that with an AI agent in the place of the user. The agent never logs into the Dashboard, so none of those roles apply to it. Whatever reaches the agent's runtime, whether a secret in an environment variable or a tool that wraps the API, carries the full API reach of your Plaid team.
What an engineering lead adds before an agent calls Plaid Transfer
None of this means Plaid is unsafe. It means Plaid secures the rail and leaves the decision about who may spend what to you. Before an agent gets a Transfer tool, teams we talk to put five things in place:
- Keep the secret out of the agent. The agent calls a tool on your server, and only your server holds the Plaid Production secret.
- A budget per agent. A monthly and per-transfer amount for each agent, far below the company-wide Plaid limit, checked before
/transfer/authorization/create. - Allowed counterparties. The accounts an agent may credit, so a prompt cannot redirect a payout to a new bank account.
- Your ruleset, not the agent's. The server sets
ruleset_keyfrom policy and never accepts it from the model. - A human above a threshold. Larger transfers, and every wire or RTP payment, wait for a named approver.
If your agents also run month-end work, the same logic applies to the accounting side, which we cover on our QuickBooks, NetSuite and Xero MCP server page.
How AgentsPay works alongside Plaid
AgentsPay sits between your agents and the payment rail. Each agent gets its own wallet with a monthly budget, a per-transaction ceiling, allowed counterparties and an approval threshold routed to a named person. Your server asks AgentsPay before it calls Plaid. If the request fits the policy, the transfer goes ahead on Plaid with the ruleset you chose. If not, it is declined or sent for approval, and either way it lands in an audit trail for agent payments your controller can read.
Plaid keeps doing what it is good at: account linking, balance checks, risk scoring and settlement. AgentsPay adds the part Plaid deliberately does not model, which is a limit per agent instead of per company. The same policy covers agents that pay by card or stablecoin, through spend controls for AI agents that work across rails.