PeopleForce MCP Server

Overview

I built an MCP server that connects AI agents to PeopleForce, the HR platform — so that questions about people, teams, time off, and org structure can be answered by the assistants people already use, instead of by someone clicking through an HR system on their behalf. Its broad tier is live in production behind the corporate MCP Gateway.

HR data is the sharpest test of agent-tooling governance an organization has. Some of it is broadly shareable inside a company — who works where, on which team, since when. Some of it absolutely is not: recruiting pipelines, compensation. A single MCP server that exposes everything to everyone is not a product; it is an incident. So this server was designed around sensitivity tiers before the first tool shipped.

The Design

• Every tool carries a sensitivity tier. broad for org-wide data, sensitive for recruiting and compensation, and a separate write tier for every operation that changes the system of record. The tier is declared where the tool is registered — there is no untiered tool.
• One codebase, two deployments. A deployment profile selects the exposed tool set at startup: one deployment serves broad tools only, the other serves broad plus sensitive. The same code, audited once, behaves as two differently scoped products.
• Independent enforcement layers, failing closed. A tool outside the deployment's tiers never registers, so it does not exist to be called. A denylist can only narrow the set further — no enable-list exists, so no configuration can widen exposure. A guard middleware rejects out-of-profile calls at call time. Responses are projected before they leave the server, so an answer carries only the fields its tier is entitled to show. And each deployment's upstream API key carries only the category permissions that deployment needs, so even a bypassed process could not fetch what its tier forbids.
• Monotonicity pinned by tests. The test suite exhaustively verifies that no combination of profile and denylist can expose a sensitive tool under the broad profile — the property that matters most is the one the tests are built around.
• Behind the gateway, twice. Both deployments belong behind the corporate MCP Gateway — the broad one already runs there — which owns sign-in and per-user, per-tool authorization; the server itself talks to PeopleForce with a scoped service credential. Layered responsibilities: the gateway decides who may call, the server decides what exists to be called.

Engineering Discipline

The project is young, and the bar was set on day one: a high coverage gate, zero-tolerance linting and typing, structured logging with recursive secret redaction so a credential cannot leak through a log line, and live-tenant tests doubly guarded so they can never run by accident.

Status

The broad tier is live in production behind the MCP Gateway, answering org-wide questions for any employee's assistant. The full tool surface has shipped across all three tiers; the sensitive and write tiers are built and tested against mocked fixtures, and stay dark until an explicit human review of the access matrix signs them off — the fail-closed posture applied to rollout itself. The design was documented before any of it shipped, because the design is the product — with HR data, exposure decisions made carelessly at the start cannot be unmade later. For the broader role context, see AI Product Manager at Spotware.