# Elon Musk Physics Prover MCP > The Elon Musk Physics Prover forces your AI client to validate any major design or operational decision using a rigid 5-Step Starbase Algorithm. Instead of accepting requirements blindly, it first attacks the premise, mandates deleting every superfluous part, simplifies what remains, accelerates cycle time estimates, and finally—and only then—justifies automation. Stop building complexity; start engineering reality. ## Overview - **Category:** architecture - **Price:** Free - **Tags:** first-principles, physics, starbase-algorithm, deletion, simplification, cycle-time, automation ## Description Most operational strategy advice is bloat. An LLM accepts constraints as given, adds layers of review, and jumps straight to automating a process that should never exist. That's consulting fluff, not actual engineering. This MCP forces your AI agent through the 5-Step Starbase Algorithm before it validates any decision. It starts by making you question every requirement, forcing you to name the person who made it and attack its core assumption. Next, you list everything that should be deleted—not improved or refactored. Only then do you simplify what survived deletion. After that, you calculate how fast you can actually ship an iteration. Finally, if anything remains, you automate it. The entire process must follow this strict sequence; skipping steps results in immediate failure warnings like Requirement Blindness or Broken Automation. You connect to this MCP through Vinkius and immediately stop building processes based on assumptions. ## Tools ### validate_elon_musk_physics Runs the full 5-Step Starbase Algorithm on a major process design, checking for requirement assumptions, unnecessary parts, simplification scope, speed targets, and automation justification. ## Prompt Examples **Prompt:** ``` We need to create 5 specialized departments, add a review queue for resilience, and automate the approval pipeline to handle the new demand. ``` **Response:** ``` REQUIREMENT_BLINDNESS + BROKEN_AUTOMATION — You accepted '5 departments' and 'review queue' as given without questioning who required them or why. Step 1: WHO demanded 5 departments? At what volume? Is a single team insufficient? Step 2: DELETE the review queue — at 12 requests per day it is bureaucracy, not resilience. Step 5: You jumped to automating approvals for a bloated structure. Delete first, simplify survivors, then automate what remains. ``` **Prompt:** ``` The director required capacity for 100K daily orders. We questioned this — actual data shows peak is 800 per day. Deleted: redundant supervisory layer (one coordinator handles 800), 4 of 5 specialized sub-teams (merged into a single cross-functional unit), external tracking subscription (internal records suffice). Survivors simplified: single team from 12 workflows to 5. Cycle time: changes implemented in 20 minutes via direct team briefing. Automation: single-step execution of the 5-workflow operation. ``` **Response:** ``` PHYSICS_PROVEN — Starbase Algorithm Complete. Step 1: Director's 100K requirement attacked — actual peak is 800 (125x overestimation). Step 2: supervisory layer, 4 sub-teams, and external tracking deleted. Step 3: surviving team simplified from 12 to 5 workflows. Step 4: 20-minute implementation cycle via direct briefing. Step 5: single-step automation of simplified operation. Ship it. ``` **Prompt:** ``` We will optimize our 7-step email drip campaign for better conversion rates and automate lead scoring using AI to make the process production-ready and enterprise-grade. ``` **Response:** ``` PREMATURE_OPTIMIZATION + ITERATION_AVERSION — Three violations. First: you are OPTIMIZING a 7-step campaign — why does it have 7 steps? Step 2 says DELETE. Throw away 5 steps. Second: you jumped to AUTOMATING lead scoring on an undeleted process. Third: 'production-ready' and 'enterprise-grade' are perfection language — the enemy of cycle speed. Delete 5 steps. Simplify to 2. Ship in hours, not months. ``` ## Capabilities ### Challenge requirements Forces the AI to question every stated need, demanding the source person and core assumption behind it. ### Mandate deletions Requires listing all components, steps, or processes that must be removed entirely from the design. ### Simplify surviving parts Ensures optimization only happens on elements that survived the deletion phase. ### Calculate speed requirements Shifts focus from theoretical perfection to concrete, rapid cycle time estimates for shipping an iteration. ### Validate automation scope Checks that automation is only applied to the simplest, undeleted, and unsimplified core process. ## Use Cases ### Scaling a new onboarding workflow A team designed an 8-step onboarding process. The MCP forces them to realize that three of those steps are actually manual sign-offs from separate departments, which must be deleted entirely before any automation can happen. ### Revising a legacy database schema Instead of simply optimizing the old structure, the MCP forces an assessment that half the data fields are redundant. The team deletes those fields and simplifies the remaining connections, vastly reducing complexity. ### Improving customer service triage The initial plan was to build a complex AI routing system. Running through the MCP proves that most tickets are simple password resets. Deleting the advanced routing layer means implementing a single self-service flow instead, drastically cutting development time. ### Planning a new marketing campaign funnel The team wanted to 'optimize' a 10-stage lead nurturing sequence. The MCP quickly proves that five stages are irrelevant and deletes them, simplifying the path into three rapid touchpoints for immediate deployment. ## Benefits - You stop accepting requirements as gospel. The tool forces you to name the person who asked for a feature and attack its core assumption before proceeding. - It mandates deleting parts, giving you a list of components or steps that are genuinely unnecessary, rather than just 'refactoring' them. - By focusing on cycle time acceleration over perfect enterprise-grade outcomes, it keeps your development sprints moving fast and shipping code faster. - The MCP ensures automation is the last step. It blocks you from building complex pipelines around processes that should have been deleted or simplified first. - It provides explicit failure warnings (like Deletion Cowardice) if your design skips steps, making assumptions visible at the outset. ## How It Works The bottom line is that this MCP prevents over-engineering by enforcing a strict sequence: question first, delete second, simplify third, accelerate fourth, and automate last. 1. You submit a major design or operational plan to the MCP. The system first forces you to question every requirement, identifying who created it and why. 2. The AI then mandates deleting parts, forcing you to list what is unnecessary before optimizing anything else. 3. Finally, the tool validates if the proposed automation step only applies to the minimal, simplified remainder of the process. ## Frequently Asked Questions **What if my process needs both optimization and automation?** You must use the MCP to prove the sequence. You first delete parts, then simplify what remains, and only after that can you justify automating the final, minimal operation. **Can I bypass the steps in validate_elon_musk_physics?** No. The MCP is designed to fail if any step is skipped or executed out of order. It enforces the 5-Step Starbase Algorithm strictly. **Does this help with code reviews, or just process flow?** It's best for validating high-level system architecture and operational flows. While it can guide technical decisions by challenging requirements, its focus is on the 'why,' not the specific lines of code. **Is this MCP only for large corporate systems?** No. It works for any process where assumptions lead to waste—even simple internal team workflows or small campaign funnels benefit from its rigor. **Why does it reject optimization?** It rejects PREMATURE optimization. The most common error of a smart engineer is to optimize a thing that should not exist. You must prove you DELETED parts (Step 2) before the engine allows you to simplify (Step 3). If you are optimizing a Kafka queue that should not exist, you are wasting time on the wrong problem. **Why must I name the person who created the requirement?** Because requirements without a name attached become immovable. When a requirement is anonymous, no one questions it. When you attach a name, you can ask: 'Is this person still right? Has the context changed?' Most requirements were created by someone who no longer works on the project. **What is 'Deletion Cowardice'?** It is the instinct to add instead of delete. When an engineer encounters a problem, the reflex is to add a cache, add a queue, add a service. The Starbase Algorithm demands the opposite: the best part is no part. Delete first. If you are not occasionally forced to add back 10% of what you deleted, you are not deleting enough.