# Aristotle Logic Prover MCP > Aristotle Logic Prover forces any AI agent to analyze arguments using classical logic. It doesn't just read text; it proves if a concept is defined correctly (genus + differentia), separates core requirements from optional features, or confirms that a conclusion necessarily follows from its premises. Use this when vague definitions or weak assumptions could cost you time or money. ## Overview - **Category:** architecture - **Price:** Free - **Tags:** formal-logic, syllogism, categorization, teleology, dialectics, definition, aristotle, four-causes ## Description When your AI agent gives you an answer, how sure are you of the underlying logic? Often, agents use terms without defining them—they assume you know what 'scalable' means in a technical context, for instance. This MCP fixes that problem by forcing structured thought based on classical philosophy. It makes your agent define every key term using both its broader category (genus) and what makes it unique (differentia). Next, it separates what is absolutely essential to the system from what is merely helpful. The tool also confirms if a conclusion logically must follow from the starting assumptions. You can use it to identify the true purpose of a process—the 'why,' not just the steps. If you’re working on complex architecture or policy design, this MCP provides an academic rigor that simple chatbots skip entirely. It's one of Vinkius' most powerful tools for making sure your ideas are structurally sound before you write a single line of code. ## Tools ### validate_aristotle_logic Runs a full formal logic audit on text, forcing definition of terms, separating essential properties, validating conclusions, identifying purpose, and testing the strongest opposing argument. ## Prompt Examples **Prompt:** ``` We need a scalable platform that is sort of like a hub for all our data. It also does reporting and analytics and additionally handles notifications. Therefore obviously we should build it as a single unified system. ``` **Response:** ``` DEFINITION_VAGUE — 'Platform,' 'scalable,' 'hub' — none of these terms are defined. Aristotle: genus + differentia. What CATEGORY does 'platform' belong to? What DISTINGUISHES it from a database, a service, or an application? 'Sort of like a hub' is not a definition. Additionally: 'it also does X, Y, Z' conflates essential and accidental properties. Is reporting ESSENTIAL (remove it and the system is no longer what it is) or ACCIDENTAL (remove it and the core thing remains)? Define first. Then categorize. ``` **Prompt:** ``` Definition: 'Order tracker' — genus: operational record-keeping system; differentia: tracks the lifecycle of customer requests from intake to delivery, distinguished from inventory systems (which track objects, not processes). Category: essential properties are (1) lifecycle tracking, (2) status transitions, (3) completion verification. Accidental: notification method (email vs. SMS), display format, report scheduling. Syllogism: All lifecycle tracking systems require status transition definitions. Our order tracker is a lifecycle tracking system. Therefore our order tracker requires status transition definitions. Purpose: Final cause (telos): ensure every customer request reaches completion within committed timelines. Material: order data, team assignments, deadline rules. Formal: sequential status pipeline with validation gates. Efficient: triggered by incoming customer request. Counterargument: Strongest counter — 'A spreadsheet achieves the same tracking with less effort.' This attacks the formal cause — is the pipeline structure necessary? Response: at <50 orders/week, a spreadsheet suffices. At our volume (380/week), manual status tracking produces 12% missed deadlines. The pipeline with validation gates reduced missed deadlines to 1.8%. Residual doubt: the 1.8% may reflect team behavior change, not the system itself. ``` **Response:** ``` LOGIC_PROVEN — Aristotelian logic complete. Definition precise: genus (operational record-keeping system) + differentia (lifecycle of customer requests), with boundary (distinguished from inventory systems). Category correct: essential (lifecycle, transitions, verification) separated from accidental (notification method, display format). Syllogism valid: major premise (all lifecycle systems need transitions), minor (our system is a lifecycle system), conclusion necessarily follows. Purpose identified through four causes, telos first (completion within timelines). Counterargument steel-manned (spreadsheet suffices at <50/week), addressed with data (380/week, 12%→1.8%), residual doubt acknowledged. This reasoning survives the Lyceum. ``` **Prompt:** ``` Definition: 'Workflow engine' — a system that automates tasks. Essential: does everything — routing, notifications, reporting, scheduling, approvals. Syllogism: Good organizations need automation. We are a good organization. This proves we need a workflow engine. ``` **Response:** ``` CATEGORY_ERROR — Definition passes partially ('automates tasks' is a start), but the category classification fails. 'Does everything — routing, notifications, reporting, scheduling, approvals' lists 5 properties as essential. Remove notifications — is it still a workflow engine? Yes. Remove reporting — still a workflow engine? Yes. Those are ACCIDENTAL properties. The ESSENTIAL property is task-state-transition management. Additionally, the syllogism is invalid: 'Good organizations need automation' is a vague major premise. What IS 'good'? What IS 'automation'? The conclusion 'this proves we need' does not follow necessarily — it follows ONLY if ALL automation is beneficial in ALL contexts, which is false. ``` ## Capabilities ### undefined undefined ### undefined undefined ### undefined undefined ### undefined undefined ### undefined undefined ## Use Cases ### Redefining a vague product goal. A Product Manager submits: 'We need an efficient data hub that is robust and scalable.' The agent uses the MCP to force definitions for 'hub,' 'robust,' and 'scalable,' immediately revealing if those terms are essential characteristics or just marketing fluff. ### Validating a complex legal argument. A Policy Analyst inputs an article of law claiming A implies B. The MCP checks the syllogism for validity, ensuring that no minor premise was assumed incorrectly and that the conclusion is legally necessary based on the major premises. ### Structuring a core business process. An operations team describes their workflow: 'We collect data, then we report it.' The MCP uses purpose identification to ask what the final goal (telos) of that data pipeline is—is it for compliance? For profit? Knowing the ultimate purpose changes the entire system design. ### Defending a major architectural choice. A development lead proposes using Kafka over RabbitMQ. The MCP forces a counterargument check, making the agent argue the strongest case for RabbitMQ, which instantly reveals any weak assumptions in the original proposal. ## Benefits - Stops vague concepts. Instead of accepting a statement like 'we need a scalable platform,' the tool forces you to define what 'platform' actually means within your specific context using genus + differentia. - Clarifies requirements immediately. It separates truly essential functions from optional additions, so you know exactly what must be built and what can wait until version two. - Guarantees structural integrity for arguments. The tool verifies that if your premises are true, the conclusion *must* follow logically; it catches lazy leaps of faith in reasoning. - Determines the 'why.' It pushes beyond merely describing how a process works (the efficient cause) and forces you to state the ultimate goal or purpose (the telos). - Prepares you for critique. By examining the strongest counterargument, you force your agent to address its weakest point before anyone else does. ## How It Works The bottom line is that it takes vague ideas and forces them into rigid, provable structures. 1. Submit your initial concept or argumentative text to the MCP for structured analysis. 2. The tool runs five distinct checks: defining terms, classifying properties, validating syllogisms, identifying purpose, and challenging assumptions. 3. You receive a detailed verdict showing exactly which logical principles were violated, pinpointing where the thinking needs correction. ## Frequently Asked Questions **How does Aristotle Logic Prover MCP help with vague requirements?** It forces the identification of genus and differentia for every term. Instead of accepting 'scalable,' it asks: what is its category, and what single factor defines it as scalable in your industry? **Can I use validate_aristotle_logic to check my arguments?** Yes, absolutely. You input your premises and conclusion, and the tool checks if the connection is a valid syllogism. It prevents logical gaps from becoming real-world failures. **Does Aristotle Logic Prover MCP just check for facts?** No. It checks *structure*. It focuses on whether the purpose (telos) was correctly identified, which is deeper than simple fact-checking. It asks 'why' over and over again. **What if my argument is sound but complicated?** The tool handles complexity by demanding a counterargument examination. This forces you to proactively address the hardest criticism against your idea, making your final proposal airtight. **How do I set up and connect `validate_aristotle_logic` to my existing AI client?** You simply subscribe to this MCP within Vinkius and select your preferred agent. Your AI client handles the connection; no manual authentication keys are needed. Once connected, you reference the tool name in a natural language prompt, and your agent manages the function call automatically. **What kind of input is best when calling `validate_aristotle_logic`?** The most effective inputs are highly structured. You must provide clear premises for syllogisms and explicitly list key terms requiring definition (genus + differentia). The tool analyzes the relationship between these elements, not just the raw text itself. **If `validate_aristotle_logic` returns a failure verdict like DEFINITION_VAGUE, how do I fix it?** The error code tells you exactly what to fix. If it's DEFINITION_VAGUE, stop and define the unclear terms first. Then, re-run the tool with your expanded definitions included in the prompt context. **Are there limits on document size or complexity for `validate_aristotle_logic`?** The tool handles deep logical analysis, but extremely long documents should be broken down. Focus on one core argument, premise set, and purpose per prompt to ensure the strongest counterargument examination is thorough. **How is this different from the Archimedes First Principles Prover?** Archimedes forces DECOMPOSITION — break the problem into irreducible components. Aristotle forces FORMAL LOGIC — define terms precisely, prove conclusions through valid syllogisms, identify purpose through four causes, and examine counterarguments dialectically. Archimedes asks 'what are the components?' Aristotle asks 'is the argument VALID?' **What are Aristotle's four causes?** Material (what is it made of?), Formal (what is its structure?), Efficient (what process made it?), Final (what is it FOR — the telos). Most people describe only the efficient cause — the mechanism. Aristotle demands the final cause first: why does this thing EXIST? What is its purpose? **Can I use this for product design, not just philosophical arguments?** Yes. Every product decision involves definition (what IS this product — category and differentiator), categorization (which features are essential vs. nice-to-have), logical proof (does the conclusion follow from the premises), purpose (what is this product FOR — not what it does), and dialectic (what is the best argument against building this). Aristotle is not philosophy — it is the operating system of clear thinking.