Palantir Ontology MCP: How to Expose Foundry Objects and Actions to AI Agents Safely

Last updated: October 13, 2026

By Omar J, Director, PAL4C Labs

TL;DR Palantir ships two MCP servers. Ontology MCP turns a Developer Console app’s object types, action types, and query functions into tools that outside agents like Claude, Copilot Studio, or Gemini Enterprise can call, with OAuth scopes and an audit trail. Palantir MCP is for builders, letting AI coding tools like Claude Code and Cursor design and edit Foundry resources. Pick by who the agent works for. Our Ontology services team sets both up.

Your company probably has more than one AI agent platform already. Copilot Studio in one department, Claude in another, a LangChain prototype somebody’s proud of. Each of them wants the same thing from Foundry. Live objects, and a safe way to change them.

Until recently, that meant custom glue code per agent. Now there’s a standard plug. The Model Context Protocol is an open standard for connecting AI applications to external systems, and Palantir supports it in two distinct ways. Most of the confusion we hear comes from mixing them up.

This guide explains both servers, how Ontology MCP authentication works, how to set it up and test it, how it compares with OSDK and AIP-native agents, and the governance questions to answer before you flip the switch. If the Ontology itself is still fuzzy, our Palantir Ontology explainer is the better starting point.

What Is MCP, and Why Does It Matter for Palantir?

MCP is an open protocol that lets any compatible AI app call tools and read data from an external system through one standard interface. For Palantir, it means agents built outside Foundry can use the Ontology without custom integration code.

Anthropic introduced the Model Context Protocol on November 25, 2024. Adoption since then has been fast. When MCP moved to the Linux Foundation’s new Agentic AI Foundation in December 2025, the project reported more than 97 million monthly SDK downloads and 10,000 active servers, with Anthropic, Block, and OpenAI as co-founders and Google, Microsoft, and AWS among supporters.

Big numbers. What do they mean for a Foundry customer?

Mostly this. Whatever agent platform your business units pick next year, it’ll probably speak MCP. If your Ontology speaks MCP too, you don’t rebuild the integration every time somebody changes vendors. The Ontology stays the system of record, with its permissions and its Actions, and the agents become interchangeable front ends.

That’s the real argument. Not novelty. Portability.

Ontology MCP vs Palantir MCP, What’s the Difference?

Ontology MCP serves agents that use your data. It exposes objects, Actions, and queries for reading and controlled writes. Palantir MCP serves developers. It lets AI coding tools build and edit Foundry resources, and it can change Ontology types but can’t write Ontology data.

The cleanest description comes from Palantir’s own MCP overview, which says Palantir MCP is designed for Ontology builders and can modify Ontology types but cannot write Ontology data, and points data consumers to Ontology MCP instead.

A quick test. Is the agent helping someone run the business, like rerouting a shipment or closing an alert? Ontology MCP. Is it helping someone build Foundry, like writing a transform or adding a property? Palantir MCP.

Some teams need both. A LangChain agent might write data through Ontology MCP while its developers use Palantir MCP in Cursor to build the app behind it. Palantir’s sample architecture shows exactly that split.

How Does Ontology MCP Work?

You create a Developer Console application, choose which object types, actions, and query functions it covers, and turn on its MCP server. Each exposed Action becomes a callable tool. The agent connects with OAuth and can only touch what the app and the user are both allowed to.

Per the Ontology MCP overview, external agents can read objects, execute predefined actions, and query data. Note the word predefined. The agent doesn’t get raw write access to a table. It gets the same Actions your Workshop users click, with the same validation rules and the same submission criteria.

That’s the design choice we like most about it. If an Action called Reassign Carrier checks that the new carrier serves the destination region, the agent gets that check for free. A badly behaved agent can still call the Action badly. It can’t skip the rule.

Every action an agent performs through Ontology MCP is recorded in the Ontology. When an auditor asks why an order changed at 2:14 a.m., the answer is on the object.

