# MCPFusion Developer Prover MCP

> MCPFusion Developer Prover validates your MCP Fusion server against strict architectural standards. It forces your AI client to prove deep understanding of Model-View-Agent (MVA) layering, correctly defining models with `defineModel()`, attaching Presenters for data validation, and using the right semantic verbs (`f.query`/`f.mutation`). Stop building servers that violate core principles—use this to enforce structural integrity.

## Overview
- **Category:** productivity
- **Price:** Free
- **Tags:** mcpfusion, mva-architecture, mcp-server, structured-reasoning, decision-pivots, definemodel, presenter, agentic-pipeline

## Description

You're writing MCPFusion servers, right? You know how easy it is for an agent—even a smart one—to build something that *looks* like it works but violates fundamental architecture. This server fixes that. The `validate_mcpfusion_implementation` tool forces your AI client to prove deep understanding of Model-View-Agent (MVA) layering, running a deep check across your code for strict adherence to core principles.

It doesn't just sniff out basic errors; it validates the entire structural intent. You use this when you need guaranteed architectural integrity, ensuring that what gets built is actually usable in production.

The tool enforces Model Definition by requiring all entities to use `defineModel()` with explicit casts, guaranteeing that fields like hidden status or timestamps are correctly managed across your system. It ensures proper data flow validation (Presenters) because any tool returning data must pass through a Presenter; this validates the output, strips unnecessary internal fields, and applies egress rules before anything leaves the server.

It maintains architectural separation by verifying that your code sticks to a strict Model-View-Agent (MVA) file structure, preventing cross-layer dependencies and keeping imports clean. When handling inputs, it manages input schemas by requiring tool arguments to use specific methods like `.withString()` or `.fromModel()`, so you're not relying on raw Zod definitions.

The system forces correct API intent typing by ensuring the agent uses semantic verbs accurately: `f.query()` for non-destructive data reading, and `f.mutation()` for destructive data writing. This rigorous checking prevents agents from misinterpreting side effects when they call your tools.

## Tools

### validate_mcpfusion_implementation
Runs a deep check across your code to verify adherence to MVA principles, ensuring correct model definitions, Presenter use, and semantic verb usage.

## Prompt Examples

**Prompt:** 
```
I'll create a task MCP with z.object({ title: z.string(), status: z.enum(['open','done']) }) in the tool file and return JSON.stringify(result) from the handler.
```

**Response:** 
```
Verdict: RAW_SCHEMA_DETECTED. Use defineModel('Task', m => { m.casts({ title: m.string(), status: m.enum('Status', ['open','done']) }) }) in models/. Create TaskPresenter in views/. Tool uses .returns(TaskPresenter). Handler returns raw data — Presenter handles the rest.
```

**Prompt:** 
```
TaskModel in models/ with m.casts(title, status, assignee). TaskPresenter in views/ with .schema(TaskModel) and agentLimit(50). f.query('tasks.list') with .returns(TaskPresenter). f.mutation('tasks.create') with .fromModel(TaskModel,'create'). server.ts with registry.register().
```

**Response:** 
```
Verdict: IMPLEMENTATION_PROVEN. MVA correct (Model→Presenter→Tool). defineModel() for Task entity. Presenter with agentLimit. Semantic verbs match (query=list, mutation=create). File structure separated. Ship it.
```

**Prompt:** 
```
I'll use f.mutation('logs.search') to search logs since it queries the database, and wrap the result with return success(data) in the handler.
```

**Response:** 
```
Verdict: SEMANTIC_VERB_WRONG. Search is a READ — use f.query('logs.search'), not f.mutation(). mutation=destructive (create/delete). Also: .handle() auto-wraps with success() — remove the manual success() call, just return data.
```

## Capabilities

### Enforce Model Definition
Requires all entities to use `defineModel()` with explicit casts, ensuring fields like hidden status or timestamps are correctly managed.

### Validate Data Flow (Presenters)
Guarantees that any tool returning data must pass through a Presenter. This validates the output, strips unnecessary internal fields, and applies egress rules.

### Correct API Intent Typing
Forces the agent to use semantic verbs correctly: `f.query()` for reading data (non-destructive), `f.mutation()` for writing data (destructive).

### Manage Input Schemas
Ensures tool inputs are typed using specific methods (`.withString()`, `.fromModel()`) instead of relying on raw Zod schemas.

### Maintain Architectural Separation
Validates that the code adheres to a strict Model-View-Agent (MVA) file structure, preventing cross-layer dependencies and ensuring clean imports.

## Use Cases

### The Agent Writes Bad Code
An agent writes a new endpoint for 'user profile lookup' using raw `z.object()` and forgets to attach a Presenter. The resulting MCP server works locally but fails in production because it leaks internal IDs or doesn't validate the user status field correctly. Running `validate_mcpfusion_implementation` catches this immediately, forcing the developer to use `defineModel()` first.

### The Developer Mixes Up Verbs
A developer needs a simple log search function and mistakenly uses `f.mutation('logs.search')`. The tool runs, flags the violation: 'Search is READ — use f.query(), not f.mutation()'. This stops the destructive API call before it ever hits the database, saving potential data corruption.

