# Palantir Foundry & AIP Code-First Workflow
I've been programming for years, and I hated going into my build challenge unable to see actual files. My goal is to ship faster by giving Claude Code the whole workflow with full permissions. Ontology, pipelines, and applications become files and structures I know, monorepos included.
The [Developer Toolchain overview](https://www.palantir.com/docs/foundry/dev-toolchain/overview/) is Palantir's maintained index of all SDKs, APIs, MCPs, and developer environments. The CLIs live in npm and GitHub (`@osdk/cli`, `@osdk/maker`, community tools); the new Foundry CLI that drives SuperRepo installs from your enrollment. As of August 2026 the Toolchain overview doesn't index the Foundry CLI; it appears only in the docs sidebar under SuperRepo. These tools overlap in confusing ways. Besides that, the docs are organized by product. They won't tell you which UI operations are genuinely unavoidable vs. falsely assumed to be.
As of August 2026, structural ontology changes (object types, links, actions) go through either Palantir MCP with human proposal approval or Ontology-as-code in the new SuperRepo beta, which compiles a versioned repo into a signed Marketplace bundle that an enrollment installs. Data manipulation is automatable through Ontology MCP (OMCP, GA since June 2026) or the Platform SDK; app deployment through `@osdk/cli` or SuperRepo. For operations that still require the browser, [AI FDE](https://www.palantir.com/docs/foundry/ai-fde/overview/) can handle some of them via natural language from inside Foundry. I'll show you when to use which path and how to hand off.
---
## Routing Summary
**The Claude Code harness handles most of it.** Ontology structure, data operations, transforms, function writing and publishing, app building and deployment, builds, and schedules. The branch-propose-approve loop and the git-tag-publish loop cover the two most common enrollment-authoritative workflows end to end. SuperRepo adds a third, repo-authoritative loop: edit → local preview → tag → Marketplace deploy.
**AI FDE fills specific gaps.** Pipeline Builder, Data Connection, ML/Model Studio, AIP Evals, logic functions, permissions audit, creating function repos, external function config, and LM/embedding integration in functions.
**Manual UI is down to four things.** Workshop/Slate building, Workshop/Slate export, Marketplace uninstall, and function-backed columns. For SuperRepo-native apps the two Workshop rows don't apply; the app is code.
**The one human click that never goes away** is proposal/PR approval, in the enrollment-authoritative model. SuperRepo has no proposal gate; its human step is the Marketplace install.
---
## Decision Framework
The right tool depends on what you're doing, not just whether MCP has a tool for it.
### Which Source of Truth?
Before choosing a tool, decide what is authoritative.
**Enrollment-authoritative.** The live enrollment is the source of truth; tools mutate it under governance. Palantir MCP, OMCP, and the Platform SDK work this way. The immovable human step is proposal/PR approval. Choose this to iterate on a shared, live ontology.
**Repo-authoritative.** A versioned repo is the source of truth; it compiles to a signed Marketplace bundle you install on enrollments. Ontology-as-code and SuperRepo work this way. No proposal gate: deploys are gated by DevOps publishing permissions, and installations are locked against UI edits by default. Choose this for greenfield builds, cross-environment reproducibility, or shipping ontology + functions + frontend as one artifact.
Every decision below sits on this fork. "MCP or SuperRepo?" really asks: should the enrollment or the repo own this change?
### Structural Ontology Changes (object Types, Links, actions)
**Is the logic simple?** CRUD shells, property definitions, link types, basic action types with no computed fields or conditionals. → Use Palantir MCP: `create_or_update_foundry_object_type`, branch, propose, approve. Fast iteration, one human approval click per batch.
**Is the logic complex?** Actions that need `now()`, property snapshots, increments, conditionals, or multi-step edits. → Write `@OntologyEditFunction`s in your TypeScript function repo. Use MCP only if you need the action type shell created first. If the function repo already exists and has CI working, skip MCP for the action type entirely: define the function, tag, publish, then create the action type pointing at it. See "When an operation spans categories" for the full multi-tool workflow.
**Do you need reproducible, version-controlled definitions?** → Use `@osdk/maker` committed to git. No proposal gate, but beta with rough edges. Best when you want the ontology definition to live alongside application code.
**Do you want ontology, functions, and frontend shipped as one versioned artifact?** → **SuperRepo** (beta). It wraps Ontology-as-code in a Foundry CLI with a local Ontology preview and an auto-generated local OSDK, and it compiles to a signed Marketplace product. Best for greenfield TypeScript full-stack; no Python functions or pipelines yet.
### Data Operations, Builds, Deployment, and Configuration
For these categories, the Capability Reference Summary shows which tool handles each operation. The routing is straightforward: OMCP or Platform SDK for data, MCP for builds, `@osdk/cli` for deployment, AI FDE for Data Connection and schedules, manual UI for Workshop/Slate and function-backed columns.
### When an Operation Spans Categories
An object type is simple (MCP), but its actions need computed logic (code), and the action rules need binding (UI). The question is which combination minimizes total steps.
Use Palantir MCP for the object type and link type shells. Write `@OntologyEditFunction`s for the action logic in the function repo. Tag and publish. Then bind the function to the action type in the UI (one click per action: Rules → Function → pick). This is three tools, but each does the part it's best at.
The alternative is defining everything in Ontology-as-code so it's all in one place. This is better when you're setting up a new project from scratch and want the ontology definition version-controlled alongside application code. It's worse for iterative changes to an existing ontology: every change still ends in a Marketplace reinstall, though SuperRepo's local preview now lets you validate before each one.
Rule of thumb: MCP + code to iterate on a live shared ontology. SuperRepo for greenfield full-stack builds where local preview and cross-environment reproducibility matter more than mutating live state.
### The "check MCP first" Rule Still Applies, but only within a Category
The reflexive "this needs UI" answer is wrong about half the time. Always run `ToolSearch` before defaulting to UI instructions. Tested example: object type creation, edit-only properties, and action type shells were all assumed to require UI. MCP had tools for all three. Only function-backed columns and Workshop wiring were truly UI-only.
But "MCP can do it" doesn't mean "MCP is the shortest path." The goal is minimizing total surface area across all tools, not maximizing MCP usage.
---
## Ontology Structure (Defining Object Types, Links, Actions)
Three paths, each with different trade-offs.
### Path A: [Palantir MCP](https://www.palantir.com/docs/foundry/palantir-mcp/overview/) (70+ Tools, proposal-gated)
Palantir MCP (`npx palantir-mcp`) gives Claude Code the ability to create, modify, query, build, and delete against your Foundry enrollment. GA since June 2026, with a tool-search mode that exposes only `search_tools` at startup and loads other tools on demand, which cuts startup token usage. Since July 2026, agents authenticate with scoped permissions out of the box, with no manual client IDs or secrets.
See the capability reference table below for the full tool surface. The short version: MCP can create and mutate ontology types, trigger builds, run SQL, clone repos, create PRs, and delete ontology entities. It cannot express complex action logic, wire function-backed rules or columns, manage schedules, delete non-ontology resources, or skip the human approval gate on proposals and PR merges.
Setup: Follow the [installation docs](https://www.palantir.com/docs/foundry/palantir-mcp/installation/). Requires admin enablement in Control Panel under Code Repositories. See [[Palantir MCP - Persisting Your Token and Hostname]] for making credentials survive terminal restarts. When used locally with Claude Code, MCP tool outputs are sent to Anthropic. Confirm this is compliant with your org's data policies before first use.
### Path B: [@osdk/maker](https://github.com/palantir/osdk-ts/blob/main/packages/maker/README.md), Ontology as Code (beta, no Proposal gate)
The `@osdk/maker` npm package lets you define ontology structure in TypeScript files: `defineObject`, `defineLink`, `defineInterface`, `defineAction`. The package generates ontology artifacts that deploy through Marketplace.
Since August 2026, this syntax ships primarily inside SuperRepo (Path C), which adds the Foundry CLI, a local Ontology preview, and auto-generated OSDK bindings on top of the primitives shown here. Palantir's official feature name is "Ontology-as-code"; the SuperRepo docs link to the osdk-ts GitHub for syntax but don't name the package.
```typescript
import { defineOntology, defineObject, defineLink,
defineSharedPropertyType } from "@osdk/maker";
await defineOntology("com.myorg.", async () => {
const idProp = defineSharedPropertyType({
apiName: "entityId", type: "string",
displayName: "Entity ID",
});
const order = defineObject({
apiName: "order",
displayName: "Order",
pluralDisplayName: "Orders",
primaryKeyPropertyApiName: "orderId",
titlePropertyApiName: "orderName",
properties: {
orderId: { type: "string" },
orderName: { type: "string" },
total: { type: "decimal" },
status: { type: "string" },
createdAt: { type: "timestamp" },
},
});
// defineLink, defineCreateObjectAction, etc.
}, "path/to/output");
```
The workflow: write definitions, commit to a Foundry code repository, tag and publish, install through Marketplace. Claude Code can write and modify these files directly.
This is beta software with rough edges. Run standalone, validation errors surface at Marketplace install, not in code review; SuperRepo's local preview catches much of this earlier. Standalone rough edges: interfaces that fail to map on install, INVALID_ARGUMENT on shared properties, API-name length failures, no virtual-table backing datasources. If an artifact fails on install, check API name length and shared property definitions first.
Install: `npm install @osdk/maker`
### Path C: [SuperRepo](https://www.palantir.com/docs/foundry/superrepo/overview) + Foundry CLI (beta, August 2026)
Announced at DevCon 5, released in beta the week of August 3, 2026. A SuperRepo is one monorepo holding your Ontology definitions, functions, and React application, developed, built, and deployed as one versioned artifact. It wraps the Ontology-as-code primitives from Path B in a Foundry CLI and a local runtime.
What the Foundry CLI gives you locally:
- **Ontology-as-code by default.** Declare object types, links, interfaces, and actions in TypeScript. The code is the source of truth and materializes on the enrollment at deploy. Import existing enrollment types with `foundry import ontology`: the command writes a lock file you commit, and code generation builds on it. Adoption can be incremental, not greenfield-only.
- **Embedded Ontology preview.** Local servers reproduce Ontology behavior. Function-backed actions route through the embedded Ontology; functions run in preview runtimes; seed files rebuild a fresh local database on each start.
- **Local OSDK.** Bindings regenerate automatically from your definitions and feed your functions and app directly. Extend the Ontology and use the new type in one loop, with no SDK republish.
**Install.** The CLI downloads from your enrollment, not npm:
```bash
curl -sS "$FOUNDRY_URL/code/api/extension/install-script" -H "Authorization: Bearer $TOKEN" | bash
```
Then `foundry login`. Windows installs are currently blocked by an unsigned binary (known issue); use VS Code Workspaces in-platform instead.
**Create.** Platform: New > Code repository > Applications > SuperRepo > Open in VS Code. Local: `foundry create`.
**Deploy.** `foundry deploy configure` writes an `env.yml` (target namespace, Project, website domain); commit it. Then either tag the repo in VS Code (Foundry CI deploys) or run `pnpm run build && foundry deploy` from your own CI with a `FOUNDRY_TOKEN` that has DevOps publishing permissions. The compiled product is self-contained, reproducible, and cryptographically signed. No proposal gate; installations are locked by default, so UI edits to installed types require unlocking and are overwritten on the next deploy.
**Scope and status.** Beta; may not be enabled on your enrollment; functionality may change. TypeScript only: Python functions, pipelines, Automate, and the Agent engine/SDK are announced but not available. SuperRepo does not replace the MCP harness for Python or pipeline work.
**Watch for ontology drift.** Locked installations answer most of it: UI edits to installed types require unlocking the project and are overwritten on the next deploy. Code wins by design. Still unspecified: what happens when two SuperRepos claim the same type, and how locking treats imported pre-existing types. Give each object type one owner anyway.
---
## Ontology Data (Reading/Writing Objects, Executing Actions)
### [Ontology MCP](https://www.palantir.com/docs/foundry/ontology-mcp/overview/) (OMCP), For Data read/write
Separate product from Palantir MCP. The key distinction:
||**Palantir MCP**|**Ontology MCP (OMCP)**|
|---|---|---|
|**Purpose**|Modify ontology _structure_ (types, links, actions)|Read/write ontology _data_|
|**Audience**|Ontology builders, developers|Ontology consumers, external agents|
|**Can write data?**|No|Yes (via Actions)|
|**Human review required?**|Yes, proposal process|No (governed by user permissions)|
|**Where configured**|IDE / CLI|Developer Console|
|**Status**|Generally available|Generally available (June 2026)|
In a SuperRepo, early local testing needs neither: seed files populate a fresh local database on each server start, and function-backed actions route through the embedded Ontology. OMCP and the Platform SDK remain the path to real enrollment data.
### [Foundry Platform SDK](https://github.com/palantir/foundry-platform-python), For Everything OMCP Doesn't Cover
The `foundry-platform-sdk` ([Python](https://github.com/palantir/foundry-platform-python)) and `@osdk/foundry` ([TypeScript](https://github.com/palantir/foundry-platform-typescript)) are REST API wrappers covering most of the platform surface outside ontology creation. See the [full API reference](https://www.palantir.com/docs/foundry/api/general/overview/introduction/).
Critical limitation: the SDK only supports _read_ operations for ontology schema definitions. There are no API endpoints to _create_ object types, action types, or link types. This may change; check before assuming it's still true. Use Palantir MCP or `@osdk/maker` for ontology creation instead.
### Pltr-cli, Community CLI Wrapper
A CLI wrapping `foundry-platform-python`. Prefer this over raw SDK calls.
Repo: `https://github.com/anjor/pltr-cli`
Not an official Palantir tool. Extend it for your enrollment's specific operations.
### Foundry-dev-tools, Community Transform Runner
A community Python package (not maintained by Palantir) that lets you run Foundry transforms locally using the same `@transform` decorators as Foundry code repos. Useful for testing without pushing to CI.
Install: `pip install foundry-dev-tools`
---
## Application Building and Deployment
### [@osdk/cli](https://www.npmjs.com/package/@osdk/cli), OSDK Generation and Site Deployment
Generates your typed OSDK package from your enrollment's ontology and deploys built frontends to Foundry-hosted subdomains. Configuration, token setup, and usage are in the [npm README](https://www.npmjs.com/package/@osdk/cli). Inside a SuperRepo, the OSDK regenerates locally and automatically on every Ontology-as-code change, with no republish; `@osdk/cli` remains the path outside SuperRepo.
### [OSDK](https://www.palantir.com/docs/foundry/ontology-sdk/overview/) (Ontology SDK), Your App's Typed Interface to Foundry
Generated from Developer Console for your specific ontology. Available in TypeScript (`@osdk/client`), Python, and Java. For React apps, [`@osdk/react`](https://www.palantir.com/docs/foundry/ontology-sdk-react-applications/overview) (GA May 2026) provides hooks and built-in caching on top of `@osdk/client`. This is how you build a standalone app backed by Foundry without touching Workshop.
### [Compute Modules](https://www.palantir.com/docs/foundry/compute-modules/overview/), Containerized Backend Logic
Dockerized Python/TypeScript/Java running on Foundry's compute. Use for agent backends, custom API endpoints, or heavy processing.
### [Custom Endpoints](https://www.palantir.com/docs/foundry/custom-endpoints/overview/), Foundry as a REST Backend
Custom URL patterns backed by ontology actions and functions. Created through the browser UI (requires admin-approved subdomain), but once deployed, callable via curl from Claude Code without touching Foundry.
### [Palantir VS Code Extension](https://www.palantir.com/docs/foundry/palantir-extension-for-visual-studio-code/overview/), Local Transform Development
Installs locally (separate from VS Code workspaces on Palantir infrastructure). Adds transform preview, debug, build, and type hints. Requires enrollment permissions for local development in Control Panel.
---
## AI FDE (In-Platform Agent)
[AI FDE](https://www.palantir.com/docs/foundry/ai-fde/overview/) is Palantir's in-platform AI agent. It operates Foundry through natural language conversations inside the browser.
AI FDE is not part of the Claude Code harness. It's a separate execution layer for operations the harness can't reach. (SuperRepo and the Foundry CLI, by contrast, are part of the harness: local git, local preview, bash.) It does not produce code artifacts and does not integrate with your local git workflow. Plan in Claude Code, hand off to AI FDE for specific browser-only tasks, come back.
### Structural Comparison
|Capability|Claude Code Harness|AI FDE|
|---|---|---|
|Custom system prompt (CLAUDE.md)|✅ Persists across sessions, encodes decision framework, patterns, institutional knowledge|❌ Context resets per session. Can paste text but can't enforce behavioral rules|
|Custom skills|✅ Extensible (product evaluator, writing audit, etc.)|❌ Fixed skill set defined by Palantir|
|Web search|✅ Real-time research, documentation lookup, fact-checking|❌ Limited to `search_foundry_documentation` and `load_documentation_bundles`|
|Arbitrary bash execution|✅ curl, jq, sed, Python scripts, npm, custom CLIs|❌ Only enumerated tool calls|
|Local filesystem + git|✅ Clone, branch, edit, test, commit, tag, push in one loop|❌ Edits via Code Workspaces or authoring interface|
|Multi-tool composition|✅ Palantir MCP + OMCP + Slack + Google Drive + any MCP in one session|❌ Foundry tools only|
|Compliance perimeter|⚠️ MCP tool outputs sent to Anthropic. LLM context stays within Foundry if ANTHROPIC_BASE_URL uses Foundry's LLM proxy. Check org policy for the MCP data path|✅ Runs entirely within Foundry|
### Known Limitations
AI FDE's planning sub-agent is a black box. You cannot tune its decision-making, sequencing, or retry logic. For multi-step builds, plan in Claude Code and hand off bounded tasks.
Notepad operations are unreliable. AI FDE tends to rewrite entire documents instead of making targeted edits, and often fails. Draft content in Claude Code, then paste a focused "create this exact content" task.
AI FDE has no web search. It cannot research community solutions, GitHub issues, or anything outside Foundry's internal documentation system.
### Handoff Format: Claude Code → AI FDE
AI FDE is good at receiving specific, bounded tasks. The handoff should be a self-contained instruction block that doesn't depend on context AI FDE can't access.
Claude Code should populate RIDs and resource names before generating the handoff. Run `search_foundry_ontology`, `search_datasets`, or SQL queries to resolve references first.
```
## Task
[One sentence: what to do]
## Mode
[Which AI FDE mode to use]
## Skills to Enable
[Any disabled-by-default skills needed: notepad, executeAction, filesystem, subagents]
## Tools to Limit
[Disable tools/modes not needed for this task. AI FDE performs better with fewer tools loaded]
## Context to Load
[Specific resources AI FDE should add to context: dataset RIDs, object type names, repo names]
## Steps
1. [Specific action]
2. [Specific action]
3. [Verification step]
## Expected Result
[What success looks like, and what to check before reporting done]
## If It Fails
[What error to expect and what to try instead]
```
**Example: Data Connection Handoff**
```
## Task
Create a JDBC Data Connection source for the PostgreSQL staging database.
## Mode
dataConnection
## Skills to Enable
None needed (Data Connection mode has its own tools)
## Tools to Limit
Stay in dataConnection mode. Do not switch modes.
## Context to Load
- Project: ri.compass.main.folder.<project-rid>
- Target folder for sync datasets: ri.compass.main.folder.<folder-rid>
## Steps
1. Create JDBC source: host staging-db.internal.example.com:5432, database prospect_staging, driver PostgreSQL
2. Create egress policy allowing outbound to staging-db.internal.example.com:5432
3. Sync `prospects` table to new dataset in target folder
4. Run test sync
## Expected Result
Dataset has rows. Sync status shows success.
## If It Fails
- "Connection refused" → egress policy missing or wrong port
- "Authentication failed" → re-enter credentials in source config
```
**Example: Schedule Handoff**
```
## Task
Create a daily build schedule for the prospect_pipeline dataset.
## Mode
dataIntegration (with schedules: true)
## Skills to Enable
None needed (schedules are a dataIntegration toggle)
## Tools to Limit
Stay in dataIntegration mode with schedules enabled. Disable Pipeline Builder tools if offered.
## Context to Load
- Dataset: ri.foundry.main.dataset.<dataset-rid>
## Steps
1. Create daily build schedule, 06:00 UTC
2. Confirm schedule active, next run tomorrow 06:00 UTC
## Expected Result
Schedule active, next run visible.
## If It Fails
- Missing upstream deps → add them to schedule or check lineage
```
For operation-level detail on what AI FDE can and can't do, see the Capability Reference below.
---
## LLM Routing
Palantir provides LLM-provider-compatible proxy endpoints:
- Anthropic: `/api/v2/llm/proxy/anthropic/v1/messages`
- OpenAI: `/api/v2/llm/proxy/openai/v1/chat/completions`
- xAI (beta): `/api/v2/llm/proxy/xai/v1/chat/completions`
- Google (beta): `/api/v2/llm/proxy/google/v1/models/{model}:generateContent`
Set `ANTHROPIC_BASE_URL` to route Claude Code through Foundry. See the [LLM-provider compatible APIs docs](https://www.palantir.com/docs/foundry/aip/llm-provider-compatible-apis/). The benefit is data governance: all context stays within Foundry's compliance perimeter with rate limiting, zero data retention (ZDR), and usage tracking. This does _not_ give you free tokens. You burn your enrollment's LLM capacity.
---
## Patterns (Tested, May 2026)
### Move Action Logic into TypeScript
When an action needs static values, computed expressions, `now()`, property snapshots, or conditionals, write `@OntologyEditFunction`s in the function repo. Don't describe the Ontology Manager's action rule editor or walk through it. Users without UI experience won't know what the Override builder, hidden parameters, or dot-notation property references mean. The code path replaces all of that with a single function:
```typescript
@OntologyEditFunction()
@Edits(Prospect)
public passProspect(prospect: Prospect, reason: string, notes?: string): void {
prospect.disposition = "PASS";
prospect.dispositionPolicyExpiration = prospect.expirationDate; // snapshot
prospect.attemptCount = (prospect.attemptCount ?? 0) + 1; // increment
prospect.lastAttemptDate = Timestamp.now(); // now()
}
```
UI work collapses from "build complex rules in the action editor" to one dropdown selection per action: Action → Rules type = Function → pick. Three clicks total for three actions.
### Edit `resources.json` in a Commit, not in the UI
The repo's `resources.json` has a "DO NOT MODIFY THIS FILE" comment. Ignore it for additions. CI regenerates `@foundry/ontology-api` based on its contents on every build. Adding an object type import:
```json
{
"objectTypes": [
{ "rid": "ri.ontology.main.object-type.<uuid>" }
]
}
```
Push, CI regenerates the typed bindings, TypeScript imports resolve. No "Resources panel → add object type" UI step. The "DO NOT MODIFY" warning applies to editing existing entries, which can confuse the generator. Adding new well-formed entries is safe.
### Functions Publish on Git Tag, not on PR Merge
Foundry function repos use semver tags as the publish trigger. Merging a PR to master runs CI but does _not_ register functions. The full sequence:
```bash
git tag -a 0.2.0 -m "add prospect actions"
git push origin 0.2.0
```
Merge → tag → publish job runs → functions register. Three steps, all scriptable.
### Branch + Propose for Every Ontology Change
This is the enrollment-authoritative loop. SuperRepo replaces it with tag → Marketplace deploy (no proposal gate).
Every ontology mutation tool requires a `globalBranchRid`. Workflow:
1. `create_global_branch` named for the change
2. Make all changes (object types, action types, link types, deletions)
3. `create_global_proposal`
4. User clicks Approve in the UI (one click, intentional human gate)
The branch is the staging area. The proposal is the PR for ontology. Once this pattern works, reuse it for every ontology operation: creating, modifying, and deleting all follow the same flow.
### SuperRepo: Local Preview Before Deploy
The SuperRepo loop is not branch → propose → approve. It is:
1. Edit ontology, functions, and app in the monorepo.
2. Run the Foundry CLI: embedded preview, function runtimes, regenerated OSDK, seed data. Validate the whole feature locally.
3. `git tag` a semver version (or `pnpm run build && foundry deploy` from CI).
4. Foundry CI compiles and installs the signed Marketplace product.
No proposal gate; the human step is the Marketplace install, gated by DevOps publishing permissions. Catch validation errors (interface mapping, shared properties, API-name length) in preview, not at step 4.
### Dependency-order Deletions
When deleting an ontology subgraph: actions first, then links, then object types. Inline action types attached to a property cascade-delete automatically when their parent object type is deleted. Don't fight to delete them first.
If a deletion errors "still has references," read the error parameters. They name the blocking RID.
### Marketplace Block as Deletion Unit
If everything inside a folder came from a single Marketplace install, uninstall the block rather than deleting resources one by one. One UI click vs. dozens. For sample ontologies (e.g., AIP Now), delete ontology entities via MCP (they go fast), then point the user at the Marketplace block uninstall for the remaining datasets, Workshop modules, notepads, pipelines, and media sets.
### Verify on the Dataset before Binding to Ontology
Hand-rolled primary keys can collide. Always run this before declaring data ready for an object type:
```sql
SELECT
COUNT(*),
COUNT(DISTINCT pk_column),
COUNT(*) - COUNT(DISTINCT pk_column) AS collisions,
SUM(CASE WHEN pk_column IS NULL THEN 1 ELSE 0 END) AS nulls
FROM `branch`.`dataset_rid`
```
One MCP call (`run_sql_query_on_foundry_dataset`), five seconds. Skip it and you'll waste a UI cycle when the Ontology Manager rejects the type.
### CI Errors Are Cheap Iteration
`Date` vs `Timestamp` mismatch, missing imports, type errors: caught in ~70 seconds of CI runtime. Push, see error, fix one line, push again. Foundry error messages are specific enough to act on directly (file, line, type expected vs. provided). Don't try to be perfect on the first push.
### Use OMCP to Seed Data and Test Actions
OMCP works during development, not just for external consumers. If you configure OMCP in Developer Console and expose your Actions as MCP tools, Claude Code can execute them in the same session where it's building the ontology via Palantir MCP. One MCP creates the object type. The other populates it.
OMCP is GA as of June 2026, with scoped-permission auth since July. It still requires a Developer Console application with the right object types and Actions exposed before it's useful. Once configured, use it for ontology data writes instead of the Platform SDK.
---
## Capability Reference (August 2026)
The Claude Code harness is: Palantir MCP + OMCP + Platform SDK + pltr-cli + @osdk/cli + @osdk/maker + Foundry CLI (SuperRepo) + bash + git + web search + CLAUDE.md + custom skills + sub-agents with inherited context + local filesystem + multi-MCP composition (Slack, Google Drive, etc.).
AI FDE is: ~80–100 platform-internal tools organized into modes and skills, running inside Foundry's browser, with no external tool access.
For rows where both columns show a tool, prefer whichever environment you're already working in. Switching to AI FDE for something MCP can handle adds context-switching overhead. For the Palantir MCP vs. OMCP distinction, see the comparison table in Ontology Data above.
### Summary
Rows are routes, not goals. When two rows reach the same goal (OSDK React vs. Workshop for frontends, code transforms vs. Pipeline Builder for pipelines), a blank Claude cell means that route needs another tool, not that Claude can't reach the goal.
|Category|Claude Code|AI FDE|Manual UI|
|---|---|---|---|
|Planning and research|✅|||
|Ontology structure (simple)|✅|✅||
|Ontology structure (complex logic)|✅|||
|Ontology structure (reproducible)|✅ (SuperRepo / Ontology-as-code)|||
|Data operations (read/write objects)|✅|✅ (executeAction)||
|Python/TS transforms|✅|✅||
|Pipeline Builder (visual path to pipelines)||✅||
|Data Connection||✅||
|Schedules|✅ (SDK)|✅ (native tools)||
|Functions (write + publish)|✅|✅ (write only, no git tag publish)||
|Logic functions (no-code)||✅||
|AIP Evals||✅||
|ML / Model Studio||✅||
|Frontend app, code path (OSDK React; SuperRepo or @osdk/cli)|✅|||
|Frontend app, quick prototype in-platform||✅||
|Frontend app, deployment|✅ (SuperRepo bundle or @osdk/cli site:deploy)|||
|Frontend app, Workshop/Slate path|||✅|
|Workshop/Slate export|||✅|
|Permissions audit||✅||
|Create function repos||✅||
|External function config||✅||
|LM/embedding integration in functions||✅||
|Notepad||⚠️ (unreliable)||
|Marketplace uninstall|||✅|
|Function-backed columns|||✅|
### Ontology Structure
|I want to...|Claude Code|AI FDE|Manual UI|
|---|---|---|---|
|Create / update object type|MCP `create_or_update_foundry_object_type`, or `@osdk/maker`|ontology mode|—|
|Add edit-only property|MCP same tool, `{ "type": "editOnly" }` mapping|ontology mode|—|
|Create link type|MCP `create_or_update_foundry_link_type`, or `@osdk/maker`|ontology mode|—|
|Create / edit interface|`@osdk/maker` `defineInterface` (incl. SuperRepo); MCP support unconfirmed|ontology mode (includeInterfaces)|Ontology Manager|
|Create action type (basic shell)|MCP `create_or_update_foundry_action_type`|ontology mode|—|
|Create action type with rules / side effects|❌ (MCP creates shells only)|ontology mode (claims "parameters, rules, and side effects", depth untested on enrollment)|Action rule editor|
|Add computed logic to action (now, snapshots, conditionals)|`@OntologyEditFunction` in function repo|❌ (can't produce code artifacts)|Action rule editor (Override builder)|
|Bind function-backed action rule|❌|❌|One click: Rules → Function → pick|
|Delete ontology entity|MCP `delete_foundry_*_type` (actions first, then links, then objects)|ontology mode (allowDeletion)|Ontology Manager|
|Search ontology|MCP `search_foundry_ontology`, `view_foundry_object_type`|ontology / exploration mode|—|
|Preview ontology + actions locally|SuperRepo embedded preview|❌|—|
|Set property-level enum validation|String-literal type in function signature|❌|Ontology Manager|
|Configure writeback dataset|❌ (often unnecessary on OSv2)|❌|Object type → Datasources|
|Wire function-backed column|❌|❌|Workshop Object Table widget|
### Ontology Data
|I want to...|Claude Code|AI FDE|Manual UI|
|---|---|---|---|
|Read / query objects|OMCP or Platform SDK|exploration mode, executeAction skill|—|
|Write objects / execute actions|OMCP via Actions, or Platform SDK|executeAction skill|—|
### Branching & Proposals
|I want to...|Claude Code|AI FDE|Manual UI|
|---|---|---|---|
|Create branch (global or code repo)|MCP `create_global_branch`; git for code branches|ontology / data integration mode (global branching); `create_branch` (code)|—|
|Create proposal / PR|MCP `create_global_proposal`, `create_code_repository_pull_request`|`create_or_update_pull_request`; ontology mode creates proposals automatically|—|
|Approve proposal|❌ (intentional human gate)|❌ (intentional human gate)|Proposal view → Approve|
|Merge PR|❌ (intentional human gate)|❌ (intentional human gate)|PR page → Squash and merge|
### Code Repositories
|I want to...|Claude Code|AI FDE|Manual UI|
|---|---|---|---|
|Clone repo locally|MCP `clone_code_repository_locally`|❌ (edits in-platform only)|—|
|Create new function repo|❌|functions mode|Code repo UI|
|Edit code files|Local editor + git after clone|Code Workspaces or authoring tools|—|
|Read PR / CI status|MCP `get_code_repository_pull_request`|`load_pull_request`|—|
|Get file or directory from repo branch|Local filesystem after clone|`get_file_or_directory`|—|
### Functions
|I want to...|Claude Code|AI FDE|Manual UI|
|---|---|---|---|
|Write TypeScript / Python functions|Local editing + git + CI feedback loop|functions mode (Code Workspaces or authoring)|—|
|Write Logic functions (no-code)|❌|functions mode (logic)|AIP Logic UI|
|Publish functions|`bash: git tag -a <ver> && git push origin <ver>`|Unclear mechanism|Code repo → Tags|
|Search functions|MCP `search_foundry_functions`|functions / exploration mode|—|
|Preview code transform|MCP `preview_transform`|❌ (has Pipeline Builder preview, not transform preview)|Code repo UI|
|Run AIP Evals|❌|functions mode (evals): author, run, diagnose, fix, rerun|AIP Evals UI|
|Configure external API calls in functions|❌|functions mode (externalFunctions)|Functions UI|
|Use LLMs / embeddings in functions|❌|functions mode (useLanguageModels)|Functions UI|
### Data Integration & Pipelines
|I want to...|Claude Code|AI FDE|Manual UI|
|---|---|---|---|
|Write Python transforms|Local + git + foundry-dev-tools for local testing|data integration mode (Code Workspaces or authoring)|—|
|Create / edit Pipeline Builder|❌|data integration / ML mode: `create_pipeline_builder`, `edit_pipeline_builder`|Pipeline Builder UI|
|Preview Pipeline Builder node|❌|`preview_pipeline_builder_node`|Pipeline Builder UI|
|Deploy Pipeline Builder|❌|`deploy_pipeline_builder`|Pipeline Builder UI|
|Build datasets|MCP `build_datasets`|`build_datasets`|—|
|Check build status|MCP `get_build_status`, `search_dataset_builds`|`get_dataset_build_history`|—|
|Get transform logs (filtered)|❌|`get_transform_logs`|Build view|
|Run SQL on dataset|MCP `run_sql_query_on_foundry_dataset` (branch-aware)|`dataset_sql_query`|Contour|
|Get resource lineage (1-hop)|❌|`get_resource_lineage`; Workflow Lineage graphs (July 2026)|Lineage view|
|Update / delete existing datasets|Platform SDK|❌|Dataset UI|
|Import trained model to Pipeline Builder|❌|`import_trained_model_to_pipeline_builder`|Pipeline Builder UI|
### Data Connection, Schedules & Syncs
|I want to...|Claude Code|AI FDE|Manual UI|
|---|---|---|---|
|Configure Data Connection (sources, syncs, egress)|❌ (workaround: write Python transforms that pull from external systems directly)|data connection mode: create/edit source, egress policies|Data Connection app|
|Debug Data Connection connectivity|❌|data connection mode: debug tools|Data Connection app|
|Create / manage build schedules|Platform SDK|data integration mode (schedule tools): create, update, pause, unpause, run, inspect|Schedules pane|
|Create / manage time series syncs|❌|data integration mode (timeSeriesData)|Time series UI|
|Manage Cipher channels|❌|data integration mode (cipher) / governance mode|Cipher UI|
### Application Building
|I want to...|Claude Code|AI FDE|Manual UI|
|---|---|---|---|
|Build OSDK React app (local dev)|SuperRepo (auto-OSDK), or `@osdk/cli` generate + local dev + git|❌ (builds in-platform only)|—|
|Scaffold OSDK React app / widget set in-platform|❌|OSDK React mode|Developer Console|
|Generate / regenerate OSDK package|MCP `generate_new_ontology_sdk_version`, `@osdk/cli`, or SuperRepo (auto, local)|❌|Developer Console|
|Deploy frontend to Foundry subdomain|`@osdk/cli site:deploy`, or SuperRepo Marketplace deploy|❌|Developer Console|
|Build Workshop modules|❌|❌|Workshop UI|
|Build Slate apps|❌|❌|Slate UI|
|Export Workshop / Slate app|❌|❌|File → Export (JSON)|
### Machine Learning
|I want to...|Claude Code|AI FDE|Manual UI|
|---|---|---|---|
|Create / configure Model Studio|❌|ML mode: `create_model_studio`, `configure_and_launch_model_studio`|Model Studio UI|
|Launch training run|❌|ML mode: `configure_and_launch_model_studio`|Model Studio UI|
|Deploy model (live inference)|❌|ML mode: `create_or_update_model_function`|Model deployment UI|
|Get model deployment logs|❌|ML mode: `get_model_deployment_logs`|Deployment UI|
|Inspect model versions / experiments|❌|ML mode: `list_model_versions`, `get_experiment_artifact_table`, `get_experiment_series`|Model UI|
### Operations & Governance
|I want to...|Claude Code|AI FDE|Manual UI|
|---|---|---|---|
|Create folder / move resources|❌|filesystem skill: `create_filesystem_folder`, `move_filesystem_resources`|Right-click UI|
|Delete folder / dataset / module|❌|❌|Right-click → Delete|
|Edit resource documentation (name, description)|❌|`edit_resource_documentation`|Resource page|
|Import resource across projects|❌|`add_missing_project_imports`|Project settings|
|Audit permissions (with what-if simulation)|❌|viewPermissions skill: `check_principal_access`, `get_access_requirements`|Permissions UI|
|Read / write Notepad|❌|notepad skill (⚠️ unreliable; see AI FDE Known Limitations)|Open in browser|
|Create / edit solution design diagrams|❌|solutionDesign skill|Solution Designer UI|
|Search datasets / get metadata|MCP search tools, SQL|`search_datasets`, `get_dataset_metadata`|—|
|Uninstall Marketplace block|❌|❌|Marketplace → Installed → Uninstall|
### Research & Documentation
|I want to...|Claude Code|AI FDE|Manual UI|
|---|---|---|---|
|Search Foundry platform docs (curated bundles)|MCP `search_foundry_documentation`, `get_documentation_summaries`|`documentation_search`, `load_documentation_bundles` (curated bundles: `ontology-action-types`, `functions-ontology-edits-tsv1/v2`, etc.)|docs.palantir.com|
|Search web (community, GitHub, third-party)|web search + web_fetch|❌|Browser|
---
## Iteration Principles
**Verify after every batch.** Don't assume an MCP call succeeded just because it returned. Use `view_foundry_object_type`, `search_foundry_ontology`, SQL queries, and build status to confirm what landed.
**Don't assume UI familiarity.** If you haven't actually used the UI, don't describe UI steps. Either find a code path or quote authoritative docs verbatim. "Click the Parameters tab" is useless if the user has never opened the action editor.
**Load docs before guessing platform semantics.** `get_documentation_summaries` returns authoritative Foundry doc bundles: `ontology-object-types`, `ontology-action-types`, `function-backed-columns`, `functions-ontology-edits-tsv1/v2`, and more. If you're unsure what `Timestamp` looks like in TSv1, or whether function-backed columns live in Workshop or Ontology Manager, look it up. Getting this wrong wastes a CI cycle or sends the user hunting through the wrong UI.
**Pushback on UI steps is a signal.** When the user pushes back on a UI-heavy plan, re-check for code paths. Don't explain the UI in more detail. They want less surface area, not more handholding.
**Reuse the same patterns.** Once "branch → changes → propose → approve" works for creating an object type, it works for deleting one too. Once "feature branch → PR → squash-merge → tag → publish" works for one function change, it works for the next.
**State exactly what you did and exactly what's next.** Each turn should end with "here's the state, here's the one or two clicks you need to do next, ping me when done." Not "let me know when you've done some unspecified amount of work."