# Workfront MCP and Claude: a field report from production > Source: > Published: 2026-07-29 17:56:46+00:00 *Originally published as a guide on thousandcuts.ai. The toolkit described is open source: Thousand-Cuts/wf-toolkit.* Three different things now answer to the name "Workfront AI," and conflating them costs evaluation teams real time. There's the AI Assistant inside Workfront's own interface. There's the **Workfront MCP server**, which Adobe shipped so an AI platform like Claude or ChatGPT can reach into your instance. And there's a third category almost nobody has seen in the wild: a skills toolkit that lives on the Claude side and carries its own tested knowledge of how Workfront actually behaves. We run that third thing in production, daily, across client tenants. This memo covers the second and third honestly — what the MCP server is, what it's genuinely good at, the exact line where it stops, and what a knowledge-carrying toolkit does differently. With timings, because claims without timings are marketing. The Workfront MCP server is Adobe's implementation of the Model Context Protocol: a connector that lets an AI platform — Claude, ChatGPT, Copilot, Gemini — search, create, and update objects in your Workfront instance through natural-language requests. It covers projects, tasks, issues, approvals, Planning records, and reporting queries, acting as the signed-in user under that user's existing permissions. That last clause matters more than the feature list. The MCP doesn't grant an AI new powers; it lends the AI *your* powers, and your admin decides how much. Two toggles govern the whole thing in System Preferences: read-only tools (on by default) and write tools (**off** by default). Two more facts from [Adobe's own documentation](https://experienceleague.adobe.com/en/docs/workfront/using/basics/workfront-mcp-server/workfront-mcp-server-overview) worth knowing before your evaluation meeting: Planning tools require the Planning package, and as of this writing the server is available only to customers hosted on AWS. Boards support is listed as coming soon. Credit where due — the MCP is good at the thing it was built for, which is conversational access to work data. "Summarize every project in the Spring portfolio and flag anything at risk" is a real capability, and it works the way [Adobe's announcement](https://business.adobe.com/blog/workfront-mcp-ai-powered-work-management) describes. So is "create a task under Website Redesign, assign it to me, due Friday." [Anthropic's Workfront connector](https://claude.com/connectors/adobe-workfront) runs on this server, and for a project manager who lives in status meetings, the summarize-and-flag loop alone justifies the setup. If your question is "can Claude read my Workfront instance and answer questions about it" — yes. Enable the read tools and you're most of the way there by lunch. Our production work runs through Workfront's API and interface surfaces every day, and the boundary of the MCP's coverage is easy to state because it's the boundary of generic object access. The following are simply not in its vocabulary: `TEXT MODE` — views, filters, groupings, valueexpressions. The reporting language admins actually fight with.`CALCULATED FIELDS` — authoring and debugging the calculation syntax on custom forms.`CUSTOM FORM STRUCTURE` — fields, sections, display logic, cross-form audits. The MCP can touch objects; it doesn't know form architecture.`BUSINESS RULES` — the block-on-save validation formulas under Setup.`FUSION` — scenarios, blueprints, error handling. The entire automation platform, absent.`REPORT DEFINITIONS` — querying data, yes; building or modifying the report objects themselves, no.`PERMISSIONS DIAGNOSTICS` — it obeys your access level; it cannot explain why a user can't see a project.And one structural limit that turns out to matter more than any single gap: **the MCP connects to one environment at a time.** One tenant, one connection. Keep that in mind for the next section, because the most important safety pattern we use is impossible under it. None of this is a flaw in the MCP, exactly. It's what "generic" means. An API bridge can only offer what the API labels; the knowledge of what to *do* with those labels — which syntax is real, which enum values the docs get wrong, which write orderings fail — has to live somewhere else. Our instrument is a Claude toolkit: twelve skills covering the list above (text mode, calculated fields, custom forms, business rules, Fusion and its testing harness, reports, bulk updates, permissions, platform assessment), backed by roughly `96` knowledge files of verified Workfront behavior. It's not a product you can download; it's the tooling this practice built for delivery work, and it's how the numbers below happened. "Instead" is also slightly unfair — nothing about it conflicts with the MCP, and an org that enables read tools gets a fine transport layer. The difference is what rides on top. A client — a regional U.S. bank — launched their intake form with zero required fields, deliberately: friction kills adoption, gather the requirements later. Months later, "later" arrived, and 100-plus of those 300-plus fields needed flipping to required. The interface route: find each field in the form builder, open it, check the box, save. Call it 15 seconds a field once you're warmed up. Across a hundred-odd fields that's half an hour of the same click pattern, with your error rate climbing the whole way — nobody's attention survives field eighty. The toolkit route: `30 seconds` . Total. One reviewed change against the API, every field accounted for. The reaction that number gets: *you let an AI write to a production form?* Right question. Here's the procedure that earns it. The toolkit first checks whether the tenant has a non-production environment available. If a preview or sandbox exists, the change runs there first, and a human looks at the result before production sees anything. If no sandbox exists, the toolkit performs a dry run against production — a full report of exactly what would change — and executes only on an explicit go-ahead. And every production write captures a previous-state file first, so if something looks wrong afterward, the exact prior configuration exists on disk to restore from. Staged environment, dry run, explicit approval, recorded rollback path. The AI never gets the chance to behave badly, because the process walks it past every opportunity. The 30 seconds in Exhibit A sits on top of all four rungs. The ladder in Exhibit B has a prerequisite the MCP can't meet: the tooling has to reach the sandbox *and* production in the same session. The toolkit connects to every environment we have credentials for — each client's production and preview tenants, with per-client credential isolation and none of the keys ever entering the conversation. The MCP's one-connection-at-a-time model forecloses the test-then-promote pattern entirely. For a solo admin on one tenant, maybe that's academic. For anyone responsible for changes that need rehearsal before production, it's the whole game. The toolkit exists because of an uncomfortable stretch of watching base Claude work on Workfront problems. Sometimes it got API interactions, text mode, and calculated fields right. It was wrong far too often to trust, and the failure mode was expensive: not a clean error but confident wheel-spinning, session after session. The fix wasn't less AI. Workfront's REST API is self-describing — metadata endpoints will enumerate every object type, every field, every enum value, every available action. So the toolkit's foundation came from pointing Claude at those endpoints and having it teach itself the entire API from the source instead of from training data. On top of that sits the part no metadata endpoint provides: findings verified against live tenants and written down with dates. One example of the genre — there's a class of form-update API call that fails with a validation error on the *entire* write if you include each row's composite ID, because Workfront then re-validates a field schema that isn't even readable through the API. The fix is to key rows a different way and omit the ID. No documentation says this anywhere. It cost an afternoon once, it's recorded with the request that proved it, and it will never cost an afternoon again. Multiply that by ninety-six files and you have the difference between an AI with API access and an AI with experience — borrowed from someone who did the debugging. Some of Workfront isn't reachable by API at all. Layout Templates, to name the one that comes up constantly, can only be created in the interface — no endpoint, no toolkit, no exception. Whatever an AI vendor's slide deck implies, a working Workfront practice still needs a human admin, and the honest description of all this tooling is that it deletes the half-hours, not the judgment. It's also not for every org. If connecting AI tooling to a production tenant is off the table for policy or compliance reasons, that's a legitimate answer, and the math above doesn't argue with it. **Is there an MCP server for Adobe Workfront?** Yes. Adobe provides an official Workfront MCP server that connects your instance to AI platforms including Claude, ChatGPT, Copilot, and Gemini. Admins control it with two toggles: read-only tools (default on) and write tools (default off). It's currently limited to AWS-hosted customers. **Can Claude connect to Adobe Workfront?** Yes, two ways: through Anthropic's Workfront connector (built on the MCP server) for conversational access to projects, tasks, and approvals — or through Claude-side skills that work with the Workfront API directly, which is how the work described in this memo runs. **Is it safe to let AI write to Workfront production?** Only with process around it. Ours: test in a sandbox environment when one exists, dry-run against production when one doesn't, execute on explicit human approval only, and capture the previous state of anything modified so it can be restored. An AI write without a staged path and a rollback record is a risk, not a workflow. **Does the Workfront MCP cover text mode or Fusion?** No. The MCP's tools cover object operations (projects, tasks, issues, approvals, Planning records) and data queries. Text-mode reporting syntax, calculated-field authoring, custom-form structure, business rules, and all of Workfront Fusion are outside its scope. If your team's version of the 300-field form is sitting on someone's list right now, [a 30-minute teardown](https://thousandcuts.ai/book) will find out what it costs you. And if you'd rather have a skill like these built for your own task — built live, in your workspace, yours afterward — that's [the Skill Session](https://thousandcuts.ai/skill-session).