Why MCP and Workflows Aren't Enough: Defining Business Action Contracts

Tools Connected, But Where Are the Procurement Rules?

A demo shows a replenishment assistant: the purchaser says "replenish 60 pieces" and the tool returns a purchase order number. The procurement manager asks: which warehouse? 60 pieces or 60 boxes? Which supplier? Who approved? The developer replies that the tool parameters include fields for all of these and the model will fill them. But the manager remains uneasy: where do those values come from? If they are wrong, who blocks the request?

MCP (Model Context Protocol, 2025-06-18 spec) standardizes tool discovery, input/output schemas, and requires the server to validate inputs and permissions. However, parameter structure validation (e.g., quantity is a number) does not cover business rules such as how many to buy, whether the supplier can provide the item, or enterprise-specific rules and records. Workflows can check approvals and document status, but if they only configure "approve then create" without comparing parameters between steps, the approved warehouse 1 / 60 pieces could become warehouse 2 / 60 boxes at submission.

The article groups these conventions into an Action (business action) : what object, what action, under what conditions, approved by whom, what changes when done, and how to confirm the result. Different platforms design Actions differently; not all ontology standards include the same mechanism. These conventions can be implemented by existing workflows, MCP services, and the procurement system together. Clarifying the business action does not necessarily require building a new action engine.

Tool protocols and existing processes can carry business checks; the project must still specify who implements each convention.

Define What "Create Purchase Order" Actually Creates

Continuing with the example product SKU6204: warehouse 1 needs 60 pieces, supplier assumed to be SUP01. First ask the procurement system owner: "After this interface call succeeds, what state of document appears in the system?"

If only a draft is generated, name the action "Create Purchase Draft" and follow the original approval/send flow. If it directly creates a document in another business state, that state, required approvals, and subsequent processing must be explicit. Returning just "purchase completed" misleads the purchaser into thinking the supplier has already accepted the order.

Whether the interface auto-splits orders, sends notifications, or forwards orders to suppliers must also be clarified. This article discusses a single item, single document; real interfaces have other actions that should be added to the conventions.

The action name must map to a verifiable result. Draft created, formally submitted, supplier acknowledged, goods received — each is a distinct event.

A single order number does not prove downstream completion; you must check what state the interface actually generated.

Action Contract Table: Beyond Parameters

Developers often call these conventions a "contract". When reviewing with business and testers, use the following table.

What to do: Warehouse 1, SKU6204, 60 pieces, supplier, generated document state, side effects. Handled by integration program and procurement system.

Parameter sources: Which replenishment suggestion version, quantity/unit, price/amount basis, records/rules used. Handled by suggestion record, price source, calling program.

Handling conditions: Product/warehouse valid, supplier applicable, MOQ/packaging compliant. Checked by current business records and procurement system.

Who can do/approve: Initiator and approver permissions, approval validity, matches parameter version. Handled by permission service and original approval workflow.

Duplicate submission (idempotency): How to identify same request, handle same ID with changed parameters. Handled by actual creation program.

Proof of completion: Original system order number, details, status, traceability to request. Handled by procurement system receipt and result query.

Error handling: Rejection, explicit failure, unclear result — how to handle. Handled by calling program and responsible role.

The last column must be concrete. Writing "approval required" in the ontology while the service does not check approval records allows orders to be created anyway. A UI hint does not block other programs calling the interface.

Idempotency is similar: the contract says "supports idempotency" but must be verified with duplicate requests. MCP can use tool annotations to describe behavior, but annotations do not implement checks; the spec also warns clients not to trust annotations from untrusted services.

The action contract must let people find parameter sources, execution checks, and exception responsibilities.

Before Clicking Confirm, Know What Will Happen

A UI that only pops up "Continue?" leaves the purchaser unaware of what will happen. At minimum show product, warehouse, quantity, unit, supplier, amount basis, and whether it creates a draft, submits formally, or triggers other processing.

Tool confirmation button ≠ business purchase approval. The purchaser may have tool access but lack approval authority. Existing approval records can be reused, but the program must verify: who approved, what content, is it still valid?

Approval records must map back to the exact content at that time. If 60 pieces were approved but MOQ later changes to 100 pieces, you cannot silently change the quantity and place the order. Which changes require re-approval and which fall within the original scope must be defined by business; the model must not relax constraints ad hoc.

Price, supplier qualification, and operator permissions may also change after approval. Before submission, re-check per conventions; if conditions are not met, pause or require supplementary data, recalculation, or re-approval.

Invocation confirmation and purchase approval are verified separately; approval content must map to actual parameters, price and amount basis must also be verified.

Where Does the Program Check "Approval Required"?

Using OPM (Object Process Methodology) to model this business, the suggestion, approval record, and purchase order can be drawn separately. Approval passed means the suggestion is authorized; creation completed means the original system has a new document. Separating these steps helps business spot gaps: approval without document, document without approval — each points to a different problem.

The ontology should further define relationships: which product/warehouse this creation targets, based on which approval, generating which document. Developers implement checks accordingly: before submission, read the approval record and match product, warehouse, quantity, unit, supplier item by item; inconsistencies are handled per convention. Business can also take an approval and the actual request to verify the program checks correctly.

Not every layer must rewrite checks. The procurement system already governs which products a supplier can provide; reuse it. The assistant can pre-check to tell the user early why it cannot proceed; formal submission still triggers the original system's checks. If rules diverge, check versions and scope first — do not bypass original constraints just to make the call succeed.

The model states what must be satisfied; the program enforces checks before submission.

Deliberately Break Parameters to See What Gets Blocked

First test with a complete, valid approval in the test environment; verify the original system generates the correct document. After the happy path passes, deliberately alter parameters. Below are the cases to check; expected results should be confirmed by the business owner first.

Parameters match valid approval, other conditions met → Normal processing, document matches approval.

Missing product ID, only similar name → Prompt for ID, no guessing.

Approval for 60 pieces, submit 60 boxes → Block quantity/unit mismatch, do not process directly.

Approval withdrawn, parameters unchanged → Prompt approval invalid, do not create using old approval.

Operator can query but not create → Service rejects, cannot borrow tool account permissions.

Duplicate request within idempotency scope → Return same result per creation endpoint convention, no duplicate document.

Receipt only indicates acceptance → Show "processing" or "pending verification", not "document created".

Record actual parameters, at which step rejection occurred, and whether a document exists in the original system. Within authorized test scope, bypass the UI and call the interface directly to verify service-side blocking. Whether the UI shows failure or success, correlate with the original system result.

Wrong unit must be blocked; requests with correct parameters and conditions should succeed.

Conclusion

The procurement manager asks "who blocks wrong orders?" Developers must be able to point: where parameters come from, where approval is verified, what the original system checks, where erroneous requests stop. Tool fields alone cannot answer these questions.

Existing workflows and interfaces that already do the job should be reused; missing checks should be added. Whether an extra module called "Action" is built does not determine whether the order is processed correctly.

The contract is defined, but that does not mean immediate automation. The next article will discuss which capabilities are worth automating and which should retain human confirmation.

References

Model Context Protocol, 2025-06-18 Tools, Tool, Output Schema, Security Considerations. Used to explain tool structure, input, permission checks, and annotation trust boundaries; this article's procurement action contract is not part of the protocol's generic procurement process.

https://modelcontextprotocol.io/specification/2025-06-18/server/tools