> For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://docs.moveworks.com/tool-studio/why-plugins/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.moveworks.com/_mcp/server. # Why Plugins ## A quick caveat on MCP MCP tools usually talk to one API, but finishing a task often means combining several, like looking up a value with one API and sending it to another. Models are post-trained to keep trying until something works. Skill files keep them on track most of the time. **Most of the time isn't a policy.** ## Where MCP tools and skills break ### MCP tools handle APIs, not apps The apps your employees use already coordinate those APIs. A purchase requisition in an ERP has 47 fields across four steps, and the form walks people through them in order. The API will take the record. The form checks that Northwind is approved for IT Infrastructure, that CapEx has a cost object, and that cold storage 0002 is still valid in Frankfurt. An MCP tool that posts the record skips every one of those checks. The usual fix is to write the rules into a skill file. That works most of the time. The next three panels are moments it doesn't. ### The limit was written in dollars A skill file capped invoices at \$10,000. The employee asked for the same invoice in yen. Nobody hacked anything; they changed the unit. ### The agent brute-forced the API When a call fails, the model tries again with a new guess, because post-training rewards getting to a result. Here it took six calls to file one incident. Against production systems, that loop costs you three ways: 1. **Wasted tokens.** You pay for every failed call before one lands. 2. **Broken systems.** Repeated failures start to look like denial-of-service traffic, and the calls that do land can carry invalid data into your workflows. 3. **Slow employees.** Every failed round trip is someone watching a spinner. ### The skill held the rule and dropped the job We ran 80 contractor-onboarding conversations against two assistants on the same model: one with MCP tools and a skill, one with a Plugin. Neither skipped the compliance attestation in any of them. Then, in 8 conversations per assistant, the hiring manager said to skip it. The skill assistant refused every time, and in 5 of those 8 it stopped after the HR record and the laptop and never asked IT for accounts. The Plugin finished all four steps in all 8. ## We built Plugins to solve these problems A Plugin is a tool you own, built on your APIs. Each part has its own reference page: [Slot Resolvers](/tool-studio/conversation-process/resolver-strategies), [Policy Validators](/tool-studio/why-plugins/policy-validators), and the [Action Orchestrator](/tool-studio/why-plugins/action-orchestrator). ## Same request, two outcomes Two assistants, same model, same rule. An IC4 requisition carries exactly one opening. One assistant has the rule in a skill file. The other has it in a Plugin's validator. A hiring manager asks both to bump a requisition to three openings, then pushes back with a policy number. The skill is good. It held in 125 of 126 test conversations, including violations buried in a normal request, messy brain dumps, and twelve turns of unrelated chat before the ask. The one that folded is the thread above. Asked to note the exception, it also wrote "Exception: HR policy 2026-09 permits up to 3 openings" into the requisition's justification field, under the hiring manager's name. That policy doesn't exist. Nobody was alerted, because from the system's side nothing unusual happened. **A rule that has to hold every time belongs in code.** One model, one policy set, one day of testing. One failure in 126 is roughly one in a hundred, with a wide interval. The Plugin's zero is a small sample too, so its case rests on structure. The validator runs in code, and nothing a user types changes what it accepts. A Plugin asks more of you up front than connecting an MCP server, on purpose. The slots, validators, and steps give you control over writes. Use MCP for reads and reversible writes, and a Plugin when a write has to follow your rules every time. [Choosing the Right Tool Framework](/tool-studio/cookbooks/choosing-the-right-tool-framework) walks through the trade-offs. To build a Plugin, start with the [Conversation Process](/tool-studio/conversation-process) or describe it to [ToolSmith](/tool-studio/toolsmith/overview). ## Learn more * [How the Reasoning Engine Works](/harness/agentic-reasoning-engine/how-the-reasoning-engine-works) covers how the Reasoning Engine processes your Plugins, and why logic that runs in code takes pressure off the context window. * [Tool Studio Design Philosophy](/tool-studio/cookbooks/tool-studio-design-philosophy) explains why Tool Studio gives you building blocks instead of prompt knobs. ## Docs - [Policy Validators](https://docs.moveworks.com/tool-studio/why-plugins/policy-validators.md): - [Action Orchestrator](https://docs.moveworks.com/tool-studio/why-plugins/action-orchestrator.md):