What the agent sees matters as much as what it can do. In Ontology Manager, each Action has an agent tool description field that controls how the tool is described to the model. Write it like instructions for a new hire. When to use it, when not to, what each parameter means. Vague descriptions produce agents that call the wrong Action with total confidence.

How Does Ontology MCP Authentication Work?

Through the Developer Console app’s OAuth 2.0 setup. Use the authorization code grant when the agent acts for a signed-in user, so it inherits that user’s permissions. Use client credentials for headless service-to-service agents running as a service user.

Palantir’s authentication docs are clear that tokens issued for MCP access are scoped to the operations and resources you’ve granted the application. And the user or service user still needs permissions on the underlying objects, actions, and queries. Two locks, not one.

One integration detail worth flagging early. Palantir’s docs note that Microsoft Copilot Studio only supports the authorization code grant with a confidential client. If Copilot Studio is your target, plan the app registration that way from day one.

Our default is authorization code wherever a human is involved. It keeps accountability with a named person, and it means an agent can never see data its user couldn’t open in Workshop.

How Do You Set Up Ontology MCP?

Open the app in Developer Console, go to its MCP page, and switch on the MCP server. Copy the configuration for your agent framework, set up OAuth, then test the connection with MCP Inspector before any real agent touches it.

The steps below follow Palantir’s getting started guide, with the prep work we add in front.

1. Decide the job first. One agent, one business task, a short list of objects and Actions it needs.
2. Create a dedicated Developer Console application for MCP, separate from any app your front end uses.
3. Configure application restrictions so the app only covers the needed object types, actions, and query functions.
4. Write agent tool descriptions in Ontology Manager for every exposed Action.
5. Open the app’s MCP page and turn the server on with the toggle.
6. Set up OAuth with the grant type that fits the agent, and register the client.
7. Connect with MCP Inspector and check that the tool list is exactly what you expect.
8. Connect the real agent, run it against test objects, and review the Ontology’s record of what it did.

Step 2 isn’t our invention. A Palantir Community answer from May 2026 about preventing agents from deleting data recommended Ontology MCP with application restrictions and a separate Developer Console application for the MCP server. Sound advice. It keeps the agent’s reach small and easy to review.

Step 7 is the one that saves the most pain. If Inspector shows a delete Action you didn’t mean to expose, you’ve caught it before an LLM did.

Can’t find the MCP page at all? Availability has varied by enrollment and release track, and a Community thread from March 2026 shows users hitting exactly that. Check with your Palantir admin before assuming it’s a permissions problem.

How Do You Connect Claude Code or Cursor With Palantir MCP?

An admin enables Palantir MCP in Control Panel. Each developer then adds it to their AI coding tool with an npx command, their Foundry URL, and a Foundry token. It runs locally and works with Claude Code, Cursor, Cline, Continue, GitHub Copilot in VS Code, and Windsurf.

According to Palantir’s installation guide, the setting lives in Control Panel under Code Repositories, and access can be limited to specific users or groups. Claude Code users add it at project scope, which the docs recommend.

The available tools page lists more than 80 tools across areas like datasets, Ontology design, object sets, OSDK, code repositories, data lineage, data health, global branching, and documentation search. That’s a lot of reach for a coding assistant. The guardrails matter.

Palantir’s security page for Palantir MCP lays them out.

• Local development use is disabled by default
• No destructive write tools are provided
• Ontology changes go through proposals, and a human has to approve the merge into the main Ontology
• Agents can create new datasets but can’t update or delete existing ones
• Tool outputs go to your LLM provider. With Claude Code, that’s Anthropic

Read that last bullet twice. It’s the one legal and security teams care about.

A known gap from the Community. Builders have reported that Claude Code can’t preview transforms through Palantir MCP, so expect to bounce back into Foundry or VS Code tooling for some testing.

Ontology MCP vs OSDK vs AIP Agents, Which Should You Use?

