PeopleForce MCP Server

Overview

I am building 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.

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. 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.
• Four 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 as the final in-process check. 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 will run behind the corporate MCP Gateway, 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

In early development: the server skeleton, the tier model, and all four enforcement layers exist and are under test; the tool surface is being built out. The design is documented here first 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.