# Palantir Foundry & AIP Code-First Workflow The goal is to minimize Foundry/AIP browser UI by using Claude Code and CLI with full permissions to maintain a pure codebase representation of ontology, pipelines, and applications. 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 (`@osdk/cli`, `@osdk/maker`, community tools) live in npm and GitHub. 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. Use this guide to determine the right tool path for each operation. As of May 2026, structural ontology changes (object types, links, actions) require either Palantir MCP with human proposal approval or the in-development `@osdk/maker` beta. Data manipulation is automatable through Ontology MCP (OMCP, beta) or the Platform SDK; app deployment through `@osdk/cli`. 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. --- ## 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 workflows end to end. **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. **The one human click that never goes away** is proposal/PR approval. --- ## Decision Framework The right tool depends on what you're doing, not just whether MCP has a tool for it. ### 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. ### 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 `@osdk/maker` 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 because every change requires a Marketplace reinstall cycle. Rule of thumb: MCP + code for iteration on a live ontology. `@osdk/maker` for greenfield setup or when reproducibility across environments matters more than speed. ### 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. 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. ```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. Known failure modes: interfaces that don't map during Marketplace installation, INVALID_ARGUMENT on shared property definitions, API name validation failures from length constraints, no virtual table support as backing datasources. Validation errors surface at the Marketplace install step, not during code review. If an `@osdk/maker` artifact fails on install, check API name length and shared property definitions first. Install: `npm install @osdk/maker` ### Path C: DevCon 5 Developer CLI (announced May 2026, not yet public) At DevCon 5, Palantir announced a new CLI for creating pro-code monorepos covering data pipelines, Ontology primitives, and application artifacts in a single repository. No public documentation, npm package, or GitHub repo exists yet. Ask your Palantir rep about access. --- ## 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|Beta (may not be on your enrollment)| ### [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). ### [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. 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 — 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 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. ### 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. Limitation: OMCP is beta, may not be on your enrollment, and 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 (May 2026) The Claude Code harness is: Palantir MCP + OMCP + Platform SDK + pltr-cli + @osdk/cli + @osdk/maker + 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 |Category|Claude Code|AI FDE|Manual UI| |---|---|---|---| |Planning and research|✅||| |Ontology structure (simple)|✅|✅|| |Ontology structure (complex logic)|✅||| |Ontology structure (reproducible)|✅||| |Data operations (read/write objects)|✅|✅ (executeAction)|| |Python/TS transforms|✅|✅|| |Pipeline Builder||✅|| |Data Connection||✅|| |Schedules|✅ (SDK)|✅ (native tools)|| |Functions (write + publish)|✅|✅ (write only, no git tag publish)|| |Logic functions (no-code)||✅|| |AIP Evals||✅|| |ML / Model Studio||✅|| |App building (OSDK React, local)|✅||| |App building (quick prototype)||✅|| |App deployment|✅||| |Permissions audit||✅|| |Create function repos||✅|| |External function config||✅|| |LM/embedding integration in functions||✅|| |Notepad||⚠️ (unreliable)|| |Workshop/Slate building|||✅| |Workshop/Slate export|||✅| |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`; 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|—| |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 (beta) or Platform SDK|exploration mode, executeAction skill|—| |Write objects / execute actions|OMCP via Actions (beta), 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`|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)|`@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`, or `@osdk/cli`|❌|Developer Console| |Deploy frontend to Foundry subdomain|`@osdk/cli site: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."