Use AIP agents built in Foundry when the agent lives inside Palantir. Use Ontology MCP when the agent lives on another platform. Use OSDK when you’re writing your own application code and want typed, programmatic control.

Palantir also lets pro-code agents run inside Foundry. The agents overview describes templates for the Claude Agent SDK, OpenAI Agents SDK, and Google ADK, with agents that authenticate against OSDK, Ontology MCP, and Palantir MCP with scoped permissions out of the box. And Foundry-hosted agents can act as MCP clients to outside MCP servers too, so the plug works in both directions.

Our view, bias disclosed since we build AIP agents for clients. If your users already work in Foundry, keep the agent in Foundry. Our AIP agents guide covers how we build and evaluate those. Ontology MCP earns its place when the users live somewhere else, like Teams or Claude, and you’d rather bring the Ontology to them than drag them into a new app.

What Governance Questions Should You Answer First?

Five. What data leaves Foundry, which Actions agents may call, which grant type each agent uses, who reviews the audit trail, and what happens when an agent gets it wrong.

Palantir’s own Ontology MCP documentation puts the first one plainly, warning that using it with an external client makes data in your Palantir environment available to that client, and telling teams to review data governance and compliance policies before turning it on.

Here’s the checklist we walk clients through.

• Which object properties are sensitive, and are they excluded from the app’s scope? PHI, salaries, and supplier pricing are the usual suspects.
• Is every exposed Action reversible, or does it require human approval inside the workflow?
• Does your LLM provider contract cover the data classes going out, including retention?
• Who owns the agent tool descriptions, and who signs off when they change?
• Who looks at the Ontology’s record of agent actions each week? Somebody named, please.
• What’s the kill switch? Turning off the app’s MCP server should be a known, practiced step.

Healthcare and regulated teams should spend the most time here. Our piece on Palantir in healthcare goes into the data-handling side in more depth.

What Goes Wrong With Ontology MCP Projects?

Too many tools exposed at once, vague tool descriptions, service accounts with broad permissions, and nobody watching the audit trail. Almost every failure is a scoping failure, not a protocol bug.

What we see most.

Exposing the whole Ontology on day one. A model offered 60 tools chooses badly. Start with three to five Actions for one job and grow from there.

Lazy tool descriptions. Update Order is not a description. Update the expected delivery date for one Order after the carrier confirms a new date, never for cancelled orders, is.

Client credentials everywhere, because it was easier to test. Then an agent quietly runs with permissions no single employee has.

No owner for review. The audit trail exists. Nobody reads it. Three weeks later someone finds 400 records changed by an agent that misread a status field.

Treating it as an IT project. It isn’t. The business owner of each Action should approve which agents can call it, the same way they’d approve which roles can.

Start With One Agent and Three Actions

Three takeaways. Ontology MCP is for agents that use your data, Palantir MCP is for agents that help build Foundry, and they solve different problems. Actions are the safety layer, so expose a few well-described ones rather than everything. And settle the data-leaving-Foundry question with security before the first connection, not after.

PAL4C Labs is an independent, Palantir-exclusive consultancy. We design Ontologies, Actions, and AIP agents for operations, supply chain, healthcare, and regulatory teams, and we’re not affiliated with Palantir.

If an agent platform outside Foundry is asking for your Ontology data, send us the one task you’d want it to handle first. We’ll scope the Ontology MCP setup with you, including the Developer Console app, the Actions to expose, and the grant type, and tell you plainly if an AIP agent inside Foundry would serve you better. Our AIP and AI agents practice covers both paths.

Ontology MCP Questions We Hear

So Does Palantir Actually Have an Official MCP Server?

Palantir MCP vs Ontology MCP, Does the Difference Really Matter?

Can Claude or Microsoft Copilot Use Our Palantir Ontology?

How Do You Stop an AI Agent From Deleting Data?

Does Data Leave Foundry When You Use MCP?

Ontology MCP vs OSDK, When Is Code the Better Choice?

Why Can’t I Find the MCP Page in Developer Console?