Inversion Thinking Prover MCP Connector for Claude

Inversion thinking (Munger) forces you to think backwards: instead of "how will this succeed," ask "how WILL this fail?" and then architect against the failure. You must: (1) state a FALSIFIABLE hypothesis — specific, measurable, testable. Not "it scales" — "it handles X at Y latency on Z resources," (2) articulate the EXACT OPPOSITE — the anti-pattern that represents the worst case. If you cannot describe the opposite, you do not understand the design space, (3) mount a BRUTAL red-team attack using deterministic language — "WILL fail," "WILL exhaust," "WILL crash." No "could," "might," or "potentially." Soft language is sycophancy, not analysis, (4) define KILL CRITERIA — the exact measurable metric that proves the hypothesis wrong. A threshold, a number, a measurement instrument. Unfalsifiable beliefs are not engineering, (5) design a DEFENSE that addresses the root cause, not the symptom. "Add more servers" is a symptom fix. "Connection pooling with specific configuration" is root-cause, (6) simulate the POST-MORTEM — what breaks AFTER you apply the defense? Every fix introduces new failure modes. Name them. If rejected, your architecture has not survived adversarial scrutiny.Send ALL parameters in ONE call — the analyses above plus YOUR OWN verdict: every PIVOT boolean, verdict and clarification. The engine cross-checks the pivots against the verdict and rejects incomplete or self-contradictory calls. Structured reflection tool for red-teaming architectural decisions via Charlie Munger-style inversion — forces hypothesis formalization, anti-pattern identification, deterministic failure simulation, kill criteria with measurable thresholds, defensive architecture, and second-order failure analysis. Catches Hypothesis Weak (vague architectural claims without specific, testable predictions — "our system scales well" is unfalsifiable. "Our system handles 10K requests/sec with p99 <200ms on 3 nodes" is a hypothesis that can be killed. Weak hypotheses survive all attacks because they make no specific claims), Anti-Pattern Blindness (inability to articulate the EXACT OPPOSITE of the proposed architecture — if you cannot describe the worst-case anti-pattern, you do not understand the design space. The anti-pattern reveals the failure mode the architecture is designed to prevent. Munger: "Invert, always invert"), Sycophancy Detected (using soft language — "could fail," "might degrade," "potentially risky" — instead of deterministic attack language. In red-teaming, the attack WILL happen. "The connection pool WILL exhaust at 500 concurrent requests because the pool size is 50 and each request holds a connection for 200ms" is deterministic. "Could potentially have issues under load" is sycophancy), Unfalsifiable Belief (kill criteria that cannot actually disprove the hypothesis — "performance degrades" is not measurable. "p99 latency exceeds 200ms at 5K rps measured by Prometheus histogram over a 5-minute window" IS measurable. If your kill criteria cannot produce a number that says "hypothesis is wrong," it is unfalsifiable), Defense Weak (architectural defenses that address symptoms instead of root causes — "add more servers" does not fix connection pool exhaustion. "Implement connection pooling with PgBouncer in transaction mode, max 200 connections, with queue_timeout=5s and server_idle_timeout=30s" is a root-cause defense), and Second-Order Blindness (failing to simulate what breaks AFTER the defense is applied — PgBouncer fixes the pool but introduces a new failure: prepared statement incompatibility in transaction mode. Every defense creates new failure modes. If you cannot name the next failure, you have not thought deeply enough). Call once per architectural decision