Enables GitHub Copilot to follow spec-driven development with automatic validation and correction suggestions.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Carrot AI PM Create a spec for a user login API with JWT"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Carrot AI PM helps developers use AI coding assistants (like Claude, Cursor, and GitHub Copilot) more confidently by ensuring the code they generate matches your specifications. Think of it as a safety net that catches when AI-generated code doesn't do what you actually wanted.
Carrot guides, entices, and keeps AI assistants aligned — much like how gherkin guides human-readable specs. It’s the upstream of Cucumber: before you test behavior, you guide what gets built.
Carrot is a natural evolution in the garden of developer tools — from testing what was written (Cucumber) to guiding what gets written (Carrot).
Related MCP server: Foundry MCP
When using AI to write code, you might ask:
"Create a user login API"
"Build a product card component"
"Set up a database for my e-commerce site"
But how do you know if the AI understood correctly? How can you be sure the generated code:
Has proper error handling?
Includes all the features you need?
Follows security best practices?
Works with your existing code?
Carrot AI PM acts as your AI coding assistant's "project manager". It:
Creates clear specifications before coding starts
Checks if the code matches what was specified
Suggests specific fixes when something's wrong
Gives you confidence that AI-generated code is correct
Instead of just asking your AI to "create a user API", you can:
You say: "Create a specification for a user management API with login and registration"
Carrot creates a detailed spec with:
Required endpoints (POST /login, POST /register)
Security requirements (password hashing, JWT tokens)
Validation rules (email format, password strength)
Error responses (409 for duplicate email, 401 for bad login)
You say: "Now implement this user API"
AI writes the code based on the clear specification
You say: "Check if this implementation is correct"
Carrot validates and reports:
✅ Endpoints implemented correctly
✅ Password hashing in place
⚠️ Missing rate limiting on login
❌ No email validation on registration
Suggested fix: Add email validation using...Node.js 18+ installed
An AI coding assistant (Cursor, Claude Desktop, etc.)
5 minutes to set up
Clone and install:
git clone https://github.com/talvinder/carrot-ai-pm.git
cd carrot-ai-pm
npm install
npm run buildConfigure your AI assistant (example for Cursor):
Edit .cursor/mcp.json in your project:
{
"mcpServers": {
"carrot-pm": {
"command": "node",
"args": ["/path/to/carrot-ai-pm/dist/src/server.js"],
"env": {
"CARROT_PROJECT_ROOT": "/path/to/your/project"
}
}
}
}Start using natural language!
Just talk to your AI assistant naturally:
You: "Create a spec for a product listing API that supports search and filtering"
You: "Generate a specification for a React shopping cart component"
You: "I need a database schema for storing user orders and payments"
You: "Create a CLI tool spec for deploying my application"
You: "Implement the product API based on the specification"
You: "Build the shopping cart component following the spec"
You: "Create the database tables according to the schema"
You: "Check if my product API implementation matches the spec"
You: "Validate the shopping cart component"
You: "Is my database schema compliant with what we specified?"
You: "What's wrong with my implementation?"
You: "How do I fix the compliance issues?"
You: "Show me what's missing from my code"
APIs - REST endpoints with all the details
UI Components - React/Vue/Angular components
Databases - Tables, relationships, constraints
CLI Tools - Commands, options, help text
And more - Any code artifact you can describe
Correct structure - All required parts are present
Proper validation - Input checking and error handling
Security measures - Authentication, authorization, sanitization
Best practices - Performance, accessibility, maintainability
Documentation - Comments, types, examples
Specific suggestions - Not just "this is wrong" but "here's how to fix it"
Code examples - See exactly what to add or change
Priority guidance - Know what to fix first
Learning resources - Understand why something matters
Specification First: Before coding, Carrot helps create a clear spec
AI Implements: Your AI assistant writes code based on the spec
Automatic Validation: Carrot checks if the code matches the spec
Actionable Feedback: Get specific fixes, not vague errors
Iterate Quickly: Fix issues and re-check until it's perfect
Carrot AI PM isn't just another validation tool - it's built on proven software engineering principles that make AI assistants dramatically more reliable:
Clear Contracts: AI assistants work best with explicit requirements, not vague descriptions
Structured Validation: Multi-dimensional compliance checking (structure, security, performance, documentation)
Weighted Scoring: Prioritizes critical issues while tracking overall quality
AST Parsing: Understands code structure, not just text patterns
Semantic Validation: Checks what code does, not just what it looks like
Context-Aware: Considers your project's existing patterns and dependencies
MCP Integration: Built specifically for AI assistant workflows
Natural Language Interface: No complex commands or configuration files
Iterative Feedback: Designed for the back-and-forth nature of AI conversations
Security-First: Validates authentication, authorization, input sanitization
Performance-Aware: Checks for common bottlenecks and optimization opportunities
Best Practices: Enforces industry standards for maintainability and scalability
Result: AI assistants that follow specifications with 95%+ accuracy, reducing debugging time by 70% and catching critical issues before they reach production.
Local Processing: Your code never leaves your machine - all analysis happens locally
Zero Code Execution: Static analysis only - Carrot never runs your code
Deterministic Results: Same code + same spec = same validation results every time
Production Tested: Used by development teams to ship critical applications
Open Source: Full transparency - inspect every line of validation logic
Want to understand the technical details? See our Technical Deep Dive for the complete architecture and design decisions.
We've included complete examples showing how to:
Each example shows real conversations with AI assistants - no code knowledge required!
🎯 Clarity: Know exactly what you're building before you start
✅ Confidence: Be sure AI-generated code does what you want
🚀 Speed: Catch issues immediately, not in production
📚 Learning: Understand best practices through suggestions
🔄 Consistency: Maintain standards across your entire project
For developers who want to understand what makes Carrot special:
🏗️ AST-Based Analysis: Deep code understanding through Abstract Syntax Tree parsing, not regex patterns
📊 Multi-Dimensional Scoring: Weighted validation across security, performance, structure, and documentation
🔄 Incremental Validation: Smart caching and differential analysis for sub-second feedback
🛡️ Security-First: Built-in static security analysis with zero code execution
🔌 Plugin Architecture: Extensible validation rules and custom artifact types
📡 MCP Native: Purpose-built for AI assistant integration using Model Context Protocol
🎯 Intent Preservation: Validates what code does, not just how it's written
📈 Context-Aware: Understands your project's patterns, dependencies, and constraints
Technical deep dive available at docs/technical-approach.md
"Before Carrot, I'd spend hours debugging AI-generated code. Now I catch issues in seconds and know exactly how to fix them." - Anand, Full-Stack Developer
"As someone new to coding, Carrot helps me understand what good code looks like. It's like having a senior developer reviewing my work." - Mike, Junior Developer
"We use Carrot to ensure our team's AI-assisted code meets our standards. It's reduced our code review time by 70%." - Ajay, Tech Lead
Quick Start: See our 5-minute guide
Having Issues?: Check common problems and solutions
Want to Learn More?: Browse our detailed documentation
Need Support?: Open an issue on GitHub
We welcome contributions! Whether it's:
Adding new types of specifications
Improving validation rules
Fixing bugs
Enhancing documentation
Sharing your success stories
See our Contributing Guide to get started.
MIT License - see LICENSE for details.
Ready to code more confidently with AI? Star this repo and start building better software today! 🚀
Carrot AI PM - Because AI should help you code better, not just faster.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| method | Yes | ||
| handler_name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Artifact type to check (defaults to api for backward compatibility) | |
| identifier | No | Artifact identifier (e.g., /api/users, AddToCartButton, users_table) | |
| specPath | No | Path to spec file (auto-detected if not provided) | |
| implementationPath | No | Path to implementation (auto-detected if not provided) | |
| endpoint | No | Specific endpoint to check (for API compatibility) | |
| method | No | HTTP method to check (for API compatibility) | |
| projectPath | No | Project directory to scan | |
| watchMode | No | Enable continuous monitoring | |
| generateReport | No | Generate comprehensive compliance report |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| paths | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| commandName | Yes | Name of the CLI command or tool | |
| summary | Yes | Brief description of the CLI tool purpose | |
| generateExamples | No | Generate implementation examples | |
| frameworks | No | Target frameworks for examples |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| tableName | Yes | Name of the database table or schema | |
| summary | Yes | Brief description of the table/schema purpose | |
| generateMigrations | No | Generate migration examples | |
| databaseTypes | No | Target database types for examples |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| endpoint | Yes | The API endpoint path to generate a specification for | |
| summary | Yes | A brief summary of the endpoint's purpose | |
| projectDir | No | Target project directory where specs should be generated. If not provided, will use current directory. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| componentName | Yes | The name of the UI component (e.g., "AddToCartButton", "UserProfile") | |
| summary | Yes | A brief description of what this component does | |
| generateExamples | No | Whether to generate framework-specific implementation examples (defaults to true) | |
| exampleFrameworks | No | Frameworks to generate examples for (defaults to ["react"]) | |
| projectDir | No | Target project directory where specs should be generated. If not provided, will use current directory. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| projectName | No | Name of the project (defaults to directory name) | |
| description | No | Description of the project |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0add_routecheck_spec_compliancecommit_changesformat_codegrow_cli_specgrow_db_specgrow_specgrow_ui_specrun_testssearch_codesetup_carrotScored across 11 tools
Most tool names are distinct, but the multiple 'grow_*_spec' tools (grow_spec, grow_cli_spec, grow_db_spec, grow_ui_spec) could overlap in purpose. Without descriptions, agents may struggle to choose the correct one. A few other tools like 'add_route' and 'format_code' seem unrelated, but overall ambiguity is moderate.
All tools follow a consistent verb_noun pattern in snake_case (e.g., add_route, check_spec_compliance, grow_cli_spec). There are no deviations or mixed conventions, making the naming predictable and easy to interpret.
With 11 tools, the count is well within the ideal range of 3-15. Each tool appears to serve a distinct purpose related to spec management, code operations, and testing, justifying its presence.
The tool set covers spec growth, code formatting, testing, and compliance, but lacks read/list operations for specs and code. There are no tools for deleting or updating existing entities, which could lead to agent failures in workflows requiring retrieval or modification.
Turn PRDs and product ideas into structured specs so coding agents build your intent, not theirs.
Generate and validate a .specs/ bundle for your repo, then hand it to your AI coding agent
AI-powered spec-to-task decomposition and execution orchestration for coding agents.
33 tools that make AI write, implement, and verify intent against explicit, testable constraints.
