How do I use O2C Deployment Workbench MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@O2C Deployment Workbench MCP Server Can you investigate payment SAP-P001-09 and explain the exception?" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

de en es ko ru zh

O2C Deployment Workbench MCP Server

by RitwijParmar

Overview Schema Source Related Servers Discussions Admin

Python

Hybrid

O2C Deployment Workbench

A complete, clearly synthetic customer implementation for ERP receivables: source onboarding, canonical data, cash application, deductions, collections, controls, KPI benchmarking, MCP access, multi-agent exception review, observability, UAT, cutover, and hypercare.

All SAP S/4HANA-style, Oracle Fusion-style, and NetSuite-style files in this repository are generated simulations. They are not genuine exports or live integrations. KPI movement is a controlled implementation benchmark on synthetic data, not customer impact.

Why this is an implementation project

The workbench starts with customer configuration and three incompatible source layouts, not a clean analytics table. It applies validation gates, preserves payment residuals, routes exceptions, prioritizes collections, shows unmet targets, and produces the artifacts a deployment team would use from discovery through go-live.

The architecture deliberately keeps financial matching deterministic and auditable. Agents handle judgment-heavy work: exception investigation, data-quality diagnosis, collection planning, and go-live monitoring. They cannot post to an ERP, issue a refund, write off debt, or alter master data.

flowchart LR
    A["Three simulated ERP export sets"] --> B["Configuration-driven adapters"]
    B --> C["Seven canonical receivables tables"]
    C --> D["Validation control gate"]
    D --> E["Deterministic cash matching"]
    E --> F["Exception and collections queues"]
    F --> G["MCP evidence tools"]
    G --> H["Supervisor agent"]
    H --> I["Cash Application Agent"]
    H --> J["Data Quality Agent"]
    H --> K["Collections Agent"]
    I --> L["Human approval gate"]
    J --> L
    K --> L
    E --> M["Controlled KPI benchmark"]
    M --> N["Go Live Monitor Agent"]
    O["OpenTelemetry traces"] -.-> B
    O -.-> E
    O -.-> H
    O -.-> N

Related MCP server: zipline-supply-chain

Run it

python -m venv .venv
source .venv/bin/activate
pip install -e ".[dev]"
o2c-workbench --project-root .
streamlit run app.py

The reproducible seed-42 run creates 1,908 canonical records, detects 18 intentional duplicate bank transactions as warnings, and leaves zero validation errors. Open the static dashboard or use the Streamlit app.

MCP server

The server uses the current MCP Python SDK and exposes structured tools, resources, and prompts. Local clients should use stdio; deployed clients can use Streamable HTTP.

o2c-mcp --transport stdio
o2c-mcp --transport streamable-http --port 8000

Tools: get_implementation_summary, investigate_payment, get_collection_priority, and run_controlled_benchmark. Resources: o2c://configuration, o2c://benchmark, and o2c://observability.

Multi-agent paths

The default path is offline and deterministic so a reviewer can reproduce handoffs and controls with no account or API key. It produces output/agent_decisions.csv, output/agent_control_summary.json, and OpenTelemetry spans.

An optional model-backed review uses the OpenAI Agents SDK with specialist handoffs and structured output:

pip install -e ".[ai]"
export OPENAI_API_KEY="..."
o2c-agent-review SAP-P001-09 --project-root .

The model path is intentionally not required for benchmark KPIs. It can recommend but cannot execute controlled financial actions.

Repository map

config/ — implementation configuration, mappings, tolerances, weights, routes, controls, KPI targets, agent limits.
data/raw/ — generated, visibly labeled simulated ERP exports.
data/canonical/ — normalized customers, invoices, payments, remittances, deductions, promises, and activities.
src/o2c_workbench/ — adapters, matching, collections, controls, agents, MCP, observability, KPI logic.
output/ — benchmark evidence, queues, traces, and dashboards.
docs/ — process designs, mapping, controls, RTM, 28 UAT cases, cutover, monitoring, training, and research basis.
deliverables/ — implementation workbook.
demo/ — five-minute narrated implementation walkthrough and script.

Seed-42 benchmark

KPI	Current state	Configured future state	Movement
Auto-match rate	10.0%	80.7%	+70.7 pp
Manual-review rate	90.3%	21.9%	-68.5 pp
Unapplied cash	$2,192,667	$550,209	-$1,642,459
DSO	115.9 days	51.6 days	-64.3 days
CEI	8.7%	75.7%	+67.0 pp
Past-due AR	69.5%	44.9%	-24.6 pp
Processing time	67.7 hours	13.0 hours	-54.7 hours

