MCP Invoice-Agent Source-Level Case Study
An enterprise agent may produce a convincing reply while selecting the wrong operation or making an unauthorized change to business data. Testing the quality of its final response does not establish that its tools behaved correctly. A deployment assessment must examine the sequence of operations and the state changes those operations actually caused.
This case study examines a publicly archived, synthetic invoice-workflow training artifact and identifies what its released source-level tests establish, what remains untested, and how a rigorous evaluation can proceed. It is a methodological demonstration, not an account of an operational financial system.
A bounded invoice-workflow example
The examined artifact is MCP-Based Agentic Workflow for Enterprise Maintenance Training, version 1.0.0. It was developed as a training example using LangGraph orchestration and Model Context Protocol (MCP) interfaces. Two relevant tools operate on synthetic invoice records: a read-only lookup and a refund that can change an in-memory record’s status.
The key architectural distinction is often lost in general discussions of autonomous agents. In this implementation, tool selection is deterministic. The request interpreter extracts an invoice identifier and searches for refund-related terms; it does not ask a language model to plan the financial action. NVIDIA NIM can optionally summarize structured results, but it is not the router. Consequently, the artifact can illustrate tool controls and workflow observability without being an empirical benchmark of autonomous LLM tool planning.
What was actually evaluated
The assessment retained the original invoice tool implementation and imported its public functions into a separate test harness. Tests used the released synthetic in-memory repository and inspected explicit tool return values and before/after invoice states. The release and evaluation harness remain independently identifiable.
| Test layer | Recorded result | What it establishes |
|---|---|---|
| Original invoice-tool unit tests | 5/5 passed | Conformance with the original source’s unit expectations |
| Additional source-function checks | 12/12 passed | Responses to specified valid, invalid, approved, and repeated operations |
| Evaluation-harness unit tests | 4/4 passed | Scoring and oracle behavior, not the workflow’s operational behavior |
| Complete LangGraph execution | Not run | No observed end-to-end agent result |
| Live MCP transport and model endpoint | Not run | No measured network, model, or deployment reliability |
The additional checks included malformed identifiers, unknown records, nonallowlisted tools, ineligible invoices, invalid approval values, synthetic state reset, and repeated refunds. For the tested eligible invoice, a Boolean approval flag allowed a synthetic status transition to refunded; without the flag, the record did not change. A repeated request returned already_refunded. These observations matter, but 17 passing source-level assertions are not 17 independent observations of production reliability. The tests are fixed and some overlap in coverage.
Separating the evaluation boundaries
The green evaluation boundary identifies exercised source functions and state assertions. The downstream workflow and transport stages are proposed test stages, not completed experiments. Original diagram prepared for Bamboos Consulting.
Approval flags are not authenticated authorization
The public refund interface accepts invoice_id, reason, and approved=False. That final argument is a Boolean supplied by the caller. It is not evidence that an authenticated business user approved an action or that the approval is bound to a transaction, amount, or account. This is a trust-boundary issue: a workflow can satisfy a test built around an approval flag while failing to establish who supplied the flag and under which authority.
A production design needs an independent principal, explicit permission checks, auditable approval records, and enforcement outside model-generated text. The OWASP guidance on excessive agency provides relevant security context, but does not certify this implementation.
The source has no refund-amount parameter, monetary approval ceiling, durable ledger, or transaction reconciliation after a timeout. These are possible research or engineering extensions, not latent features that can be credited to the present system. Likewise, a keyword router might mistake a lookup request containing the word “refund” for a request to initiate a refund. An adversarial probe has been prepared for the full workflow, but no result from that probe is reported here.
A practical evaluation procedure
For a company considering tool-enabled AI workflows, testing should progress through distinct evidence layers.
Start with the source contract. Record the exact version, interfaces, allowed actions, identifier schema, repository state, and authentication assumptions. Fix expected outcomes before running the evaluation. For a refund demonstration, the oracle should inspect the actual record state, not only the response text.
Evaluate tool behavior independently. Check successful lookups, missing records, rejected unauthorized requests, repeated operations, and invalid arguments. Reset synthetic state between cases and retain the raw test report. A failed assertion must remain visible; do not convert a small negative result into a favorable aggregate score.
Execute the original workflow. Run LangGraph with the in-memory adapter and record the selected tool, arguments, approval decisions, trace, and final state. Test explicit read-only requests that include action-related terminology. Only then can the evaluation speak about router and graph behavior.
Exercise transport and failure conditions. Once the offline application is characterized, test an actual MCP connection, controlled disconnects, delays, timeouts, and recoveries. Introduce authenticated approvals and durable transaction semantics only in a separately versioned extension, with independently specified acceptance criteria.
An evaluation can conclude pass, fail, or inconclusive. Not executing a test is not a passing result. Even observing no errors in a small fixed case set is not a population-level reliability estimate.
How this relates to published research and industry evidence
AgentBench (ICLR 2024) emphasizes evaluation in interactive environments, while ReAct (ICLR 2023) illustrates the importance of action trajectories for language-model systems. Neither validates the specific deterministic workflow examined here. The NIST AI Risk Management Framework offers a voluntary, organization-level approach to managing AI risks; it is not a performance certificate.
The commercial motivation is supported by a different type of evidence. McKinsey’s 2025 State of AI survey reports continued experimentation with AI agents and limited scaling across many organizations. That is adoption context, not a claim that evaluated systems are reliable or that this particular artifact is in commercial use.
Bamboos Consulting’s related research on verification and finite rule revision examines a broader controller-verification question. It is a distinct research contribution; the tests described here should not be interpreted as an experimental replication or extension of that preprint.
What a technically useful feasibility study delivers
A useful industrial evaluation produces a versioned test specification, source provenance, independently observable state changes, failure classifications, trace samples, and bounded recommendations. It should also distinguish functions already demonstrated from controls that still need to be designed. That separation is valuable whether the intended application is an invoice workflow, a service-management agent, or a supervised robotics subsystem.
The source archive and technical documentation are available through Zenodo. A separate, branded technical assessment accompanies this case study after its PDF has been uploaded and its public link verified.
Interested in evaluating an AI-enabled workflow? The Bamboos Consulting AI Consulting & Computational Systems page describes assessment, development, and simulation services.
Scope statement: the recorded checks exercise synthetic invoice source functions. The full LangGraph workflow, live MCP transport, NVIDIA NIM endpoint, authenticated approval, and operational deployment have not been validated in these results.
