# Scope Containment Prover MCP > Scope Containment Prover forces AI agents to apply YAGNI and define the absolute minimum viable product (MVP). This engine validates feature scope by forcing six critical checks: isolating the core problem, explicitly rejecting 'nice-to-have' features, proving necessity for every dependency, and mapping maintenance cost. It stops developers from building massive, unused systems. ## Overview - **Category:** reasoning - **Price:** Free - **Tags:** scope, yagni, over-engineering, mvp ## Description You know how it is when your AI agent starts building something and suddenly there's ten extra features that nobody asked for? It’s over-engineering, plain and simple. The Scope Containment Prover fixes that mess up. This MCP server acts as a hard gatekeeper, forcing any plan or piece of code through a ruthless audit before it ever leaves your client. It stops the typical AI habit of building massive systems just in case something *might* happen later. The **`validate_scope_containment`** tool runs a structured validation against six non-negotiable criteria to prove that what you're building is actually necessary for minimal development. When you run it, your agent doesn't just write code; it has to justify every single architectural decision by proving discipline across the whole project lifecycle. It starts by forcing **your AI client** to define the single core problem. It makes sure your agent can boil down a vague feature list into one irreducible user action and outcome—if you can't nail that, the scope is too wide, period. Next up, it tackles 'nice-to-have' crap by requiring explicit rejection of future features, forcing the agent to name exactly what it *isn’t* building so it doesn't fall into the trap of assumed necessity. The server then validates current scale, checking if your proposed infrastructure is overkill for how you actually use it. It keeps the complexity low until growth demands it; you don't want to build a skyscraper when all you need is a sturdy shed. To keep maintenance costs down, **`validate_scope_containment`** minimizes dependencies by forcing justification for every library used, suggesting native code alternatives if the problem can be solved with less than twenty lines of basic logic. It makes your agent account for long-term liability when mapping total cost of ownership. This isn't just about build time; it includes who fixes the thing next year and what that costs—testing updates, documentation, on-call support. Finally, it forces the definition of a true Minimum Viable Product (MVP), ensuring you can validate your core hypothesis with the smallest possible effort. If building that MVP takes more than two weeks, it’s not minimum. This process guarantees that every line of code and every dependency serves one singular, proven purpose. ## Tools ### validate_scope_containment Runs a structured validation against six criteria—Core Problem, YAGNI, Optimization, Dependencies, Cost, MVP—to determine if a feature is ready for minimal development. ## Prompt Examples **Prompt:** ``` Problem: Auth. YAGNI: none. Opt: none. ``` **Response:** ``` Verdict: YAGNI_VIOLATION. You must explicitly state what you are choosing NOT to build. ``` **Prompt:** ``` Problem: Button. YAGNI: no animation. Opt: Using Redis for state just in case. ``` **Response:** ``` Verdict: PREMATURE_OPTIMIZATION. Using Redis 'just in case' is exactly the bloat this trap prevents. ``` **Prompt:** ``` Problem: Send email. YAGNI: Rejecting bulk batching. Opt: Ignoring 1M/day scale. Deps: Using native fetch. Maint: Tiny function. MVP: One API call. ``` **Response:** ``` Verdict: SCOPE_CONTAINMENT_PROVEN. Perfect MVP isolation. ``` ## Capabilities ### Isolate Core Problem Forces the AI agent to define one single user action and outcome, rejecting vague feature lists. ### Reject Scope Creep (YAGNI) Requires the agent to explicitly name what it is *not* building, preventing the inclusion of 'nice-to-have' additions. ### Validate Current Scale Checks if the proposed infrastructure overbuilds for current usage metrics, keeping complexity low until growth demands it. ### Minimize Dependencies Forces justification of every library used; suggests native code alternatives when possible to reduce maintenance debt. ### Map Total Cost of Ownership Makes the agent account for long-term costs, including testing updates and on-call support, not just build time. ## Use Cases ### The bloated file upload system A team planned a simple CSV import. The agent kept suggesting adding drag-and-drop previews and image editing support. Running `validate_scope_containment` forced the AI to isolate the single problem: 'User selects CSV -> system validates format -> imports rows.' Everything else was flagged as a separate feature for a later sprint. ### Building for hypothetical growth A developer wanted to build an API endpoint assuming it would handle 10 million transactions. The tool immediately corrected this, showing the unnecessary complexity of message queues and sharding needed for that scale, recommending instead a simple single-server setup until data proves otherwise. ### The 'just in case' dependency An agent added Moment.js to handle date formatting because it was familiar. The validation flagged this as unnecessary bloat, pointing out that modern JavaScript can achieve the same result with native functions and zero maintenance overhead. ### Vague feature definition The initial request was 'Improve user management.' Running `validate_scope_containment` forced the agent to break it down into distinct, actionable components: (1) Password Reset API (MVP), (2) SSO Integration (Future Feature), and (3) Role-Based Access Control (Separate Epic). ## Benefits - Stops dependency bloat. Instead of adding a library for a minor formatting issue, the tool checks if native code can solve it in under 20 lines, saving maintenance debt. - Enforces MVP thinking. It forces the agent to define the absolute minimum needed to ship and validate, preventing multi-week projects from being bogged down by non-essential features. - Limits over-engineering. The 'Premature Optimization' check ensures you build for today’s user base (e.g., 200 files/month), not for a theoretical million users in three years. - Maps true cost of ownership. It makes the agent account for maintenance—who fixes it at 3 AM? This tool forces that calculation into the planning phase. - Clarity on scope. By forcing you to explicitly reject 'nice-to-have' features (YAGNI), the output is laser-focused on the single, necessary user outcome. ## How It Works The bottom line is that this tool forces your agent to think like an experienced engineer who hates wasted work and technical debt. 1. You feed your AI client a feature idea or an existing codebase plan. 2. The agent calls `validate_scope_containment`, forcing the model to perform six structured checks on the proposal's scope, optimization, and dependencies. 3. The tool returns a verdict: either 'SCOPE_CONTAINMENT_PROVEN' (ready for minimal build) or pinpoints exactly where the plan is bloated, over-engineered, or too costly. ## Frequently Asked Questions **How does the Scope Containment Prover prevent over-engineering?** It uses the 'Premature Optimization' pivot to make you state your current operational scale. The tool flags attempts to build for theoretical future growth, forcing you to optimize only for proven data. **Does validate_scope_containment handle dependency bloat?** Yes. It runs the 'Dependencies Minimized' check, requiring justification for every library. If a problem can be solved in native code under twenty lines, it will flag the external package as unnecessary debt. **What is YAGNI enforcement in the Prover?** YAGNI means 'You Aren't Gonna Need It.' The tool forces you to list features you are actively *rejecting*, ensuring the scope is constrained, not just broadly defined. **Can I use validate_scope_containment for non-coding tasks?** Yes. While focused on code, it applies its principles to any process flow. You can run it on a business workflow to ensure the steps are minimal and necessary. **How do I integrate `validate_scope_containment` into my agent workflow?** You run it as a mandatory pre-execution step within your AI client. You simply route its output to force the necessary architectural reflection before any code is generated or written. **What kind of input information should I provide when calling `validate_scope_containment`?** You must supply a clear feature concept and specific constraints for all six pivots. The quality of your initial prompt dictates how rigorous the scope analysis will be, so be detailed. **If `validate_scope_containment` returns an error or failure status, what should I do?** It means your current feature concept is too broad and lacks defined limits. The tool forces you to pinpoint exactly which 'nice-to-have' addition or assumption is causing the scope bloat. **Does using `validate_scope_containment` create any performance overhead?** The primary cost is structured thinking time, not computational power. By forcing upfront discipline, you save massive amounts of development time and effort by eliminating architectural rework later. **What does YAGNI mean?** 'You Aren't Gonna Need It'. It's the principle of not building features until you actually need them. **Why force rejection of premature optimization?** Because optimizing for 1M users when you have 10 adds massive complexity that slows down development. **Why map maintenance cost?** Code is a liability, not an asset. Every line written must be read, tested, and updated forever.