Four stretch targets remain unmet, so the monitor recommends a conditional go, not a victory lap. That is intentional implementation realism: proceed only with human approval controls and focused hypercare for unapplied cash and residual overpayments.

Verification

pytest -q

See research basis for the primary sources that informed the payment cases, MCP transport choice, agent handoffs, and telemetry conventions.

Available Tools

4 tools

get_collection_priorityA

Return the configured collection score evidence for one synthetic invoice.

ParametersJSON Schema

Name	Required	Description	Default
`invoice_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description indicates it returns read-only evidence, so side effects are not impliedasi. No annotations are present, but as a getter, the behavior is somewhat inferable. It does not specify errors, auth, or configuration dependencies.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single precise sentence with no filler. It conveys the operation, target, and scope efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is adequate for a simple getter and the output schema exists, but it lacks usage guidance, alternatives, and explanation of what 'configured collection score evidence' actually contains.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Even though the parameter schema is only a raw string, the description ties the operation to 'one synthetic invoice', which effectively identifies the invoice_id parameter and explains its scope.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the operation ('Return'), the resource ('configured collection score evidence'), and the scope ('for one synthetic invoice'). This distinguishes it from the sibling tools, which target implementation summaries and payment investigation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'for one synthetic invoice' gives a clear invocation context. However, it does not explicitly describe when to choose this tool over the sibling tools or mention any exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_implementation_summaryA

Return controlled benchmark KPIs, data-quality status, disclaimers, and agent readiness.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

There are no annotations, so the description carries the behavioral burden. It states that the tool returns a summary, implying a read-only operation, and lists the types of content returned. However, it does not disclose prerequisites (e.g., whether a benchmark must already exist), data freshness, or any side effects, which leaves some ambiguity.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, front-loaded sentence conveys the tool's purpose with no filler. Every phrase earns its place by naming a distinct output category.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that there are no parameters and an output schema exists, the description is largely complete. It lists the key output categories and indicates the tool's role as a summary provider. It could be slightly stronger by explicitly linking it to run_controlled_benchmark, but that is not essential for calling it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so schema coverage is trivially 100%. The description correctly avoids inventing parameter semantics and instead focuses on what the output contains, which is appropriate for a parameterless tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Return') and identifies a precise set of resources: controlled benchmark KPIs, data-quality status, disclaimers, and agent readiness. This clearly differentiates it from siblings like run_controlled_benchmark, which is the execution counterpart rather than the summary retrieval tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided about when to call this tool versus its siblings. There is no explicit statement such as 'use after running a controlled benchmark' or 'use instead of investigate_payment'; the intended usage must be inferred from the name and resource list.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

investigate_paymentC

Return matching evidence and exception routing for one synthetic payment.

ParametersJSON Schema

Name	Required	Description	Default
`payment_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of behavioral disclosure. It says the tool returns evidence and exception routing, but it does not disclose whether this is a read-only operation, whether it requires special permissions, or what side effects (if any) exist. The presence of an output schema mitigates some ambiguity, but the description alone is thin.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no wasted words. It is appropriately sized for a simple one-parameter tool, though it could have added a brief usage note without becoming verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has one parameter and an output schema, so the description does not need to explain return values. However, it lacks any context about when to use this tool, what 'exception routing' means, or how it relates to the sibling tools. For a tool with no annotations, this is a moderate gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It names the single parameter implicitly ('one synthetic payment' maps to payment_id) but does not explain the expected format, constraints, or how the parameter affects the result. With only one parameter, the gap is small, but the description adds minimal semantic value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Return') and resource ('matching evidence and exception routing for one synthetic payment'), which clearly identifies the tool's function. It does not explicitly distinguish it from siblings, but the resource is specific enough that an agent can infer its purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like get_implementation_summary or run_controlled_benchmark. The description implies it is for investigating a single synthetic payment, but it does not state exclusions or conditions that would route an agent to a sibling.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

run_controlled_benchmarkA

Regenerate synthetic source exports and controlled benchmark outputs; never connects to a genuine ERP.

ParametersJSON Schema

