Mad Fish Elements
Rippling connector

Rippling MCP Connector – People and Payroll Data by Asking

The questions are ordinary: how many people are on each team, who is out next week, what does capacity look like for the quarter. The data lives in Rippling. The gatekeeping is right and proper, and it also means simple questions queue behind busy HR inboxes.

The Rippling connector answers the ordinary questions while keeping the gates. It links the AI you already use, like Claude, ChatGPT, or Copilot, to your Rippling instance through Mad Fish Elements, reading the workforce, organization, compensation, and time-and-attendance data your connection authorizes, and managing leave, groups, and custom objects where your flow calls for it. The sensitive system stays sensitive. The routine questions stop being tickets.

See it

What Your AI Can See

Connect your instance, and your AI reads what your Rippling authorization exposes, and only that: workers and their roles, the org structure they sit in, time and attendance, and the compensation data your scopes permit. The double gate is the design: Rippling's own API scopes decide what the connection can ever see, and Elements' per-person permissions decide who on your team can ask.

Within those gates, planning gets easy. "Headcount by department, and how it changed this year." "Who is on leave the first week of the campaign launch?" "What does the design team's capacity look like against the content calendar?" For marketing operations specifically, the people picture joins the work picture: the same Gateway reads Toggl and Workamajig, so staffing, hours, and project load can answer as one.

Do it

What Your AI Can Do

The write surface is deliberately administrative, not personal:

Leave management

Read and manage leave requests where your flow authorizes it, so coverage planning works from the real calendar.

Groups

Maintain the group memberships that drive access and communication, shown and approved like everything else.

Custom objects

Read and manage the custom records your org models in Rippling, under the same gates.

Full API reach where authorized

The REST and Platform API surfaces are reachable through passthrough for what your scopes permit, so the odd authorized request stays supported.

What it deliberately is not: a way around HR. Compensation changes, employment actions, and anything personnel-sensitive stay in Rippling's own flows with the humans your policy names.

A working session

The Launch Staffing Check

In practiceThe session marketing ops runs before every big push: the campaign launches the first week of November. You ask, "Who on the marketing and design teams is on approved leave that week?" Your AI returns the list: two designers out, one overlapping the heaviest build days. You ask, "What is the design team's tracked load looking like that week?" Toggl answers beside Rippling: the remaining designers are already near capacity. The launch plan shifts a deliverable earlier, this week, while shifting is cheap. The staffing surprise that usually arrives on launch morning arrived three weeks early, as a sentence.

Live answers and approved work stay tied to the connected account and audit trail.
The return

What You Get Back

01

Planning without the ticket queue

Headcount, coverage, and capacity answered on demand, within your scopes.

02

Launches staffed on facts

Leave calendars and team load checked before dates get promised.

03

Org answers for the people who need them

Managers see their slice; the gates hold for everyone else.

04

People data beside work data

Rippling with Toggl and Workamajig, one conversation, when the question spans them.

Use cases

One Conversation, Real Account Work

"Headcount by department, with change since January."
Rippling

The org picture as a visual report, within authorized scopes.

"Who is on approved leave during launch week?"
Rippling

The coverage answer before the promise, not after.

"Add the three new hires to the marketing-tools access group."
Rippling

Group membership maintained on approval, in the audit trail.

"Design team capacity next month against their tracked hours trend."
Rippling · Toggl Track

People and workload in one answer.

"List open leave requests awaiting action."
Rippling

The queue surfaced to the humans who decide.

For in-house teams

Close the expectation gap

Marketing ops and team leads get the planning answers their roles justify, without borrowing HR's afternoon. HR keeps the gates and loses the ticket noise.

For marketing teams
For agencies

Run the whole book

Capacity is the constraint behind every pitch promise. The staffing picture joins the hours and the project load on one Gateway, so "can we take this on" gets answered with the calendar, not optimism.

For agencies
Reports worth sharing

From Live Account to Clear Story

Ask in chat and share the dashboard without building exports or taking screenshots.

Coverage Calendar

Approved leave against key dates. Built for launch planning.

Headcount and Org Board

Teams, roles, and change over time. Built for the quarterly planning cycle.

Capacity Outlook

People available against load trends. Built for the take-it-or-decline decision.

The charts stay sober here: bar for team comparison, calendar-style for coverage, line for headcount trend. And when leadership wants these anytime, the Data Visualization add-on turns your reports into always-current dashboards they open from a link. Ask in chat; share the dashboard.

