What the Tipalti MCP server does today
Tipalti runs one hosted MCP server, at https://mcp.tipalti.com/mcp. Its documentation page was last updated on 11 October 2026 and calls the product a beta that is rolling out gradually: you ask your Tipalti representative whether your account is eligible. It currently works with Claude Enterprise only, and Tipalti says other AI platforms come in a later rollout. So if your team lives in ChatGPT or Copilot, there is no Tipalti connector for you yet.
Setup is short once a Payer administrator turns on AI Integration under Administration. In Claude Code it is one line, claude mcp add --transport http --client-id mcp-public tipalti https://mcp.tipalti.com/mcp, with no client secret. Claude Desktop connects through mcp-remote with the same public client ID. In Claude.ai your IT or AI platform owner adds it as a custom connector, picks "Sign in when needed" and "Use your own OAuth client", enters mcp-public and leaves the secret blank. Each user then clicks Connect.
Once connected, Claude can answer questions about bills (details, statuses and aging), payees, payments and their statuses, virtual account balances and funding requirements, and cards with their transactions. Tipalti says every request is checked against the user's own role and permissions, the scopes the Payer administrator enabled and the account, and that the MCP "doesn't grant any access beyond what you already have in Tipalti." For a controller who wants to ask "which bills over 30 days are still unpaid," that is genuinely useful, and it is the safe place to start.
How we probed Tipalti, with a control for every check
We did not rely on the announcement. On 19 October 2026 we pulled four public sources and paired each with a control that should have produced the opposite result:
- The MCP host.
GET /mcpreturned401withWWW-Authenticate: Bearer resource_metadata=".../.well-known/oauth-protected-resource/mcp", and a JSON-RPCinitializesent by POST without a token also returned401. A randomly generated path on the same host returned404, and so did the root. The host is real, and it is not a catch-all that answers everything. - The OAuth metadata. The protected-resource document and the authorization-server document both publish the same 26 scopes:
openid,offline_access, and a read and a write scope for each of twelve resources. The server supports the authorization code and refresh token grants, PKCE with S256 only, public clients with no secret, and it has no dynamic registration endpoint, so only clients Tipalti has registered (such asmcp-public) can connect. - The API reference.
documentation.tipalti.com/llms.txtindexes the REST reference, and every reference page embeds its OpenAPI 3.0.1 definition (build 2026-08-11). We parsed 36 operations. A random path under the docs returned404. - The limit vocabulary. We searched all 161 input fields on the 12 write operations for approval, limit, max, budget, threshold, cap, ceiling, daily, monthly and cumulative. The search is not blind: it fired on two fields, and we read both by hand. The section below explains why neither one limits the caller.
We did not sign in, so we cannot see the list of tools the MCP server exposes after authentication. Everything on this page comes from what Tipalti publishes without a login, which is also what anyone can re-check.
Read-only today while the OAuth server already lists write scopes
Tipalti is clear that the MCP "is read-only in this release, so it can't create or change anything in your account." We take that at face value, and it is the right call for a beta. The detail worth knowing is where that promise is enforced.
The same authorization server that issues tokens to Claude publishes 12 write scopes next to the read scopes: tipalti.api.payment.write, tipalti.api.payment-batch.write, tipalti.api.payee.write, tipalti.api.invoice.write, tipalti.api.invoice-batch.write, tipalti.api.payment-term.write, tipalti.api.gl-account.write, tipalti.api.custom-field.write, tipalti.api.tax-code.write, tipalti.api.payer-entity.write, tipalti.api.report1099.write and tipalti.api.report1042.write. In other words, read-only is a property of the tools in this release, not of the authorization layer, which already speaks the vocabulary of creating payments and editing payees.
That is not a flaw. It is a preview of where the product is heading, and Tipalti's own pricing page already describes "one agentic AI platform." The practical takeaway for a controller is timing: decide where an agent's payment limit lives before write tools ship, not after a pilot has been running on a token that can suddenly do more.
The Tipalti API can create a 5,000-payment batch with no amount cap
Most agent builders will not wait for MCP write tools. They will call the Tipalti REST API directly, which is what Tipalti's AP integrations already do. Of the 36 published operations, 24 are reads and 12 are writes (7 POST, 5 PATCH, no DELETE). The one that moves money is POST /api/v1/payment-batches, which needs the tipalti.api.payment-batch.write scope.
A single call accepts up to 5,000 payment instructions; more returns an error. Each instruction carries a payee ID, an amountSubmitted with amount and currency, a mandatory unique refCode, an optional scheduled date and a handful of tax switches. That is the whole contract. There is no field for a maximum per payment, a budget for the batch, a running total for the month or the name of an approver.
The API is also fast enough that volume is never the bottleneck. Tipalti's rate limiter allows up to 1,500 requests per minute before it returns 429. Invoice batches take up to 200 invoices per call, with up to 100 lines each. An agent that misreads a CSV, or follows an injected instruction in a vendor email, is constrained by your Tipalti balance and by whatever approval phase your account has, and by nothing in the request itself.
Two credentials can make that call. With the client credentials flow, an app holds a Client ID and Client Secret with its chosen scopes and calls the API with no user present. With the authorization code flow and PKCE, a payer admin authorizes the scopes once and the app keeps a refresh token. Either way, the limit on what the agent pays is not in the token.
isThresholdIgnored and max withholding are switches the caller holds
Our limit search returned exactly two hits across 161 write fields, both on the payment instruction, and both point the same way.
isThresholdIgnored is documented as: "In a case where the payment exceeds or doesn't meet the threshold, indicates whether the system ignores the payment threshold and executes the payment." So Tipalti does keep a payment threshold, which is a real control, and the API lets the caller tell the system to skip it for that payment. isMaxWithholdingApplied does the same for tax: when a payee is unpayable because their tax form is incomplete, it lets the caller pay them anyway at the maximum withholding rate.
Both switches exist for good reasons. Finance teams need to push an urgent payment past a minimum, or pay a contractor whose W-8 is stuck in review. The point for agent design is who holds them. Any process with the batch write scope can set either flag to true, so a threshold you rely on to stop an oversized payment is one boolean away from not applying. If an AI agent writes your batches, those two fields belong on the list of things it should never set without a person.
Supplier bank details can change through the Tipalti API
Vendor bank detail fraud is a classic business email compromise pattern, and it never needs a large payment. It needs one changed routing number. In Tipalti that change is an API call: PATCH /api/v1/payees/{id}/payment-method, under the same tipalti.api.payee.write scope that creates and updates payees.
The request accepts an ACH block with nameOnAccount, accountNumber, routingCode, bankName and accountType, an eCheck or wire block with IBAN and SWIFT, a PayPal email and a check mailing address (PayPal and check are US only, and currency cannot be changed through REST). There is no confirmation field, no second approver and no hold period in the request.
Tipalti does give you real protection around payees. Payees can sit in statuses such as pending review, pending compliance review, pending tax form approval, blocked and suspended, and a payer can require review of updates a payee makes in the iFrame. Those controls are strong for changes made by the supplier. The question for an agent rollout is narrower: should the same credential that pays suppliers also be able to repoint where they are paid? Our answer is no. Keep payee.write off any agent's token, and route bank changes to a person who calls the supplier back on a number already on file.
Tipalti batch approval is real but optional and per batch
Tipalti deserves credit here. Its payment flow guide says that "during implementation, you can choose to configure an approval phase before the payment batch is sent out. If you do, each payment batch will require approval in Tipalti Hub before it's processed." No published API operation approves a batch, so with that phase on, a person in Tipalti Hub has to release the money. That is a stronger default than several APIs we have measured, including the Mercury direct send that skips approval rules entirely, covered on our Mercury MCP server and agent cards page.
Three limits matter for agents. First, the phase is optional and chosen during implementation, so check whether your account has it before assuming it does. Second, it is per batch: a reviewer sees one batch of up to 5,000 payments and approves or declines it as a unit, which is a poor fit for an agent that submits a steady stream of small batches. Third, it knows nothing about which agent created the batch or how much that agent already spent this month.
Insufficient balance is the other built-in brake. A payment without enough funds moves to Pending funds (PENDING_PAYER_FUNDS) and Tipalti notifies you, so the account balance works as a hard ceiling. It is a ceiling on the whole company, though, not on one agent. Tipalti also documents more detailed statuses, including PENDING_APPROVAL, as arriving later.
What a finance lead adds before an agent touches Tipalti
None of this means you should keep AI out of payables. It means the controls an auditor will ask about have to be designed in, and most of them sit outside Tipalti. Before an agent writes to Tipalti, we would put these in place:
- Start with the MCP, read-only. Let Claude answer aging, status and funding questions for a month. It is useful on day one and cannot move money.
- Give each agent its own OAuth app and the narrowest scopes. An agent that pays approved bills needs
payment-batch.writeand reads. It does not needpayee.write,payment-term.writeortax-code.write. - Turn on the batch approval phase and confirm it with your Tipalti implementation contact, rather than assuming it is on.
- Put a per-agent budget and a per-payment ceiling in front of the API. The agent asks a policy service before it builds the batch, and the policy decides by amount, payee and month to date. Our spend controls for AI agents do exactly this.
- Require a named human above a threshold, per payment rather than per batch, with approval routing for agent payments that records who approved what.
- Never let the agent set
isThresholdIgnoredorisMaxWithholdingApplied. Strip them in the policy layer. - Log the agent, not just the user. Tipalti records the token's actions. You also want the agent's identity, the instruction it acted on and the policy decision.
The same pattern applies across the AP stack. We measured the equivalent gaps on the Bill.com MCP server and API, where limits sit behind an admin token, and on the QuickBooks and NetSuite MCP servers, where the vendor governs which tools an agent gets but never the amount.
How AgentsPay works alongside Tipalti
AgentsPay does not replace Tipalti. Tipalti stays your AP system, supplier portal, tax engine and payment rail. AgentsPay sits between your agents and Tipalti and decides, payment by payment, whether a request goes through.
Each agent gets its own identity, a monthly budget, a per-transaction ceiling and an approval threshold with a named approver. Before the agent calls POST /payment-batches, it asks AgentsPay with the payee, amount and reason. Under the threshold and inside the budget, it proceeds. Over the threshold, the approver gets the request with the context and approves or declines. Every decision is written to an audit trail you can hand to an auditor. Because the same policy covers cards, bank transfers and agent payment protocols, a Tipalti payout and a SaaS purchase on a virtual card count against the same budget.
If you are pricing the Tipalti side of this, our Tipalti pricing breakdown covers the published plans and the per-payment fees that an agent drives. The agent side is on our AgentsPay plans and pricing page.