# Leonardo da Vinci Prover MCP > The Leonardo da Vinci Prover MCP forces your AI agent to actually do the design work before handing you a solution. It rejects generic best practices and demands proof of direct observation, cross-domain synthesis, testable prototypes, constraint exploitation, and multiple variations. Stop accepting single-draft, untested architecture from your agent. ## Overview - **Category:** design - **Price:** Free - **Tags:** design-thinking, cross-disciplinary, observation, prototyping, iteration, constraints, leonardo-da-vinci, creative-engineering ## Description The Leonardo da Vinci Prover MCP stops your AI agent from handing you generic, untested first drafts. You ask it to design a checkout flow or a data pipeline, and it immediately spits out a polished solution based on industry best practices. It skips the messy part. It does not watch real users. It does not build a prototype. It just gives you one final answer. This MCP fixes that. It acts as a brutal design reviewer. When your agent proposes a solution, this tool runs it through a five-point methodology. It checks if you actually observed the real system instead of guessing. It demands you pull insights from unrelated fields. It forces you to build something you can break, rather than just writing a planning document. It makes you treat budget limits as creative fuel instead of excuses. And it requires multiple variations with real trade-offs, not just one final concept. If your agent skips any of these steps, the tool rejects the design and tells you exactly which cognitive gap you fell into. You get a specific verdict like observation absent or interdisciplinary blind, so you know exactly what to fix. You can plug this into Vinkius and connect it to your preferred AI client to enforce this rigor automatically. It turns your agent from a yes-man who writes planning documents into a rigorous design partner that actually builds and tests. ## Tools ### validate_davinci_design Checks a design proposal against five methodology pivots and returns a pass or a specific rejection verdict. ## Prompt Examples **Prompt:** ``` The best approach for this enrollment process is a 3-step flow: registration → verification → confirmation. This is the industry standard and most participants expect it. ``` **Response:** ``` OBSERVATION_ABSENT — 'Industry standard' and 'most participants expect it' are borrowed knowledge — someone else's observation of someone else's participants. Da Vinci dissected cadavers to understand muscles he could not see from outside. What does YOUR enrollment data show? How many participants abandon at step 2? Where do they hesitate? What does a 5-minute observation session reveal that 'best practices' cannot? Observe YOUR process before designing for it. ``` **Prompt:** ``` Observed: watched 23 participant sessions on our current enrollment. 68% abandon at the personal details form — they see 11 fields and leave. The form itself is the friction, not the step count. Cross-domain: behavioral economics (Schwartz's paradox of choice) — reducing options reduces anxiety. Applied: streamlined form with 3 fields (postal code auto-fills location details) mirrors the 'smart default' principle from game design — players get moving instantly, customize later. Prototype: built a clickable walkthrough with the 3-field design. Tested with 8 participants — 7/8 completed in under 40 seconds. One participant wanted manual country selection (edge case: overseas military address). Constraint: budget for only 1 address verification per submission (lookup service quota). Exploited: postal-code-first design exists BECAUSE of the verification limit — one lookup returns city+state+country. Without the quota constraint, we would have built a 5-field form with real-time checks on each field, which is worse experience. Variations: (A) Single-page — all fields visible, scroll-based, optimizes for transparency. Trade-off: cognitive load from seeing payment before address. (B) Progressive disclosure — show only the current field, expand next on completion. Optimizes for focus. Trade-off: participant cannot review previous answers without scrolling back. (C) Conversational — guided sequential questions. Optimizes for simplicity. Trade-off: slower for experienced participants who can parallel-fill. Recommendation: B for walk-in participants (78% of volume), A for experienced staff, with shared processing. ``` **Response:** ``` DESIGN_PROVEN — Da Vinci Method complete. Observation: 23 participant sessions, 68% abandon at 11-field form — friction identified empirically, not from 'best practices.' Cross-domain: behavioral economics (paradox of choice) + game design (smart defaults) transferred to enrollment design — genuine synthesis. Prototype: clickable walkthrough tested with 8 participants, 87.5% success in 40 seconds, edge case (overseas address) documented. Constraint: address verification quota became the design parameter — postal-code-first exists BECAUSE of the limit. Variations: 3 alternatives (single-page, progressive disclosure, conversational) with annotated trade-offs and context-specific recommendation. This is design. ``` **Prompt:** ``` Observed: analyzed 3 months of operational incident logs — 340,000 delays, 72% are bottleneck-related, concentrated in the order lookup step. Cross-domain: from a purely operational perspective, we need to add a staging buffer and streamline the search procedure. ``` **Response:** ``` INTERDISCIPLINARY_BLIND — Observation passes: 340K delays, 72% bottlenecks, concentrated step — this is empirical data. But cross-domain fails: 'from a purely operational perspective' is single-domain thinking. Da Vinci connected fluid dynamics to painting. What does queueing theory (mathematics) teach about your bottleneck pattern — is it gradual accumulation or a sudden surge? What does urban planning teach about your lookup flow — is this a highway bottleneck or a neighborhood dead-end? The transferred insight changes the solution: a staging buffer fixes symptoms, but queueing theory reveals whether the problem is concurrency (add staff) or sequencing (parallelize steps). ``` ## Capabilities ### Reject unobserved designs Catches when the agent guesses instead of studying the actual system and user behavior. ### Force cross-domain thinking Blocks single-domain solutions by demanding insights from completely unrelated fields. ### Demand testable artifacts Rejects paper plans and requires actual prototypes that can be broken and tested. ### Exploit budget limits Reframes financial and technical constraints as core design parameters instead of blockers. ### Require design variations Blocks single final answers and forces multiple alternatives with annotated trade-offs. ## Use Cases ### Agent suggests an industry standard flow The agent suggests a standard enrollment flow. You run it through validate_davinci_design, which rejects it for lacking direct observation of your specific user drop-off data. ### Architect proposes a purely technical pipeline An architect proposes a data pipeline based purely on operational perspectives. The validate_davinci_design tool flags it as interdisciplinary blind, forcing the agent to apply queueing theory. ### Team faces strict API call limits A product team needs to design a checkout flow with a strict limit on address verification calls. The validate_davinci_design tool forces the agent to exploit that constraint for the design. ### Designer presents a single final wireframe A designer presents a single final wireframe for a new dashboard. The validate_davinci_design tool rejects it for iteration refused, forcing the agent to produce three distinct variations. ## Benefits - You stop getting generic best practices. The validate_davinci_design tool rejects proposals that rely on borrowed knowledge instead of direct observation of your actual users. - Your designs actually get tested. The validator blocks paper-only plans and forces your agent to describe a testable prototype that answers specific questions. - You stop hearing about budget blockers. The tool reframes your financial and technical limits as core design parameters that shape the final invention. - You get real trade-offs instead of one final answer. The validator rejects single-concept proposals and demands multiple variations with annotated pros and cons. - Your agent stops thinking in one dimension. The system catches single-domain thinking and forces the agent to pull insights from completely unrelated fields. ## How It Works The bottom line is your agent can no longer hand you a generic, untested first draft and call it a finished design. 1. Submit your design proposal or architecture plan to the validator. 2. The system checks your work against the five da Vinci methodology pivots. 3. Get a strict pass verdict or a specific rejection detailing exactly which design gap you need to fix. ## Frequently Asked Questions **How does Leonardo da Vinci Prover know if my agent actually observed users?** It checks for empirical data. If your agent cites industry standards instead of specific metrics from your own system, the validate_davinci_design tool rejects it for observation absent. **Can Leonardo da Vinci Prover work with my specific AI client?** Yes. You connect it once through Vinkius, and it works with any MCP-compatible client like Claude, Cursor, or VS Code to enforce design rigor across your workflow. **What happens if my agent skips building a prototype in Leonardo da Vinci Prover?** The tool flags it as prototype skipped. Your agent must describe a testable artifact, like a load test or clickable mockup, before the validate_davinci_design tool accepts the design. **Does Leonardo da Vinci Prover accept designs that just ask for a bigger budget?** No. It rejects this as constraint ignored. The validate_davinci_design tool requires your agent to reframe financial or technical limits as core design parameters. **How many variations does Leonardo da Vinci Prover require for a design?** It demands at least three distinct alternatives. If your agent only presents one final concept, the validate_davinci_design tool rejects it for iteration refused and forces annotated trade-offs. **What counts as a valid cross-domain connection in Leonardo da Vinci Prover?** It must be a genuinely unrelated field. Pulling insights from UI design when building a UI fails the check. You need to connect distinct worlds, like using fluid dynamics to solve a data pipeline bottleneck. The MCP rejects sub-field transfers. **How does the consistency engine in Leonardo da Vinci Prover catch contradictions?** It flags semantic traps and conflicting claims. If your agent claims it observed users but uses phrases like industry standard, the MCP rejects it. Borrowed knowledge is not direct observation, and the tool enforces that distinction strictly. **How often should I call validate_davinci_design during a single project?** Call it exactly once per complete design proposal. The tool evaluates the entire methodology at once. Running it on partial ideas triggers false failures, so wait until your agent has documented observations, built a prototype, and listed variations. **Is this only for visual design?** No. Da Vinci was an engineer, anatomist, architect, and painter. This tool applies his method to any creative problem: process design, product design, experience flows, organizational structure, service design, operational improvement. The 5 pivots — observe, connect domains, prototype, exploit constraints, iterate — apply wherever a human designs something for other humans. **What counts as cross-domain synthesis?** Two genuinely different disciplines, not sub-fields. Frontend and backend are the same domain. Psychology and software architecture are different domains. Biology and data modeling are different domains. Music theory and UI rhythm are different domains. The insight must transfer — not 'I thought about psychology' but 'cognitive load theory from psychology limits my dashboard to 7±2 elements per view.' **Why does it require 3+ variations?** Da Vinci's notebooks contain 50+ sketches of a single muscle group. One answer is a reflex — three variations with annotated trade-offs is design. Variation A optimizes for simplicity. Variation B optimizes for performance. Variation C asks 'what if the opposite were true?' The comparison reveals which trade-offs you are willing to make and which you are not.