codeigniter-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.5.0
Disambiguation5/5
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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 4/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 21 commits in the last 12 weeks
- Last stable release on August 13, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![codeigniter-mcp MCP server](https://glama.ai/mcp/servers/X-Gunner/codeigniter-mcp/badges/card.svg)](https://glama.ai/mcp/servers/X-Gunner/codeigniter-mcp)

Score Badge

Copy to your README.md:

[![codeigniter-mcp MCP server](https://glama.ai/mcp/servers/X-Gunner/codeigniter-mcp/badges/score.svg)](https://glama.ai/mcp/servers/X-Gunner/codeigniter-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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