The server provides tools to generate, validate, and maintain a CodeIgniter-inspired PHP framework with MVC + Service/Repository architecture, running as an MCP server.
Scaffold complete CRUD resources: Generate Controller, Service, Repository (interface + implementation), Entity, Migration, and tests in one call.
Generate individual layers: Create Controllers, Services, or Repositories (always with interface) independently.
Validate routes: Check Routes.php for exact/pattern collisions and syntax errors without modifying files.
Run database migrations: Execute up/down migrations with explicit confirmation required for destructive operations.
Lint against framework conventions: Validate PHP files for strict types, naming, no queries in controllers, input validation, and repository interfaces.
Access framework documentation: Provide naming, architecture, folder structure, and security rules via MCP resources.
Security & safety: Enforce path traversal protection, Zod input validation, rate limiting, overwrite prevention, and sanitized errors.
Deployment: Support local (stdio) and remote (HTTP) transports, integrable with LLM clients like Claude Code, Cursor, and VS Code.
Generates and maintains idiomatic CodeIgniter framework code, including scaffolding full CRUD resources, controllers, services, repositories, migrations, and route validation.
Click on "Install 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.
MCP (Model Context Protocol) server that accelerates development of a PHP framework inspired by CodeIgniter: MVC + optional Services/Repository layer (lightweight Ports/Adapters), with native CodeIgniter 4 support (auto- detected from the project structure). Extreme development speed without sacrificing security.
Version:
0.5.0— Semantic versioning: any input/output schema change breaks compatibility and must be versioned explicitly.
7 tools + 4 resources + 3 token-saving prompts for an LLM (Claude Code, Cursor, VS Code, Trae) to scaffold, validate and maintain idiomatic framework code without hallucinating structure.
CodeIgniter 4 native — BaseController + Model (Query Builder) + forge
migrations + views; auto-detected, zero config needed.
Hard security by default: Zod input validation, path-traversal
protection, explicit confirm/overwrite for destructive ops, rate
limiting, prepared statements, no credential leaks.
Related MCP server: MySQL MCP Server
npx -y codeigniter-mcp # run directly over stdio (published package)
npm install -g codeigniter-mcp # or install globallyFrom source (contributors): npm install && npm run build && npm test.
The server reads environment variables (see mcp.json):
Variable | Default | Description |
| — | Required. Absolute path to the target PHP framework root. All tools operate only inside this directory. |
|
| Write operations allowed per minute per session. |
|
|
|
|
| HTTP transport port. |
mcp.json (Claude Code / Cursor / Trae):
{
"mcpServers": {
"codeigniter-mcp": {
"command": "npx",
"args": ["-y", "codeigniter-mcp"],
"env": {
"APP_ROOT": "/path/to/mi-framework",
"RATE_LIMIT_PER_MINUTE": "20"
}
}
}
}Project profiles (.codeigniter-mcp.json — optional): an explicit file
always wins; without it the profile is auto-detected from the project
structure (app/Config/Paths.php or spark → ci4; bin/migrate or
app/Repositories → spec; unknown → spec). See
docs/profiles.md.
Tool | What it does |
| Full CRUD: Controller + Service + Repository (interface+impl) + Entity + Migration + tests (8 files, ~15 ms) |
| Controller only; zero SQL allowed (build-time check) |
| Service: business logic + validation, contract-first DI (ci4: Service that injects the Model) |
| Repository interface + PDO implementation, always together (ci4: no-op, Models handle data) |
| Read-only route collision detection against |
| Runs the native migration runner (spec: |
| Lints PHP files against the profile conventions |
Token-saving templates: compact input → exact tool arguments.
Prompt | What it does |
|
|
|
|
|
|
URI | Content |
| PascalCase / camelCase / kebab-case, mandatory suffixes |
| MVC + Service + Repository (lightweight Ports/Adapters) |
| Framework folder tree |
| Hard security rules of the tools |
docs/tools.md — full tool specs, inputs/outputs and examples
docs/profiles.md — profiles, .codeigniter-mcp.json, auto-detection, generated contract
docs/security.md — security model in detail
docs/testing.md — tests, npm run verify, local development, end-to-end example
ci3 profile — CodeIgniter 3 (legacy) support behind the same
.codeigniter-mcp.json / auto-detection mechanism (CI3 is still active on a
large legacy base but is EOL: no security patches).
Recipe prompts — high-level feature templates (auth, file uploads, REST CRUD) that chain the existing tools.
Contributions are welcome! Read CONTRIBUTING.md to set up the development environment, run the tests and open a pull request. Security issues should be reported privately — see SECURITY.md. Release history is tracked in CHANGELOG.md.
MIT © 2026 X-Gunner
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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.…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/X-Gunner/codeigniter-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