### The Server Overflows Data
A module returns a list of records but includes internal metadata fields (like `__internal_id` or `is_draft`). Without Presenters, this data gets sent to the client. The tool forces the use of `.returns(TaskPresenter)`, ensuring only clean, validated fields are exposed.

### Building a Complex Workflow
You're building an agent that reads user records and then updates them. You must ensure data flows correctly: Model (definition) → Presenter (validation/cleanup) → Tool (execution). The Prover guides you through this exact sequence, confirming every step adheres to the MVA pattern.

## Benefits

- **Guaranteed Data Integrity:** Never rely on raw Zod schemas again. `defineModel()` handles hidden fields, timestamps, and casting automatically, giving you a single source of truth for your data structure.
- **Predictable Output Flow:** By forcing the use of Presenters (via `.returns(Presenter)`), you ensure that data leaving the server is validated against business rules, not just raw database dumps. No more unexpected fields in production.
- **Clear Intent Signaling:** The tool forces semantic verbs (`f.query()` vs `f.mutation()`), making it impossible for your agent to accidentally treat a read operation as a destructive write—a massive reliability win.
- **Structured Codebase Discipline:** It enforces the Model→Presenter→Tool layering, ensuring clean imports and separation of concerns across your entire server architecture.
- **Accelerated Debugging Cycle:** Instead of chasing runtime errors related to schema violations or missing validation layers, you get a definitive report pointing out exactly which MVA principle was broken.

## How It Works

The bottom line is that this tool enforces architectural discipline, turning fuzzy LLM outputs into reliable, production-grade MCP servers.

1. Define your core data structures using `defineModel()` in the `models/` directory. This establishes the canonical source for field types and business logic.
2. Write tools using semantic verbs (`f.query`, `f.mutation`). Attach a Presenter to every tool that returns data, ensuring validation happens before the response leaves the server.
3. Run the `validate_mcpfusion_implementation` check. The output will pinpoint any violation—whether it's a raw schema or wrong verb usage—allowing you to fix and resubmit until all checks pass.

## Frequently Asked Questions

**Does validate_mcpfusion_implementation check my database connection?**
No, it doesn't test connectivity. It checks the *code structure* to ensure you are calling your data layer using the correct MCPFusion methods and following MVA architectural rules.

**Do I have to use Presenters for every tool?**
Yes, if a tool returns data (i.e., it reads or creates records), you must attach a Presenter using `.returns(Presenter)`. This is how the server validates and cleans up your output.

**What should I use for reading data? Is validate_mcpfusion_implementation clear?**
You must use `f.query()` for all read operations, even if they are complex searches. The Prover strictly enforces that `f.query()` is reserved only for non-destructive reads.

**Is this necessary if I'm just calling a simple external API?**
This tool assumes you are building the API *within* the MCPFusion framework. If your server logic involves creating or reading data through defined models, running `validate_mcpfusion_implementation` is mandatory.

**How does validate_mcpfusion_implementation guide me through complex error scenarios?**
It validates the use of `f.error()` for structured failure handling. You must implement self-healing logic using `.suggest()`, `.actions()`, and `.retryAfter()` when your tool fails. This keeps the agent loop running smoothly instead of failing hard.

**What's the key difference between raw z.object() and defineModel() according to validate_mcpfusion_implementation?**
Raw schemas bypass critical metadata like hidden fields, fillable profiles, and timestamps. You must use `defineModel()` because it automatically strips unnecessary data, injects lifecycle rules, and resolves API aliases for you.

**Does validate_mcpfusion_implementation help manage rate limits or performance?**
It doesn't enforce external rate limiting, but the architecture promotes efficient usage. By forcing Model→Presenter→Tool layering, you minimize unnecessary payload size and ensure proper data validation before any action is taken.

**When designing inputs for a tool using validate_mcpfusion_implementation, how do I handle optional, structured parameters?**
You use specific input wrappers like `.withOptionalStrings({...})` or `.fromModel(Model, "update")`. Never rely on raw z.object() definitions; these specialized methods ensure type safety and correct parameter handling within the framework.

**Does this generate MCP server code?**
No. The agent writes the code. This tool VALIDATES that the code follows MCPFusion's MVA architecture — defineModel() for entities, Presenters for egress, semantic verbs for operations, and correct file structure. It teaches the framework through rejection messages.

**Why does the LLM need this if it can read documentation?**
Documentation reading is one-shot — the LLM reads once and forgets. This tool forces structured reflection on EVERY tool being built. Each field is a micro-lesson: modelStrategy forces naming m.casts() fields, presenterStrategy forces explaining .returns(), toolDesign forces choosing the right semantic verb. Repetition through obligation, not suggestion.

**What if my MCP doesn't return data (reasoning-only)?**
Reasoning MCPs still use MVA. The Model defines the verdict/message shape. The Presenter renders the verdict. The tool forces structured input. Even a tool that computes nothing needs defineModel() for its response and a Presenter for its output. The same architecture applies — the Presenter is the egress contract.