# Requirement Decomposition Prover MCP > Requirement Decomposition Prover forces complete system specification before code is written. This tool eliminates the '80% Problem' by systematically validating functional requirements against failure modes: mapping all error states, covering every edge case (nulls, Unicode, concurrency), enforcing OWASP security standards, and planning structured observability. ## Overview - **Category:** productivity - **Price:** Free - **Tags:** requirement-decomposition, specification, error-handling, edge-cases, security-validation, observability, owasp, agentic-pipeline ## Description Look, your AI agent's good at spitting out the main API endpoint and making the form submit data. But you know how it is—it always misses the critical twenty percent: the failure modes that wreck production when things go sideways. You don't want that headache. This server runs a structured check on feature specifications using the `validate_requirement_decomposition` tool, forcing you to map out every single piece of this thing before you write a line of code. It acts like an automated architecture review, making sure your plan accounts for everything that could go wrong. It starts by verifying state transitions; you gotta specify the exact sequence of steps a feature takes—from when the user inputs data to when it hits permanent storage—and confirm what success looks like at every single junction. It doesn't accept vague stuff like, 'it should work.' You gotta define specific values and types for everything. When things break, you need to know why. The tool forces you to map out every potential error state. Think database timeouts or auth failures—you got to list them all, then mandate a specific recovery strategy for each one. This means defining the detection method, what the user sees when it goes south, and exactly how your system gets back on its feet. It handles more than just errors; you gotta check every single input boundary. It forces you to consider edge cases like empty strings, maximum character limits, or null values. You'll also cover Unicode ranges—that means emojis, accents, whatever weird characters people throw at it—along with concurrent access issues and date/time zone shifts. Security isn't optional. The server validates requirements against the OWASP Top 10 web vulnerabilities for every endpoint. It demands that you plan for proper input validation and hashing right from day one because every single piece of user input is treated like it's hostile. You gotta define things like rate limiting upfront. And since nobody fixes what they can't see, the tool mandates observability planning. This means defining structured logging—you mean queryable logs, not just plain text dumps—and specifying performance metrics, like p95 latency figures. You also have to set up alert thresholds and plan for distributed tracing if your workflow involves any async steps. ## Tools ### validate_requirement_decomposition Runs a structured check on feature specifications to ensure complete coverage of happy paths, failure modes, edge cases, security risks, and observability requirements. ## Prompt Examples **Prompt:** ``` Build a user registration endpoint with email and password. Store in the database and return a JWT token. ``` **Response:** ``` Verdict: ERROR_STATES_MISSING. Happy path defined (register, store, return JWT) but no error states mapped. What if email already exists? What if DB connection fails? What if password doesn't meet policy? What if email validation fails? What if the JWT signing key is unavailable? Map every failure mode with recovery strategy. ``` **Prompt:** ``` Create a file upload API that saves files to disk. Assume the client sends valid image files. ``` **Response:** ``` Verdict: EDGE_CASES_MISSING. Assuming valid files violates security guidelines. You must specify limits on file size, allowlist file extensions, scan for malware, generate unique filenames to prevent path traversal, and define how to handle storage space exhaustion. ``` **Prompt:** ``` Happy path: POST /register → validate → hash → store → sign JWT → return 201. Errors: 409 duplicate email, 422 validation failure, 503 DB unavailable, 500 JWT signing failure. Edge cases: unicode emails, max length 254, concurrent registration, empty fields. Security: bcrypt cost 12, rate limiting, CSRF, input sanitization. Observability: structured JSON logs, Sentry, p99 latency metric. ``` **Response:** ``` Verdict: REQUIREMENTS_PROVEN. Happy path fully specified with inputs/outputs. Error states mapped with HTTP codes and recovery. Edge cases covered (unicode, max length, concurrency, empty). Security validated (bcrypt, rate limiting, CSRF, sanitization). Observability planned (structured logs, Sentry, p99). Ready for implementation. ``` ## Capabilities ### Validate all failure paths The tool maps every potential error state—like database timeouts or authentication failures—and mandates a specific recovery strategy. ### Test input boundaries and types It forces you to check for edge cases, including empty strings, maximum character limits, Unicode characters (emojis, accents), concurrent access, and date/time zone shifts. ### Enforce OWASP security standards The tool validates requirements against the top 10 web vulnerabilities, ensuring proper input validation and hashing are defined upfront for every endpoint. ### Define structured logging and metrics It requires plans for production observability, demanding queryable logs (not plain text) and specific performance metrics like p95 latency. ### Verify state transitions You specify the exact sequence of steps a feature takes—from input validation to final data storage—and confirm success criteria at every point. ## Use Cases ### Building a User Profile Update API The architect needs an endpoint that updates user details. The agent runs `validate_requirement_decomposition`. It fails because the requirements only specify 'name' and 'bio,' but miss handling null values, max-length limits on bios, or what happens if the connected profile picture service is slow. This forces the team to add validation for all fields. ### Implementing a Payment Gateway Integration A developer writes the happy path for processing payments. The agent runs `validate_requirement_decomposition`. It fails immediately because it didn't map failure modes: What if the payment gateway is slow (>2s)? What if the network drops after authorization but before confirmation? This forces implementation of retry logic and robust error reporting. ### Designing a File Upload Service The team writes an API to save images. The agent runs `validate_requirement_decomposition`. It fails because it assumes the input is safe. The tool forces mandatory checks for file size limits, allowlisting extensions, and scanning for malware—security requirements that were previously treated as optional. ### Creating a Time-Sensitive Reporting Tool The team builds a report that aggregates data across time zones. The agent runs `validate_requirement_decomposition`. It flags the lack of explicit handling for Daylight Saving Time (DST) transitions and leap years, ensuring the reporting logic remains accurate regardless of calendar anomalies. ## Benefits - Catch the 80% Problem: Instead of shipping code that works for 'John Smith,' you get a spec validated against nulls, Unicode, and max-length strings. This prevents runtime bugs related to data boundaries. - Mandatory Failure Mapping: You don't just define success; you map every possible failure—DB timeout, API rate limit, network drop. The tool forces you to plan the user response and recovery steps for each. - Security by Design: It treats security as a non-negotiable requirement from day one. You won't forget hashing or input sanitization because the tool demands OWASP adherence for every endpoint. - Production Visibility Plan: Instead of `console.log` messages, you build structured logs and define performance metrics (like p95 latency) right into your requirements, making production debugging predictable. - Concurrency Handling: If multiple users hit a resource at once, this tool forces you to specify the handling mechanism (e.g., optimistic locking), preventing race conditions before deployment. ## How It Works The bottom line is that this tool forces you to prove your plan works under duress, making sure the technical design accounts for every way it could possibly fail. 1. Feed your proposed feature requirements into `validate_requirement_decomposition`. This initiates the structured review process. 2. The tool analyzes the input against its internal framework (IEEE 830, OWASP, SRE principles), pinpointing missing error states, security gaps, or insufficient boundary definitions. 3. You receive a detailed verdict—either 'REQUIREMENTS_PROVEN' (ready to code) or a specific failure category (e.g., ERROR_STATES_MISSING). You must then decompose the requirements further. ## Frequently Asked Questions **How does Requirement Decomposition Prover work with existing APIs?** You feed the tool documentation or a sample usage flow for an existing API. The server will analyze it and tell you exactly which failure modes, security gaps (like missing rate limiting), or edge cases are currently unaddressed in your design. **Is Requirement Decomposition Prover just another linter?** No. A linter checks syntax; this server validates the *architecture*. It forces you to document requirements that aren't code—like 'on timeout, send user email notification.' It moves validation from compile-time to design-time. **What is the difference between using it and a traditional spec writer?** A human spec writer might miss obscure edge cases (Unicode, DST). The tool uses structured frameworks (IEEE 830) to systematically check for gaps that humans often overlook under pressure. It’s automated rigor. **Can I use Requirement Decomposition Prover if my feature is simple?** Yes, but don't skip it. Even a 'simple' feature needs input validation, failure mapping (what if the dependency fails?), and observability planning to be production-ready. **How does Requirement Decomposition Prover handle complex authentication flows?** It maps out every failure point in your auth system. It doesn't just check for valid logins; it requires documenting what happens when a token expires, credentials fail due to rate limits, or the identity provider is unreachable. This forces you to plan for recovery and user feedback at every step of the authentication process. **Does `validate_requirement_decomposition` cover concurrency issues?** Yes, it specifically requires mapping out concurrent access scenarios. You must define behavior when two or more users try to update the same resource simultaneously (e.g., a shopping cart count). This forces you to specify locking mechanisms and conflict resolution strategies. **Can Requirement Decomposition Prover help me define non-functional performance requirements?** The tool mandates specifying key performance metrics like P95 latency and expected throughput. Instead of saying 'it must be fast,' you define measurable goals, such as 'the API response time must be under 200ms for 95% of users'—making it actionable for engineering. **What is the required format after using the Requirement Decomposition Prover?** The output isn't just a pass/fail. It provides highly structured feedback, detailing exactly which of the five core pivots (Error States, Edge Cases, Security, etc.) are incomplete. You get specific, actionable requirements that you must address and resubmit before writing code. **Does this replace writing user stories or PRDs?** No. It supplements them by forcing the AI to decompose beyond the happy path. Most user stories specify what should happen. This tool forces specification of what happens when things go wrong — the failure modes, edge cases, security vectors, and observability requirements that stories typically omit. **Should I call this before or after Code Integrity Prover?** Before. Requirement Decomposition ensures the SPECIFICATION is complete. Code Integrity ensures the IMPLEMENTATION is clean. The workflow: decompose requirements → generate code → validate code integrity. Fixing incomplete requirements after code exists is expensive — fixing them before code exists is free. **How does the prover validate security requirements?** It checks the specification against the OWASP Top 10 guidelines (such as SQL injection, XSS, and broken auth). It flags statements that treat inputs as implicitly trusted.