The useful signals

The Numbers That Matter

Workforce planning runs on a modest set. Headcount by team, with change over time: the org's shape, moving. Coverage: who is out, when, against the dates that matter. Capacity outlook: people available against the load the work systems report. And open leave requests: the queue the humans decide. Deliberately absent from this list: anything personal. No individual performance metrics, no sensitive attributes, nothing your scopes exclude. The gates decide what exists here, and the planning figures above are what most teams gate in. Read coverage before every launch and headcount quarterly, and the ordinary questions stay answered without a single ticket. The extraordinary ones still go to HR, where they belong.

A practical start

Your First Week

Day one: connect within the scopes HR approves; confirm what the connection can and cannot see. The gates are the feature; verify them first; day two: read the org. "Headcount by department." Day three: run the coverage check. "Approved leave over the next month against our launch dates." Day four: pair people with work. "Design team capacity against their tracked hours." Day five: schedule the planning brief. "Monthly, send the coverage calendar and headcount changes." By Friday, the routine planning questions answer themselves inside the gates, HR's inbox is quieter, and the next launch date got promised against a real calendar. Nothing sensitive moved; nothing sensitive will. The connector's first week is mostly proving that, and it should be.

Works best with

Build the Connected View

Pair Rippling with Toggl Track for capacity against actual load, and with Workamajig for people beside projects. Keep access narrower than any other connector while doing it; the per-person permissions exist for exactly this pairing.

A closing note on posture; this connector succeeds by staying small. Narrow scopes; few users; planning questions only; if it ever feels like more than that, tighten it. The value is real: launches staffed on facts, coverage known in advance, headcount answered without a ticket. And the value survives any amount of caution. Set it up narrow; keep it narrow; let the answers earn their place.

Clear limits

What This Connector Will Not Do

It will not exceed your Rippling scopes; what the connection is not authorized to see does not exist to it. It will not handle employment actions, compensation changes, or anything personnel-sensitive; those stay in Rippling's own flows with your HR team. It will not become a surveillance layer; it answers planning questions from data your policy already shares. And access here should be, and can be, the narrowest of any connector: per-person permissions make that real.

Governance

Governed Access Your Whole Org Can Live With

Access is set per person, not per account, so Read seats see everything and change nothing while Write seats create and edit with your approval flow in front of every change. Delete access goes only to people you trust to clean up, and many teams start read-only, check answers against the platform, then widen access as the audit trail earns it.

You choose the level of human review and can change it at any time, while every action records what changed, when, and who approved it. Per-user access means Elements never stores your Rippling password, and your data is never harvested or resold.

Per-user accessRead / write / delete per seatFull audit trailApproval flow on every change
Setup

Setup Takes Minutes

  1. Start your trialCreate your Elements account and connect it to your AI.
  2. Link RipplingSign in through the secure connection screen and choose what to connect. No code and no engineers.
  3. Set permissionsDecide who can Read, who can Write, and who can Delete. Start conservative and widen as trust builds.
  4. Ask your first question"How did we do last month?" is a complete instruction.
FAQ

Rippling Connector Questions

Who should get access to this connector?

Fewer people than any other connector; HR, ops leads, and managers with a planning need, mostly on Read. The per-person permission model exists for exactly this decision.

Can it see compensation?

Only if your Rippling authorization includes it, and only for Elements users you permit. Most tenants scope compensation out of the connection entirely, which the double gate makes simple.

What are the writes actually for?

The administrative edges: leave workflows, group memberships, and custom objects your org models in Rippling. Everything shown first, approved by name, audited; personnel actions are not on this connector, by design.

Will my AI change things without asking me?

No. Your AI acts only with the permissions you set, and changes follow the review level you choose. Read-only seats cannot change anything, because the approval flow is the product working as designed.

Which AI assistants can our team use?

Your team can use Claude, ChatGPT, and Microsoft Copilot, while other AI tools can likely connect when they support MCP, the open standard for linking AI assistants to outside tools.

Is my data used to train anything?

No. Your data stays yours, so nothing is harvested and nothing is resold.

Focus on the Strategy, Delegate the Launch

The teams winning with AI are not handing their accounts to a black box; they keep the strategy and delegate the hands-on-keyboard work, while approvals and an audit trail make it safe to move fast. Connect the account you already have through the Gateway and ask the question you would normally build a report to answer.

Your first 14 days are free. Add your card to start, and cancel before the trial ends to pay nothing.