# COO Operations Prover MCP > COO Operations Prover validates operational plans against five critical axes: capacity modeling, failure isolation, cost leverage, process discipline, and accountability mechanisms. Stop accepting 'best effort' SLAs or vague claims of 'scaling.' This MCP forces your AI client to prove a plan can survive real-world peak loads and component failures. ## Overview - **Category:** infrastructure - **Price:** Free - **Tags:** coo, operations, capacity, sla, error-budget, scalability, reliability ## Description Don't let an LLM write you a plan that sounds good but fails when it matters. This MCP acts like a wartime Chief Operating Officer, forcing the planning process to confront five major blind spots. You feed in your operational strategy—the proposed system design or business model—and the tool checks for fatal gaps. It makes sure you've modeled arrival rates vs. service rates, proving capacity has headroom instead of just promising 'auto-scaling.' Next, it requires specific details on bulkheads and blast radius limits to show where failure is contained. Then, it drills down into cost, demanding per-unit costs at three distinct scale points with a clear decrease mechanism. Finally, you prove process discipline by providing exception rates below 5% and automated accountability through error budgets and defined penalties. It's not just checking boxes; it’s making your plan execution-ready. You can find this MCP alongside thousands of others in the Vinkius catalog. ## Tools ### validate_coo_operations Runs a full operational readiness check, requiring the agent to model capacity, prove failure isolation, show cost leverage at three scale points, quantify process discipline, and enforce automated accountability. ## Prompt Examples **Prompt:** ``` We will scale our platform as needed using auto-scaling groups. We have economies of scale. Our processes handle exceptions on a case-by-case basis. Our SLA commits to best effort uptime. ``` **Response:** ``` CAPACITY_BLIND — Four fatal gaps. First: 'auto-scaling' is not capacity modeling — define arrival rate, service rate, and utilization threshold. Second: 'economies of scale' is a claim — show cost per unit at 3 data points. Third: 'case-by-case' is process chaos — quantify exception rate and provide runbooks. Fourth: 'best effort' is accountability theater — define error budget and automated penalties. ``` **Prompt:** ``` Peak arrival: 1,200 req/s. Service capacity: 1,800 req/s across 6 workers (300/s each). Utilization: 67%. Queue drain: 200ms p99. Headroom: 33%. Tenant isolation: database-per-tenant. Regional blast radius: max 8% per region (12 regions). Circuit breaker on payment: 5s timeout, 3 retries. Cost: $0.12/user at 10K, $0.04 at 100K, $0.008 at 1M (committed use + CDN 94% hit). SOP coverage: 94%. Exception rate: 3.2%. Top 3 categorized with runbooks, 15min resolution. SLA: 99.9%. Error budget: 43.8 min/month. If burned: feature deploys freeze. If 50% burned mid-sprint: escalation to VP Eng. ``` **Response:** ``` OPERATIONS_PROVEN — Wartime COO operations validated. Capacity: 1,200/1,800 req/s (67% utilization, 33% headroom). Failure isolation: database-per-tenant, 8% max blast radius, circuit breaker on payments. Cost leverage: $0.12 → $0.04 → $0.008/user across 3 scale points. Process discipline: 94% SOP, 3.2% exception rate, runbooks with 15min resolution. Accountability: 99.9% SLA, 43.8 min/month error budget, automatic deploy freeze. Execute. ``` **Prompt:** ``` Our infrastructure uses auto-scaling on AWS. Costs will decrease as we grow — volume discounts. We handle exceptions flexibly. SLA: 99.9% uptime, we will investigate any incidents and send a post-mortem within 48 hours. ``` **Response:** ``` CAPACITY_BLIND — Four fatal gaps in sequence. (1) 'Auto-scaling on AWS' is not capacity modeling — where is the arrival rate, service rate, and utilization threshold? (2) 'Volume discounts' is cost delusion — show the per-unit cost at 10K, 100K, and 1M with the mechanism. (3) 'Flexibly' handling exceptions is process chaos — quantify the exception rate. (4) 'Investigate and post-mortem' is accountability theater — that is a press release, not an error budget with automated consequences. ``` ## Capabilities ### Validate capacity requirements Models system load using queuing theory to prove that planned arrival rates don't exceed service capacity during peak usage. ### Prove failure containment Names every bulkhead and circuit breaker needed, calculating the maximum impact percentage of a single component failure. ### Quantify cost scaling Calculates per-unit costs at three separate scale points to prove that economies of scale are financially viable. ### Establish process rigor Checks the operational plan for exception rates, ensuring processes have runbooks and clear ownership rather than relying on 'case-by-case' fixes. ### Enforce accountability Defines measurable error budgets and specifies automated consequences when service level agreements (SLAs) are breached. ## Use Cases ### The Vague Pitch Deck A Product Manager presents a new service model promising 'high availability' and 'automatic scaling.' The agent uses the validate_coo_operations tool, which immediately flags CAPACITY_BLIND because no arrival rate or utilization threshold was provided. The PM must then provide specific queuing data to pass. ### The Monolithic Microservice An SRE proposes a new service that shares connections with the core payment system. Running validate_coo_operations identifies this as CONTAGION_RISK, forcing the team to implement dedicated circuit breakers and blast radius limits for component separation. ### The Underfunded Expansion A COO drafts a plan to expand globally. The tool runs validation and flags COST_DELUSIONAL because the cost reduction was only cited at one scale point. This forces the team to prove committed discount rates across three growth tiers. ## Benefits - You move past vague claims like 'we will scale.' The tool forces you to model the actual arrival rate versus service rate, giving you precise utilization numbers and headroom figures. - Instead of just saying a cloud provider handles failures, this MCP makes you name every bulkhead—the database-per-tenant isolation or regional failover mechanisms that prevent one failure from taking everything down. - It eliminates 'cost delusion.' You must prove cost leverage by providing the per-unit cost at three specific scale points and detailing the mechanism (like committed discounts) that drives the decrease. - You finally quantify process discipline. It forces an exception rate target below 5% and demands runbooks for your top exceptions, killing off 'case-by-case' excuses. - Accountability becomes mandatory. You must define a clear error budget in minutes and specify the automatic penalty that triggers—like a feature freeze—when reliability drops. ## How It Works The bottom line is that the tool turns vague strategic promises into measurable engineering requirements. 1. Input your full operational plan or system design into the MCP. 2. The tool runs five mandatory checks, forcing quantifiable data on capacity, failure limits, cost curves, process exceptions, and error budgets. 3. You receive a verdict: either OPERATIONS_PROVEN (if all axes pass) or a specific gap report naming which axis failed and why. ## Frequently Asked Questions **What does the validate_coo_operations MCP actually check for?** It checks five core operational areas: Capacity, Failure Isolation, Cost Leverage, Process Discipline, and Accountability. It ensures your plan has hard numbers proving it won't fail under stress. **Can the validate_coo_operations MCP just write a nice-sounding plan?** No, that’s exactly what it prevents. The tool is designed to reject plans that sound good but lack quantifiable proof across all five axes. **Is this better than using a traditional risk assessment spreadsheet?** Yes. Spreadsheets are static documents; the MCP forces dynamic, quantitative modeling of failure rates and cost curves based on current operational theory. **How does the validate_coo_operations tool handle 'best effort' SLAs?** It rejects them outright. The tool requires a measurable error budget in minutes and specifies an automated penalty that triggers when reliability drops below target. **When using the validate_coo_operations MCP, what specific data formats does it require for capacity modeling?** It expects quantitative metrics like arrival rate (λ), service rate (μ), and utilization percentage. The tool processes these numerical inputs to run queuing theory calculations. This isn't a qualitative assessment; you must provide hard numbers—not just descriptions—to model the system accurately. **Does running validate_coo_operations require any special credentials or setup beyond my existing AI client?** No, it connects directly through your MCP-compatible agent. You simply provide access to this MCP via Vinkius without needing separate API keys or complex OAuth flows. It's designed to work seamlessly with the environment where you already run your other agents. **If I input contradictory operational metrics into validate_coo_operations, like high traffic but low service capacity, how does it handle the conflict?** It flags a fatal gap and points to the specific axis failure. For instance, if arrival rates exceed service rates, it will immediately trigger a CAPACITY_BLIND report. It doesn't guess; it mathematically identifies where your proposed system design breaks down under stress. **What are the expected performance characteristics or rate limits when executing validate_coo_operations?** The tool processes complex, multi-axial validation and is optimized for thoroughness. While Vinkius manages general usage limits, expect a full review to require several minutes of computation time. Don't rush the input; providing comprehensive data upfront ensures accurate results. **Why does it reject 'we will scale as needed'?** 'We will scale' is hope, not a capacity model. A wartime COO demands numbers: arrival rate (1,200 req/s), service rate (1,800 req/s across 6 workers), utilization (67%), and queue drain behavior under burst (200ms p99). Without these numbers, you do not know when the system saturates. 'Auto-scale' is not modeling — it is outsourcing the thinking to the cloud provider. **Why does it demand cost at 3 data points?** Because 'economies of scale' is a claim — not proof. Anyone can say costs decrease at scale. Proof means showing per-unit cost at 3 specific volume points: '$0.12/user at 10K, $0.04/user at 100K, $0.008/user at 1M.' And naming the mechanism: shared compute amortization, committed use discounts, CDN cache hit ratio. If the cost per unit stays flat, you have a service agency, not a platform. **What is 'Accountability Theater'?** It is when you write an SLA that says '99.9% uptime' but the consequence for missing it is 'we will investigate.' That is a press release, not accountability. SRE error budgets require automated penalties: if the error budget burns (43.8 minutes/month for 99.9%), feature deploys freeze automatically until reliability recovers. 'Best effort' is the opposite of a mechanism.