What the Deel MCP server does today
Deel hosts one MCP server at https://api.letsdeel.com/mcp. It speaks JSON-RPC over HTTP with streaming responses, and it works with Cursor, VS Code, Claude Desktop and ChatGPT. Deel recommends OAuth 2 with dynamic client registration, where the client registers itself and the user approves a consent screen. A personal access token in an Authorization: Bearer header is the fallback for clients without OAuth.
Deel's tools reference groups 116 tools by area: contracts and hiring (11), people and HRIS (10), time off and scheduling (12), payments and invoices (13), payroll (2), hiring intelligence (8), benefits and compliance (8), Deel IT assets, orders, seats, policies, agreements, products and warehouses (35 in total), onboarding and immigration (6), and organization and reference data (11). Tools are split into three permission levels: organization tools that need organization scopes, worker tools that act as one individual, and public reference tools.
The payments group is the one a finance team should read slowly. It includes list and retrieve for invoices, payment receipts and payment breakdowns, and three tools that write: createInvoiceAdjustment, updateInvoiceAdjustment and AddOffCyclePaymentForContract. The contracts group includes createANewContract, amendContract and signContract, which change who gets paid and how much.
How we probed Deel, with a control for every check
On 30 October 2026 we checked each claim against the live server and a control that should have behaved differently:
- The MCP endpoint. A JSON-RPC
initializeon/mcpreturned200and the server namedeel-mcp. A POST to a random path on the same host returned404, so the host is not a catch-all. - Public tools. Without any token,
tools/listreturned 8 tools, every one flagged read-only: EOR employment cost, hiring insights, take-home pay and ATS job postings. That matches Deel's note that public operations need no authentication. - A protected tool. Calling
AddOffCyclePaymentForContractwith no token returned401and a challenge naming exactly one scope,off-cycle-payments:write. So the tool maps to a single scope, and nothing in that scope mentions an amount. - The OAuth metadata.
/.well-known/oauth-authorization-serverlists 100 scopes: 52 read, 47 write and the bareopenid. It supports PKCE S256, open dynamic registration and refresh tokens, with no client secret (token_endpoint_auth_methods_supportedisnone). - The endpoint pages. Deel's API index lists the stable 2026-01-01 reference as markdown pages. We read the create and review pages for off-cycle payments and invoice adjustments in full.
Deel OAuth has 47 write scopes and none of them carries an amount
The write scopes that can move or commit money are easy to spot: off-cycle-payments:write, invoice-adjustments:write, invoice:create, treasury-vendorbill:write, global-payroll:write, on-demand-payroll:write, payment-statements:write, timesheets:write, milestones:write and contracts:write. Around them sit 37 more write scopes for people, benefits, IT orders, equity, jobs, legal entities and webhooks.
That is a thoughtful, granular list. Deel's own best practices tell you to request the smallest set of scopes, to separate read from write, and to audit granted scopes. A read-only connection is a good default. The limit is structural: OAuth scopes name a category of action. A token holding off-cycle-payments:write can create an off-cycle payment of any size on any contract the connecting user can see, because the size is simply an input to the call.
The connected person also matters. The MCP server acts with the signed-in user's permissions, so an agent connected by an admin inherits an admin's reach. Access tokens last one hour and refresh tokens 30 days, and each refresh token is single use, so a leaked refresh token that is used first locks the legitimate client out, which is a real operational risk for long-running agents.
The Deel payment calls let the caller skip manual approval
Deel's documentation for Add off-cycle payment (POST /contracts/{contract_id}/off-cycle-payments) describes a one-off payment such as a bonus, a reimbursement or a correction, on top of the scheduled amount. It requires an amount as a plain number, and it offers an optional boolean, is_auto_approved: "If true, the off-cycle payment will be automatically approved as part of the request." The description repeats it: set the flag "to skip the manual approval step."
Create an invoice adjustment (POST /invoice-adjustments) works the same way. A bonus, commission or deduction takes a positive amount in the contract currency, and is_auto_approved, when true, makes the adjustment "approved immediately on creation." Deel also allows recurring adjustments that apply to future invoices, and a group_key that merges adjustments into one invoice line, which only works when auto-approval is on.
The review endpoint is the other half. POST /invoice-adjustments/{id}/reviews records an approve or decline decision, and it needs invoice-adjustments:write, the same scope that creates the adjustment. A token that can create an adjustment can also approve it. Deel does say that, depending on the organization's approval configuration, a review may be processed asynchronously. We could not test how an organization's rules interact with is_auto_approved without a paid account, so we do not claim the flag defeats them. What the documentation does show is that the approval step is a parameter the caller can set, not a gate the caller cannot reach.
What Deel gets right
Deel deserves credit on several counts:
- Read-only is easy. Scopes are paired as read and write for almost every area, so you can connect an agent that can answer "who is on payroll in Germany" and never write.
- Least privilege is the documented advice. The best practices page says to request only what the integration needs and to audit scopes.
- Public tools are safe by design. The cost calculators and hiring insights need no login and are marked read-only.
- Clear audit hooks. Deel recommends logging every tool name, parameter set and status, and its webhooks include an event for an invoice adjustment pending approval.
- Short-lived tokens. One hour access tokens and rotating refresh tokens beat the long-lived keys many vendors hand out.
The gap is not carelessness. It is that a payments platform authorizes actions, while a finance team needs to authorize amounts, payees and totals over time.
What a finance lead adds before an agent touches Deel
The controls an auditor asks about sit outside the tool the agent operates, so the agent cannot edit them:
- A per-agent budget by day and month, counted across every payment the agent triggers, in Deel and anywhere else.
- A per-payment ceiling that the amount field is checked against before the call is made.
- An approval threshold so small, expected payments go through and anything above the line waits for a named person in Slack or email.
- Separation of creating and approving. The agent that proposes an off-cycle payment must never hold the credential that approves it, and
is_auto_approvedshould be blocked by policy rather than trusted to a prompt. - A payee check against the contract, so a payment to a new or changed bank detail is held.
- One audit log that names the agent, the amount, the contract and the human who approved.
How AgentsPay works alongside Deel
Keep Deel as your system for contracts, contractors, payroll and compliance. AgentsPay sits in front of the moment an agent triggers a payment. The agent asks AgentsPay with the contract, payee, amount and reason, and calls Deel only after an approval. AgentsPay holds a per-agent monthly budget and per-payment ceiling, routes anything above your threshold to a person through approvals in Slack or email, and strips is_auto_approved from the request so the agent cannot approve itself. The agent holds no write access to its own policy, and every decision lands in one exportable audit trail.
The same layer covers spend that never touches Deel, such as software and API usage on a scoped virtual card per agent. If you run contractor payouts through other systems too, our measurements of the Rippling MCP server for the HR side, the Bill.com MCP server, the Tipalti MCP server and the Mercury MCP server use the same method, and the payment MCP servers from Stripe, PayPal and Square page puts the market in one table.