# Estimation Prover MCP > Estimation Prover forces structured project planning before you commit to a timeline. This MCP validates estimates by forcing granular scope breakdown, identifying all technical unknowns and dependencies, mapping historical precedents, and applying concrete contingency buffers. Stop guessing; start calculating. ## Overview - **Category:** productivity - **Price:** Free - **Tags:** estimation-prover, planning-fallacy, scope-decomposition, risk-mitigation, agile-planning, contingency-buffer, historical-forecasting, agentic-timeline ## Description Project timelines are notoriously wrong. Developers and PMs tend to underestimate—a phenomenon called the Planning Fallacy. Estimation Prover acts as an immediate gatekeeper for any proposed timeline. It doesn't just calculate a date; it forces you through structured checks that expose blind spots in your plan. Instead of giving one vague number like 'three weeks,' this tool demands you break the work into micro-tasks, documenting every potential technical risk and dependency failure point. You have to cite specific historical projects for comparison, not just say 'based on experience.' It also forces you to assign a numerical contingency buffer—a real safety net—and list every single assumption: Who's available? Does the API even work yet? If any of those things shift, your original estimate fails. Connecting Estimation Prover through Vinkius lets your AI client enforce this rigor directly into your planning process. You get an objective verdict on whether a timeline is realistic or just wishful thinking. ## Tools ### validate_estimation Forces a structured review of your project plan, requiring scope decomposition, unknown mapping, historical comparisons, buffers, and explicit assumptions to validate any timeline. ## Prompt Examples **Prompt:** ``` Let's build a new mobile catalog. It should take around 2 weeks since the requirements are straightforward. ``` **Response:** ``` Verdict: SCOPE_VAGUE. A single 2-week estimate lacks task decomposition. Break the catalog work into clear components: database sync, listing UI, navigation actions, cache storage, and reviews. Define time estimates for each unit to build a reliable timeline. ``` **Prompt:** ``` Task: build mobile catalog. Breakdown: 1. local SQLite DB sync (2 days), 2. layout grid UI (2 days), 3. detail views (1 day), 4. offline image caching (2 days). Unknowns: SQLite sync conflicts. Precedent: last year's web catalog SQLite sync took 3 days due to sync conflicts. Buffer: 30% added (2.1 days buffer on 7 days total). Assumptions: requirements do not change during development, team size is 1 developer. ``` **Response:** ``` Verdict: ESTIMATION_PROVEN. Scope is decomposed into tasks ≤2 days. SQLite risks are identified. Grounded in precedent (last year's sync issues). Realistic 30% buffer applied. Scope assumptions are explicit. This estimate is verified. ``` **Prompt:** ``` Task: mobile catalog. Decomposition: SQLite sync (2 days), grid UI (2 days), detail views (1 day), image caching (2 days). Unknowns: Sync conflicts. Precedent: last year's SQLite sync. Buffer: none needed since requirements are simple. Assumptions: requirements do not change, 1 dev. ``` **Response:** ``` Verdict: NO_BUFFER. You have omitted a contingency buffer. Even if requirements seem simple, SQLite sync conflicts are an identified risk. Apply a minimum 20% buffer to account for integration delays. ``` ## Capabilities ### Decomposing scope Breaks large, vague tasks into small, manageable units that are easier to estimate. ### Quantifying unknowns Requires documentation of technical risks and external dependencies, noting the potential impact if they materialize. ### Mapping history Grounds current estimates in concrete data from similar projects completed in the past. ### Calculating buffers Adds a specific, measurable contingency time to account for known project volatility and cognitive biases. ### Stating assumptions Forces explicit definition of all resource limits, scope stability points, and external dependencies. ## Use Cases ### The Vague Feature Request A Product Manager proposes a new user dashboard update, estimating it will take 3 weeks. The agent runs this through the MCP and immediately flags 'SCOPE_VAGUE,' forcing the PM to break the work down into database changes, UI components, and data validation layers for accurate timing. ### The Overly Optimistic Dev Lead A Development Lead estimates a complex microservice migration will take 2 sprints. The MCP checks it against historical records, revealing that similar migrations always took 35% longer due to unexpected network latency issues, forcing the lead to adjust the plan. ### The Missing Safety Net A team plans a small internal tool, assuming everything will be straightforward. The MCP runs its check and returns 'NO_BUFFER,' reminding them that even simple tasks require at least a 20% contingency time for unexpected integration hiccups. ## Benefits - Stops scope creep before it starts. By forcing granular decomposition, you immediately see if a 'single task' is actually 10 separate units of work. - Mitigates the Planning Fallacy. You stop relying on gut feelings and start basing your timeline on concrete historical data from past projects. - Forces risk ownership. It requires you to name technical unknowns—like API changes or library deprecations—and quantify their potential impact, so they can't be ignored later. - Guarantees contingency time. You don't just get a date; you get a realistic buffer number that accounts for human error and integration delays. - Defines the boundaries. The tool forces every stakeholder to state assumptions about resources and scope stability, preventing late-stage 'feature creep' surprises. ## How It Works The bottom line is that you get an objective pass/fail grade on your project plan before any code is written. 1. First, feed the tool your proposed project scope. The system will reject any single timeline or vague description. 2. Next, it forces you to map out every dependency, list technical risks, and provide a specific historical comparison for grounding. 3. Finally, it outputs a verdict: whether the estimate is verified, if it needs more buffer, or if the scope itself is too ambiguous. ## Frequently Asked Questions **How does Estimation Prover validate an estimate?** It analyzes the inputs based on a 5-pivot validation. You provide the task decomposition, risk mapping, historical context, buffer metrics, and assumptions. It rejects single-line guesses or projects without buffers. **What is the recommended buffer size?** The tool enforces a minimum 20% buffer on projects with clear precedents, and increases to 40% or more for complex integrations, new frameworks, or systems with high architectural risk. **How does Reference Class Forecasting work here?** It forces you to compare the new project with similar work completed in the past. If your past authentication integration took 3 weeks instead of the planned 1 week, you must adjust the new estimate's baseline accordingly. **How do I get started connecting Estimation Prover to my development workflow?** You connect this MCP via your preferred AI client. Once connected, you can simply prompt your agent with a preliminary estimate for immediate validation. The system routes the scope data through the structured estimation process. **What kind of input does validate_estimation need to run correctly?** The tool needs more than just a paragraph; it requires four distinct inputs: a task breakdown (decomposition), identified unknowns, specific historical references, and stated assumptions. It processes structured data points, not general text blocks. **Does Estimation Prover handle complex systems with multiple service dependencies?** Yes, it analyzes dependency chains effectively. For optimal results, however, break the large system into functional micro-milestones first. This ensures each component receives detailed attention regarding its unique risks. **What should I do if my initial estimate contains circular dependencies?** If a dependency loop exists (e.g., A needs B, and B needs A), the tool flags it immediately. You must manually break the cycle by defining an external service or temporary workaround to allow validation to proceed. **Is my proprietary project scope data secure when using Estimation Prover?** Your input is processed within a secured, session-based environment. The MCP does not retain sensitive, unvalidated project details after the execution completes. Focus on providing the raw inputs for analysis.