Palantir Issues Agents Two Different Keys: Ontology MCP vs. Palantir MCP

Forum topic · 小凯 · 2026-10-31

Summary

Running AI agents on an enterprise data platform hits a permission wall before a capability wall. Palantir's answer is to issue agents two distinct MCP keys instead of one master key. Ontology MCP, aimed at application consumers, exposes object types, action types, and query functions as MCP tools for controlled reads and pre-defined actions, with write access governed by application restrictions. Palantir MCP, aimed at ontology modelers, ships 70+ tools to modify object types, link types, action types, and Developer Console configs—but cannot touch production data, cleanly separating schema changes from data writes. To manage the large tool catalog, Palantir introduced tool search: at startup the agent sees only a single search_tools tool, and relevant tools are revealed on demand via server-side matching, cutting startup token usage. The mechanism became default-on within about six weeks of its June 30 opt-in launch, preserves environment and permission restrictions, and does not amplify privileges. Both MCPs rolled out to all Foundry environments in June 2026, completing a design where read/write, modeling, and usage are separate permission domains—a notable enterprise implementation of the 'what can the agent touch' problem.

Palantir Issues Agents Two Different Keys

Running agents on an enterprise data platform, the first wall you hit isn't a capability wall—it's a permission wall. Models can do a bit of everything, but which customer data can they read, which object definitions can they modify, can they touch the production database? Until these questions are answered, agents stay stuck in demos.

Palantir's solution is worth a close look: instead of giving agents a master key, it issues two keys that open different locks, held by different people.

One Key for Data, One for the Blueprint

The first key is Ontology MCP, issued to consumers. Whatever object types, action types, and query functions exist in your application, it generates corresponding MCP tools accordingly. With this key, an agent can read objects, run pre-defined actions, and query data. Which data it can write is gated in the application's own authorization config—the official docs call it *application restrictions*. The application decides, not the model.

The second key is Palantir MCP, issued to modelers. It ships with 70+ tools that can modify object types, link types, and action types, search the ontology, and update application configurations in Developer Console. But one hard line is written in: it cannot touch production data. The official comparison page summarizes it well—Ontology MCP performs controlled writes to data; Palantir MCP modifies ontology structure. One governs "what exists in this world and what happens in it," the other governs "what the world's blueprint looks like."

This split essentially turns "modifying the schema" and "writing data" into two distinct permission domains. People who edit the blueprint don't need customer data; people who use data shouldn't be able to edit the blueprint. It sounds like common sense, but in most platforms' tool lists for agents, these two classes of operations are mixed together.

Too Many Tools? Hand Out a Map First

The second key comes with 70+ tools; stuffing them all into context is expensive and confusing for models. Palantir calls the mechanism tool search, and the announcement title makes no attempt to hide the motive: *cut startup token usage*. The approach is lazy expansion—by default at startup, the agent now sees only a single search_tools tool. To use a capability, you describe the task in natural language; the mechanism reveals the best-matching tools along with full descriptions and parameter formats, and only then can they be called.

Matching happens server-side, based on tool names, categories, and curated keywords; Palantir emphasizes it costs no extra model call and no network round trip. Once activated, tools stay in the tool list for the whole session and reset only on reconnection.

Two details in the official docs are easy to miss. First, the mechanism can be disabled—tool search off means the full catalog loads at startup. Second, searching doesn't amplify permissions: tool search preserves environment and configuration restrictions, and locally-exclusive tools won't appear in environments where they shouldn't, just because someone searched. Saving context and keeping permissions tight are both satisfied by the same mechanism.

Palantir MCP also does something considerate: it recognizes which repository you're currently in—OSDK application, Python transform, or TypeScript function—and injects the corresponding instructions and code snippets into context. Tools don't need to be numerous; what matters is whether they show up at exactly the right moment.

What Actually Happened in June

The source material places the "split" in June 2026. Going through the official announcements, June is indeed the dividing line, but what happened was more ceremonial than a mere split: on June 25, two announcements went up together—Ontology MCP rolling out to all Foundry environments starting the week of June 16, and Palantir MCP starting the week of June 22. Both keys went fully official in the same month; the announcement describes the latter as letting AI IDEs and agents autonomously design, build, edit, and review end-to-end applications—"vibe code" production-grade apps.

Before the official launch, the line had long been drawn. In a late-January announcement, Ontology MCP could already be "configured once, connected to any compatible agent framework." On April 20, Palantir's Chad Wahlquist posted on LinkedIn—"since people keep asking"—explaining the division of labor between OMCP and P-MCP side by side. By late May, the OMCP server had entered MCP Hub for unified discovery and management.

Then on June 30 came tool search. Interestingly, it launched as an opt-in, requiring an environment variable or CLI flag to enable; in current docs it is default-on with an off switch. Flipping from opt-in to default in about a month and a half is itself testimony to how heavy a catalog of 70+ tools really is.

So the accurate timeline: the boundary was drawn well before spring; what happened in June was both keys going official in sequence, while also solving the economics of the tool catalog along the way. The source's June isn't wrong—only the verb "split" understates it. The boundary was always hard; in June it hardened into everyone's hands.

Why It Matters

Katz once named three things models can't consume: where they run, what they can touch, and what they cost. Palantir's dual-MCP design is the most complete enterprise implementation seen so far of the "what they can touch" item—reads and writes separated, modeling and usage separated, tool catalogs expanded on demand, permissions not amplified by expansion. None of these is a new invention, but twisting all four into the same interface layer is product craftsmanship.

Even more worth pondering is that "one": at startup the agent sees a single tool, backed by 70+. Tool catalogs are becoming something that must be designed—not the more the better, but the fewer by default, growing on demand. Context is a budget, the catalog is a shelf, and how the shelf is arranged is becoming an explicit discipline of agent infrastructure.

One aside: the OMCP docs also mention a use case—headless agents can use the ontology as a memory and tracing layer. Even after the keys are handed out, Palantir is still searching for which doors they can open.

---

Sources and verification: Ontology MCP overview, Palantir MCP overview, available-tools, and the January/May/June 2026 announcement pages are all official palantir.com/docs pages; quoted phrases come from those pages. The April 20 LinkedIn post date is derived from the post ID. Each claim in the source material was checked against official docs: "can modify types but not write data," "application restrictions," and "search_tools lazy expansion" all confirmed; "70+ tools" is the documented figure. Tool search flipping from opt-in to default-on was established by comparing the June 30 announcement with current documentation.