Name	Required	Description	Default
`seed`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.5/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses a key behavioral trait: it never connects to a genuine ERP, which is valuable context beyond the schema. However, with no annotations provided, the description carries the full burden and doesn't disclose other behaviors like whether it overwrites existing outputs, how long it takes, or what the output schema contains.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence, front-loaded with the action and resource, and the critical safety qualifier ('never connects to a genuine ERP') is included. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with one optional parameter and an output schema, the description is mostly adequate. However, it doesn't explain what 'controlled benchmark outputs' means in practice, what the output schema contains, or any side effects (e.g., overwriting files). The sibling tools suggest this is part of a larger workflow, but the description doesn't position it within that workflow.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It mentions 'seed' implicitly through 'regenerate' (deterministic regeneration), but doesn't explain the seed parameter's role or how it affects outputs. The single parameter is simple, so the gap is minor, but the description adds no explicit parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('regenerate') and resource ('synthetic source exports and controlled benchmark outputs'), and distinguishes itself from a genuine ERP connection. It is clear what the tool does, though it doesn't explicitly name sibling tools for differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies this tool is for synthetic/controlled benchmark scenarios and explicitly notes it never connects to a genuine ERP, which suggests when it should be used. However, it doesn't explicitly state when to use it versus alternatives like get_implementation_summary or investigate_payment.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesv1.0.0Sep 10, 2026
- First observedget_collection_priority
- First observedget_implementation_summary
- First observedinvestigate_payment
- First observedrun_controlled_benchmark

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.7/5.0

Scored 2026-09-10 08:31 across 4 tools

Disambiguation5/5

Each tool targets a clearly distinct function: summary/KPIs, payment investigation, collection priority, and benchmark regeneration. There is no meaningful overlap or ambiguity between them.

Naming Consistency4/5

All names use lowercase snake_case and follow a verb_object pattern, but the verb set is mixed (get, investigate, run). This is still predictable and readable, with only minor stylistic variance.

Tool Count5/5

Four tools is a tight, well-scoped surface for a synthetic O2C benchmark workbench. Each tool serves a distinct purpose without unnecessary bloat or missing core functionality.

Completeness4/5

The tool set covers the main workflows: viewing benchmark status, investigating a payment, checking collection priority, and regenerating outputs. A minor gap is the lack of explicit discovery tools for available synthetic payment or invoice identifiers, but this may be addressed through the summary.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Duvo MCP B
io.github.duvoai
Governed retail, FMCG, and CPG operational tools: runs, cases, approvals, audit-ready execution.
E-commerce & Retail ERP Systems
3802
AP Control Labs Finance Controls A
io.github.juodoc
Read-only finance and operations controls for AI agents with evidence and safe next actions.
Finance ERP Systems
1
diezx
ai.diezx
Business Observability: process inventory, AP risk, sales temperature, savings. diezX customers only
Finance
1
Algenta MCP Server B
io.github.thyn-ai
Governed data discovery, exact queries, decisions, simulations, and runtime utilities over MCP.
Data Platforms Search RAG Systems
1402

Related MCP Servers

dumate-supply-chain-mock-api
ERP Systems CRM
pipiwolve
F
license
Not graded
quality
B
maintenance
MCP server that provides mock APIs and deterministic seed data for ERP/OMS, WMS, and CRM systems, enabling supply chain data exploration and integration testing.
Updated a month ago (2026-08-12 09:22 UTC)
-
zipline-supply-chain
ERP Systems Research & Data
maevelynz
F
license
Not graded
quality
C
maintenance
Enables natural-language supply-chain analysis over synthetic datasets through governed SQL/Python tools, providing supplier scorecards, forecast accuracy, risk detection, landed-cost comparisons, capacity planning, and quality trend insights without the LLM performing quantitative calculations.
Updated 15 days ago (2026-09-01 10:00 UTC)
-
Payables MCP
ERP Systems Finance
zeybekci-lab
F
license
A
quality
B
maintenance
Enables an AI agent to handle accounts payable tasks against a mock ERP, including reading and writing bills and vendors, checking duplicates, matching invoices, recommending approvals, and queuing payment releases, with configurable profiles that limit available tools.
Updated 12 days ago (2026-09-04 15:28 UTC)
11
-
finance-engines-mcp
Finance
Cubiczan
F
license
A
quality
C
maintenance
Provides AI agents with deterministic, offline finance tools for commodity margin analysis, loan covenant compliance, invoice auditing, AP exception classification, and five-day close readiness.
Updated 10 days ago (2026-09-06 23:43 UTC)
14
17 npm
-