You can scaffold, validate, and lint CodeIgniter 4 code, and run migrations.
Generate full CRUD resources: controller, service, repository, entity, migration, tests.
Generate individual PHP controllers, services, and repositories.
Validate routes against Routes.php for collisions and CI4 syntax.
Run migrations up/down with explicit confirmation.
Lint PHP files against framework conventions (strict types, naming, no SQL in controllers, etc.).
Generates and maintains idiomatic CodeIgniter framework code, including scaffolding full CRUD resources, controllers, services, repositories, migrations, and route validation.
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., "@codeigniter-mcp Generate a Product resource CRUD with title, price, and description fields."
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.
Model Context Protocol (MCP) server built for high-velocity AI development on CodeIgniter 4 and modern PHP architectures (MVC + Services/Repository layer).
Eliminates LLM hallucinations, scaffolds complete production-ready modules in <15 milliseconds, and unlocks real-time live database and route introspection directly inside your AI IDE (Claude Code, Cursor, Windsurf, Trae, OpenAI Codex, and Google Project Astra).
Most MCP servers are either purely external (blind to running application state) or heavy PHP extensions. codeigniter-mcp uses a Dual-Engine Architecture bridging the best of both worlds:
flowchart TB
subgraph AI["AI Coding Assistant"]
Client["Claude Code / Cursor / Windsurf / Trae / Codex / Astra"]
end
subgraph Outer["Engine 1: Outer Server (Node/TypeScript)"]
MCPNode["codeigniter-mcp (stdio / HTTP)"]
Scaffold["Lightning Scaffolding (<15 ms)\nCRUD, Controllers, Services, Entities"]
Linter["AST Linter & Conventions\nStrict types, PascalCase, Zero-SQL Controllers"]
RouteVal["Route Collision Analyzer\nCI4 placeholders, (:segment), $routes->resource()"]
Migrator["Safe Migration Runner\nExplicit confirmation, interpreted PHP errors"]
end
subgraph Inner["Engine 2: Inner In-App Server (PHP Spark Command)"]
SparkCmd["php spark mcp:serve\n(Generated via scaffold_ci4_mcp_server)"]
LiveDB["Live DB Introspection\nReal tables, columns, nullability, keys"]
SafeQuery["Safe SELECT Query Engine\nCapped row limit, mutation blocking"]
ActiveRoutes["Live Route Reflector\nReads compiled Services::routes()"]
MigStatus["Migration Version Status\nReads active batch history"]
end
Client -->|Local stdio or Streamable HTTP| MCPNode
MCPNode --> Scaffold
MCPNode --> Linter
MCPNode --> RouteVal
MCPNode --> Migrator
MCPNode -.->|Generates app/Commands/McpServer.php| SparkCmd
Client -.->|Direct live introspection| SparkCmd
SparkCmd --> LiveDB
SparkCmd --> SafeQuery
SparkCmd --> ActiveRoutes
SparkCmd --> MigStatusOuter Engine (codeigniter-mcp): Runs in Node/TypeScript over stdio or http. Handles sub-millisecond code scaffolding, static syntax validation, and route collision checks without touching PHP runtime dependencies.
Inner Engine (php spark mcp:serve): Scaffolds a zero-dependency, native CodeIgniter 4 Spark command (app/Commands/McpServer.php) that runs a pure JSON-RPC 2.0 MCP server over stdio for real-time live schema reflection, safe read-only SQL queries, and compiled route inspection.
Related MCP server: MySQL MCP Server
8 Production Tools: Complete CRUD scaffolding, modular controllers, services, repositories, route validation, migration runner, AST convention linter, and native CI4 MCP server generator.
Vibecoding Ready (Zero Hallucinations): The AI assistant never confuses CI3, Laravel, and CI4 syntax. Generates clean BaseController, dependency-injected Services, Query Builder Models, and CSRF-protected forms.
Enterprise-Grade Security:
Symlink Traversal Mitigation: Canonical realpathSync resolution prevents reading or writing outside APP_ROOT.
DNS Rebinding Protection: Enforces strict Host header matching (returns 403 Forbidden).
HTTP API Key Authentication: Supports Authorization: Bearer <key> or X-API-Key headers.
Safe PDO Mutations: Prevents false 404s on unchanged MySQL row updates (rowCount() > 0 || $this->findById($id)).
Destructive Operations Guarded: Requires explicit confirm: true or overwrite: true.
4 Convention Resources + 3 Token-Saving Prompts: Compact prompt templates save token context and speed up LLM responses.
npx (No installation needed)npx -y codeigniter-mcpnpm install -g codeigniter-mcpgit clone https://github.com/AntigamerISK/codeigniter-mcp.git
cd codeigniter-mcp
npm install
npm run build
npm test
npm run verifyAdd to claude_desktop_config.json or run claude mcp add codeigniter-mcp:
{
"mcpServers": {
"codeigniter-mcp": {
"command": "npx",
"args": ["-y", "codeigniter-mcp"],
"env": {
"APP_ROOT": "/absolute/path/to/your/codeigniter4_project",
"RATE_LIMIT_PER_MINUTE": "30"
}
}
}
}In your project root or global settings (.cursor/mcp.json or settings UI):
{
"mcpServers": {
"codeigniter-mcp": {
"command": "npx",
"args": ["-y", "codeigniter-mcp"],
"env": {
"APP_ROOT": "/absolute/path/to/your/codeigniter4_project"
}
}
}
}For cloud agents that connect over HTTP instead of spawning local sub-processes:
# Start server in HTTP mode
MCP_TRANSPORT=http MCP_PORT=3000 MCP_BIND_HOST=127.0.0.1 MCP_API_KEY=secret_token APP_ROOT=/path/to/project npx codeigniter-mcpConfigure your remote AI agent:
{
"mcpServers": {
"codeigniter-mcp": {
"url": "http://127.0.0.1:3000/mcp",
"headers": {
"Authorization": "Bearer secret_token"
}
}
}
}Tool | Purpose | Key Parameters |
| Generates full CRUD in ~15 ms: Controller + Service + Model/Repository + Migration + View + Tests (8 files). |
|
| Generates standalone Controller with strict validation; enforces zero SQL in controllers. |
|
| Generates business logic Service with contract-first DI (injects Model in CI4). |
|
| Generates Repository interface + PDO implementation (no-op in CI4, data lives in Models). |
|
| Analyzes |
|
| Executes native migrations ( |
|
| Lints PHP source code against framework conventions and AST security rules. |
|
| Scaffolds native CI4 in-app MCP command ( |
|
php spark mcp:serve)Once you run scaffold_ci4_mcp_server, your CodeIgniter 4 application gains its own native MCP server:
php spark mcp:serveThis exposes live runtime tools to your AI assistant:
ci4_db_tables: Reflects active database schema, columns, data types, and primary keys.
ci4_db_query: Runs safe, read-only SELECT queries (capped at 50 rows, destructive keywords blocked).
ci4_routes_list: Reads dynamically compiled routes directly from Services::routes().
ci4_migration_status: Queries Services::migrations() for active and pending migration batches.
Compact input templates that minimize token consumption:
Prompt | Description |
| Converts compact definitions (e.g. |
| Prepares migration direction while enforcing safety confirmation. |
| Directs the model to inspect and repair a specific file against framework standards. |
Read-only context injected into the LLM context window:
convention://naming: Rules for PascalCase, camelCase, kebab-case, and mandatory suffixes.
convention://architecture: Explains MVC + Service + Repository separation.
convention://folder-structure: CodeIgniter 4 directory tree mapping.
convention://security-rules: Guidelines for CSRF tokens, PDO parameterized statements, and strict typing.
Variable | Default | Description |
| — | Required. Absolute path to the PHP application root directory. |
|
| Maximum write/scaffold operations permitted per minute per session. |
|
| Communication protocol ( |
|
| Port for Streamable HTTP transport mode. |
|
| Local IP binding to guard against DNS rebinding attacks. |
| — | Optional Bearer token or X-API-Key required for HTTP transport. |
|
| Path or name of the PHP CLI binary to execute. |
# Run complete test suite (165 tests across 17 files)
npm test
# Typecheck with zero warnings
npm run typecheck
# Acceptance checklist against real stdio MCP transport
npm run verifycodeigniter-mcp — acceptance checklist
✅ Handshake: serverInfo.name = codeigniter-mcp
✅ Exposes 8 tools (found 8)
✅ Exposes 4 convention resources (found 4)
✅ Exposes 3 token-saving prompts (found 3)
✅ scaffold_full_resource creates 8 files on disk (7 ms)
✅ php -l passes on all generated files (8 files OK)
✅ lint_against_framework_rules → compliant
✅ validate_route POST /orders → valid
✅ run_migration without confirm → blocked (zero executions)
✅ run_migration with confirm=true executes via bin/migrate
✅ scaffold again → no overwrite, 8 files skipped
✅ Path traversal outside APP_ROOT → ValidationError
✅ Runner failure → actionable MigrationFailedError
Result: 13 passed · 0 failed · 0 skippeddocs/tools.md — Comprehensive parameter references for all 8 tools.
docs/profiles.md — Profiles, auto-detection (ci4 vs spec), and configuration.
docs/security.md — Deep dive into the security architecture and guardrails.
docs/testing.md — Testing strategy, E2E fixtures, and CI automation.
Contributions are welcome! Please read CONTRIBUTING.md before submitting pull requests.
Distributed under the MIT License. See LICENSE for more information.
Validates a PHP file of the project against the framework conventions: strict_types, naming, no queries in controllers, input validation and repositories behind an interface. Returns structured violations; compliant=false when there is any error.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior on its own. It mentions specific checks and the compliant flag, but it does not explicitly state that the tool is read-only or what happens when the file doesn't exist. This is a gap, though the verb 'validates' suggests a non-mutating operation.
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?
The description is two sentences long, front-loading the purpose and immediately listing the checked conventions. It ends with the return behavior, which is essential. No unnecessary words.
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?
For a tool with one parameter and no output schema, the description covers the main purpose and provides some return information ('structured violations', 'compliant=false'). However, it doesn't describe the structure of violations or any failure modes, so it's incomplete but not severely lacking.
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?
The schema only has one parameter, filePath, with a minLength constraint. The description refers to 'a PHP file of the project', which adds context that the path should point to a PHP file, but it does not further elaborate on path requirements or default behavior. Given the simplicity of the parameter, this is adequate.
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?
The description clearly states the tool's purpose: it validates a PHP file against specific framework conventions. The list of conventions (strict_types, naming, no queries in controllers, etc.) distinguishes it from the sibling scaffold and migration tools.
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?
The description implies the tool is for linting existing PHP files, which separates it from the scaffolding tools that generate code. However, it does not explicitly state when to use this versus validate_route or when not to use it, leaving the guidance at an implicit level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Runs framework migrations (up/down) through the project's native migration runner (spec: php bin/migrate; ci4: php spark migrate). DESTRUCTIVE OPERATION: requires an explicit confirm: true. Without that flag nothing is executed.
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | Yes | ||
| direction | Yes | ||
| migrationName | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly warns that the operation is destructive and requires an explicit confirm flag, and notes that nothing executes without it—fully disclosing behavioral implications.
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?
The description is concise, front-loaded with the primary action, and includes necessary warnings and examples in a single well-structured sentence.
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?
Given no output schema and simple parameters, the description provides enough context about the operation, the confirm requirement, and the underlying commands to be complete.
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?
The description explains the 'direction' (up/down) and 'confirm' parameters, but does not explicitly describe the 'migrationName' parameter, though it is implied by 'Runs framework migrations'. Coverage is partial but reasonable.
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?
The description clearly states the tool runs framework migrations (up/down) and specifies the native migration runner for different frameworks, distinguishing it from other scaffold or validation tools.
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?
It effectively communicates when to use this tool (to run migrations) and provides concrete command examples for spec and CI4, leaving no ambiguity about its intended use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generates a PHP Controller for a resource (presentation layer only). The controller only calls the corresponding Service: zero queries and zero inline validation. Does not overwrite existing files unless overwrite=true.
| Name | Required | Description | Default |
|---|---|---|---|
| methods | No | ||
| overwrite | No | ||
| resourceName | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses key behavior: generates a controller with zero queries and zero inline validation, and overwrite behavior. However, it does not state what happens when a file exists and overwrite=false (error, skip, etc.), which is a minor gap.
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?
Two sentences, front-loaded with the main action and scope. Every sentence adds value: the first clarifies purpose and constraints, the second handles overwrite behavior. No wasted words.
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?
The description is sufficient for a simple scaffolding tool with no output schema. It covers what the generated controller does, its scope, and overwrite behavior. It lacks details on file destination or naming conventions, but the presence of sibling tools and resourceName helps infer context.
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?
Schema description coverage is 0%, so the description must compensate. It adds meaning to `overwrite` (does not overwrite unless true) but not to `methods` or `resourceName`. The schema's enums and pattern provide some self-describing structure, but the description doesn't explain how methods map to generated code or validate naming conventions.
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?
The description clearly states it 'Generates a PHP Controller for a resource' with the scope 'presentation layer only', which is a specific verb+resource. It distinguishes from sibling scaffolds by emphasizing the controller only calls the corresponding Service, with zero queries and zero inline validation.
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?
The description provides clear context: it is for presentation layer controllers that delegate solely to services. It implies the tool is not for creating full resource stacks or services/repositories, but does not explicitly name alternatives or exclusion criteria, so a slight deduction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generates the full CRUD of a PHP resource: Controller, Service, Repository (interface + implementation), Entity, Migration and tests (unit & integration). Requires overwrite=true to overwrite existing files.
| Name | Required | Description | Default |
|---|---|---|---|
| fields | Yes | ||
| overwrite | No | ||
| withTests | No | ||
| resourceName | Yes | ||
| withRepository | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that it can overwrite existing files only when overwrite=true, and enumerates the exact files generated. It does not mention prerequisites or failure modes, but the core mutation behavior is clear.
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?
The description is two sentences and front-loads the tool's purpose and key constraint. Every phrase contributes information, making it compact and efficient.
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?
The tool is complex, generating multiple file types, yet the description omits details on field specification and naming conventions, which are only partially covered by the schema. It also lacks any mention of return values or post-generation steps, making it adequate but not complete.
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?
The schema defines 5 parameters, but the description only explains the overwrite parameter's requirement. It does not add meaning for resourceName, fields, withTests, or withRepository, leaving their syntax and semantics to the schema alone.
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?
The description uses a specific verb 'generates' and identifies the resource as a full CRUD scaffold, enumerating concrete components (Controller, Service, Repository, Entity, Migration, tests). This clearly distinguishes it from sibling tools that scaffold individual components.
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?
The description states it generates the full CRUD of a PHP resource, implying use when a complete scaffold is needed. However, it does not explicitly contrast with sibling scaffold_* tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generates the Repository of a resource: ALWAYS the interface (contract) and the implementation (PDO adapter with prepared statements) together. Does not overwrite existing files unless overwrite=true.
| Name | Required | Description | Default |
|---|---|---|---|
| fields | Yes | ||
| overwrite | No | ||
| resourceName | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It reveals key behaviors: generates both interface and implementation, uses PDO adapter with prepared statements, and respects overwrite=true for existing files. It stops short of covering error handling, directory creation, or file naming conventions, so it is not fully exhaustive but is well above minimal.
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?
The description is two sentences, front-loaded with the primary purpose followed by the critical overwrite caveat. Every clause adds necessary information, with no filler or redundancy.
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?
For a code-generation tool with no output schema and no annotations, the description covers the essential high-level behavior and overwrite flag. It does not describe what methods the generated repository will contain, naming conventions, or runtime requirements, leaving open questions for an agent trying to predict the full effect of the tool.
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?
The schema provides no descriptions (0% coverage), so the description must compensate. It explicitly clarifies the `overwrite` parameter ('Does not overwrite existing files unless overwrite=true') and references 'resource' for resourceName. However, it does not explain `fields`, which is a required array of objects with name/type pairs, nor how these fields influence the generated repository—leaving a significant interpretation gap.
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?
The description clearly defines the tool's purpose: 'Generates the Repository of a resource' and specifies the exact outputs—'ALWAYS the interface (contract) and the implementation (PDO adapter with prepared statements) together.' This distinguishes it from sibling tools like scaffold_controller and scaffold_service by naming the specific resource layer and mandatory paired artifacts.
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?
The description implies usage when a repository for a resource is needed, and the 'ALWAYS ... together' phrasing sets expectations for output scope. However, it does not explicitly mention when to prefer this over sibling tools like scaffold_full_resource or scaffold_controller, nor does it state exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generates a PHP Service for a resource (business logic + input validation). Receives the Repository through dependency injection via interface (contract first). Does not overwrite existing files unless overwrite=true.
| Name | Required | Description | Default |
|---|---|---|---|
| overwrite | No | ||
| resourceName | Yes | ||
| withRepository | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses a key safety behavior: does not overwrite existing files unless overwrite=true, and mentions the contract-first DI approach. However, it does not mention other potential side effects like file location creation or autoloading updates.
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?
The description is two sentences, front-loads the primary purpose, and includes only necessary behavioral notes. No redundant or vague wording.
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?
For a scaffolding tool with three parameters and no output schema, the description provides the core purpose, a key safety behavior, and architectural context (DI via interface). It could be more complete by covering what withRepository does and where files are placed, but it is sufficiently complete for typical selection.
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?
The description explicitly explains the overwrite parameter's effect, and resourceName is inferable from the purpose. However, withRepository is not explained at all, and schema coverage is 0%, so the description only partially compensates for the missing parameter semantics.
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?
The description clearly states the tool generates a PHP Service for a resource, including business logic and input validation. It is specific enough to distinguish from controller/repository generation, though it does not explicitly name sibling alternatives like scaffold_controller or scaffold_full_resource.
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?
The context implies this is for generating services that receive a repository via dependency injection, but there is no explicit guidance on when to use this versus alternatives such as scaffold_repository or scaffold_full_resource. Exclusions or alternative tool references are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verifies (read-only) that a route does not collide with the routes registered in app/Config/Routes.php and follows the framework's kebab-case {param} syntax. Never modifies files.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| method | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and clearly discloses read-only behavior and 'Never modifies files.' It adds specific context about what is validated (collisions and syntax). However, it does not disclose output format or error behavior on collision, which prevents a higher score.
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?
The description is two sentences, front-loaded with the core action and includes essential safety information. Every word adds value; there is no redundancy or fluff.
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?
The description covers purpose and side effects adequately for a simple validation tool, but lacks clarity on what the tool returns (e.g., boolean, error message) and does not elaborate on parameter semantics. Given no output schema and no annotations, this is a notable gap, though the core function is clear.
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?
Schema description coverage is 0% and the description provides no guidance on the 'method' or 'path' parameters. It does not add meaning beyond the schema's enum/pattern, leaving the agent to infer semantics entirely from property names and schema constraints.
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?
The description states a specific action (verifies) and resource (route against Routes.php), and clearly defines scope (collision check and kebab-case syntax). It distinguishes from sibling scaffolding/migration tools by being a read-only validation tool.
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?
The description implies usage as a pre-registration validation step but does not explicitly state when to use it or mention alternatives. It provides no exclusions or comparison with sibling tools, leaving usage context implicit rather than explicit.
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.
v0.1.0lint_against_framework_rulesrun_migrationscaffold_controllerscaffold_full_resourcescaffold_repositoryscaffold_servicevalidate_routeScored across 7 tools
Each tool targets a clearly distinct action: layer-specific scaffolds, full resource scaffolding, route validation, migration execution, and linting. The full resource tool is explicitly named and described as a superset, so there is little risk of misselection.
All tools follow a consistent verb-first snake_case pattern: scaffold_*, validate_route, run_migration, lint_against_framework_rules. The naming conventions are uniform and predictable.
Seven tools is well-scoped for a CodeIgniter scaffolding and validation server. Each tool earns its place and the set is neither bloated nor thin.
The server covers the main resource scaffolding workflow, routing validation, migrations, and framework linting. Minor gaps exist such as no standalone entity/migration/test generator outside the full resource scaffold, but common workflows can be completed without dead ends.
327 dev tools via REST API and MCP. Generate Dockerfiles, schemas, K8s, APIs, and more.
The Mercado Pago MCP Server implements the Model Context Protocol to provide AI agents and LLMs with access to Mercado Pago's APIs and tools within compatible development environments. It acts as an intermediary that translates Mercado Pago resources into executable functions (tools) that AI applications can invoke to perform actions and automate flows. The server simplifies integration, enables using documentation to implement or improve code, and optimizes operations through natural language interactions without manual implementations.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
A Model Context Protocol (MCP) application for automated GitHub PR analysis and issue management.…
