What the Rippling MCP server does today
Rippling hosts one MCP server at https://mcp.rippling.com/mcp and calls it a first-party connection. It is switched on by default for every company, but nobody can use it until an admin creates an access assignment in the MCP Gateway under IT. Employees then connect from Rippling's My IT page or from the AI client itself, and sign in with their Rippling account.
The design is unusual. The client does not see a menu of tools. It sees one tool named code, whose description lists the typed functions the signed-in user may call. The model writes a short JavaScript program against those functions, and the program runs in an isolated sandbox with no outbound network access. Credentials, retries and logging live outside the sandbox, so the program never sees a key.
The documented function list is short enough to count. 31 functions in five groups: Rippling AI (1), people and org chart (9), time off (4), hiring (1) and custom objects (16). Nineteen are read-only. Twelve write: request_time_off, create_draft_hire and ten that create, update or delete custom records, fields, categories and objects.
How we checked the live server, with a control for every check
On 1 November 2026 we compared the server's behavior with Rippling's documentation:
- A JSON-RPC call to
/mcpwith no token returns 401 with a Bearer challenge that points at OAuth protected-resource metadata. That matches the documented sign-in with your own Rippling identity. - The control, a POST to a random path on the same host, returns 403, so the 401 is the server answering for its real endpoint and not a blanket rule.
- The OAuth metadata paths answer 403 to an unauthenticated caller, so, unlike some vendors, there is no public scope list or tool list to read. We therefore counted functions from Rippling's published tools reference and did not infer any from the wire.
- The developer index at developer.rippling.com says the same thing in its LLM guidance: the MCP runs as the connected employee, needs a gateway policy and a Rippling AI trial or subscription, and is not a substitute for the REST API.
What we could not do is call a write function, because that needs a paying Rippling company with Rippling AI. Everything below about write behavior is Rippling's documented behavior, not something we triggered.
Two permission layers, and what each one cannot do
Rippling stacks two checks. The MCP Gateway policy decides which functions a person or group may use, built on Supergroups that follow attributes such as department, location and employment status. Separately, the person's normal Rippling permissions still apply, so the agent cannot read or do anything the human could not. When a worker is offboarded, access ends with their identity, and admins can revoke a function company-wide at any time.
This is a good model for an assistant acting for one employee. Its limit is the thing you are trying to prevent in the first place. The policy answers which functions, not how much or how many. A group that may call update_custom_record may call it on every record the user can touch, and a group that may call delete_custom_object is limited by an explicit confirmation, not by a number.
Rippling does add safeguards where the action matters to payroll and people. Time off enters the usual manager approval queue as Pending. A new hire is created as a draft for a person to review and submit. Rate limits are fixed per user, 50 calls per 60 seconds per function bucket, and the Rippling AI helper allows 5 new runs per minute and 10 at once. Those are reliability limits against runaway loops, not spending limits.
Where money is, and is not, in the Rippling MCP
No function in the published list pays anyone. There is no payroll run, no bill pay, no card, no reimbursement approval. Compensation, pay, SSNs, home addresses, personal email and tax IDs are explicitly excluded from what the server returns. For a finance team this is the reassuring half of the story: connecting the Rippling MCP does not give an agent a way to move funds.
The exposure is indirect, and two places deserve a look before you grant write access:
- Custom objects. Rippling lets companies model their own records, and many use them for approvals, budgets, vendor lists or expense requests. Ten of the twelve write functions edit that data. If an object holds a spending limit or a payee, an agent with write access can change the number a downstream workflow trusts.
- Draft hires. A draft needs a human to submit it, which is a sound control, but a flood of drafts is still noise that an approver may click through.
The larger point is architectural. Most companies that connect an HR system to an agent also connect the system that pays: the bank, the card program, the accounts payable tool, a contractor platform. The Rippling policy covers Rippling. It does not carry across to those tools, and an agent that holds both sets of access has Rippling's guardrails in one place and none, or the other vendor's, in the other.
What to set up before you connect it
- Start with read-only functions. Assign people, org chart and balance lookups first. Add
request_time_offafter a week of normal use. - Treat custom-object writes as production data access. Assign them to a small group and look at what those objects feed.
- Keep deletion off. The delete functions need confirmation, but there is no reason to hand them to a general group.
- Use the gateway audit log. Rippling says admins can review logs there. Check it weekly for the first month.
- Never give an MCP client a company-wide API token. Rippling's own guidance says the same. A token inherits its owner's permission profile, and the MCP is meant to be the narrower path.
- Put a separate spend limit on whatever pays. If the same agent can also pay vendors or contractors anywhere else, give that payment path its own per-agent budget and approval rule.
How AgentsPay works alongside Rippling
Keep Rippling as your system for people, devices and app access. AgentsPay covers the part Rippling's MCP deliberately leaves out: the moment an agent spends money. Each agent that can pay gets its own AgentsPay identity with a hard monthly budget and per-transaction cap, merchant and category rules, and approval routing by amount to a named person. Spend that happens by card goes through a scoped virtual card per agent, and every request, approval and decline lands in one audit trail.
If you only use the Rippling MCP to look up colleagues and file time off, you do not need us, and this page is saying so on purpose. If the same agents also pay contractors, renew software or top up APIs, the sibling measurements show where the limits sit in those tools: the Deel MCP server for international contractor payments, the Bill.com MCP server for accounts payable, and the payment MCP servers from Stripe, PayPal and Square.