Provides read-only introspection of a Laravel application, including routes, migrations, models, jobs, config values, and composer dependencies, with structural guarantees against mutation, secret disclosure, and path escape.
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., "@mcp-artisan what jobs run on the payments queue?"
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.
Point an AI agent at a Laravel codebase and ask it to explain the routes, the
data model, the queued jobs, or a config value — without giving it any way to
change the code, run a console command, or read a secret. mcp-artisan is a
Model Context Protocol server that exposes a Laravel project to an agent
read-only. The interesting part is not the list of things it can report; it
is that the things it cannot do are enforced structurally, not by convention.
The server runs over stdio, speaks MCP, and needs no framework installed and no LLM API key. It works against a project whether or not PHP is present on the machine.
An agent is genuinely useful on a large PHP application: "which routes are
unauthenticated?", "what does the orders table look like?", "which jobs run on
the payments queue?". But the moment you hand a general-purpose agent a shell
and a project directory to answer those questions, you have also handed it the
ability to run php artisan migrate:fresh, read .env, or edit a controller.
On a production or legacy codebase that trade is unacceptable, so the questions
go unanswered or a human does the archaeology by hand.
The useful shape is a tool that can only look. mcp-artisan gives an agent a
faithful, bounded map of the application and makes mutation impossible by
construction — there is no write path and no arbitrary-command path to abuse.
Related MCP server: Context MCP
The assumed adversary is the agent itself: a capable, possibly-confused, or prompt-injected LLM that will call any tool it is offered with any argument it can construct. The design goal is that no sequence of tool calls can change the project, exfiltrate a secret, or read a file outside the project root.
What that means in practice, and where each guarantee lives:
No mutation. The server exposes no tool that writes. The static backend
only ever opens files for reading; the artisan backend only ever runs verbs
from a frozen allowlist (route:list, migrate:status, about), all of
which are read-only. The allowlist is checked before a subprocess is
created (mcp_artisan/artisan_backend.py), so a request for migrate or
tinker never reaches php.
No arbitrary commands. Artisan verbs are constants in the code, never built from tool input. The subprocess is invoked with a fixed argument vector (no shell), so there is nothing to inject into, and each call has a hard wall-clock timeout.
No secret disclosure. .env is never read. Config values come from
config/*.php, and every value is passed through key-based redaction
(mcp_artisan/redaction.py): a key matching password, secret, token,
key, dsn, and similar returns <redacted>, including nested keys inside a
returned subtree. Redaction is deliberately broad — it prefers hiding a
harmless value to leaking a credential.
No path escape. Every filesystem read is funnelled through one
containment check (mcp_artisan/paths.py) that resolves the real path and
rejects anything outside the configured project root, including via a
crafted config key or a symlink that points out of the tree.
Every one of these is covered by a negative test; see
tests/test_paths.py, tests/test_config_redaction.py,
tests/test_artisan_backend.py, and tests/test_server_protocol.py.
What is explicitly out of scope: this is not a sandbox for the agent's other tools, and it does not defend against a compromised host or a malicious PHP runtime. It hardens the one surface it owns — introspection of the codebase.
Tools (all read-only):
Tool | Returns |
| Counts and versions, in one call, for cheap orientation. |
| Every route: methods, URI, name, middleware, |
| One route by name or URI. |
| Migration files on disk, plus applied/pending state when a database is reachable. |
| Eloquent models: table, |
| Queued job classes with |
| Dotted config lookup with mandatory secret redaction. |
| Direct requires with versions, plus Laravel and PHP versions. |
Resources: laravel://routes, laravel://schema, laravel://composer — the
same data as JSON documents, for clients that prefer resources to tool calls.
static (default, and the only one used in CI). Pure parsing of
composer.json, routes/*.php, database/migrations/*.php,
app/Models/*.php, app/Jobs/*.php, and config/*.php. Requires no PHP.
artisan. Used only when php is on PATH and php artisan about
succeeds. Routes and migration status then come from route:list --json and
migrate:status, which are exact where the static parser is best-effort.
Models, jobs, config, and composer data stay static even here — no read-only
artisan verb exposes them.
The backend is chosen once at startup and reported in every response so an agent
knows how much to trust the data. Set MCP_ARTISAN_STATIC_ONLY=1 to force the
static backend even when PHP is available.
Install and run against a project:
pip install -e .
MCP_ARTISAN_PROJECT=/path/to/laravel-app python -m mcp_artisanOr register it with an MCP client (the entry point is the mcp-artisan
console script):
{
"mcpServers": {
"artisan": {
"command": "mcp-artisan",
"env": { "MCP_ARTISAN_PROJECT": "/path/to/laravel-app" }
}
}
}The project root defaults to the current working directory if
MCP_ARTISAN_PROJECT is unset.
This repository ships a small hand-built fixture Laravel app under
tests/fixtures/laravel-app (no framework was downloaded). Every count quoted
below is produced by a command here, not asserted in prose.
python scripts/demo.pyprints, for the fixture: 8 tools exposed, and a project_summary of
6 routes, 2 models, 2 migrations, 2 jobs, 3 direct dependencies, on the
static backend — followed by a redacted database password to show the masking.
The artisan allowlist is three verbs:
python -c "from mcp_artisan.artisan_backend import ALLOWED_VERBS; print(sorted(ALLOWED_VERBS))"
# ['about', 'migrate:status', 'route:list']The full test suite (unit tests for both backends, plus protocol-level tests that drive the server through an in-memory MCP client) runs with:
pip install -e ".[dev]"
pytestCI runs exactly this on every push (.github/workflows/ci.yml), with no PHP
installed and no secrets.
Choices made in the interest of a smaller, safer, more predictable server. Where a fuller behaviour was possible, the simpler option was taken and recorded here.
The static route parser does not resolve Route::group prefixes/middleware,
Route::resource expansion, or closures' internals. It parses top-level
Route::<verb> statements and their chained ->name()/->middleware(). This
is a best-effort map; where exactness matters, the artisan backend provides
the real route table. Closures are reported with an action of Closure.
The static backend cannot know which migrations have run — that needs a
database connection. It lists the files and reports applied/pending as
unknown rather than guessing. The artisan backend fills in real status.
The config parser understands a subset of PHP: scalars, arrays (both
[...] and array(...)), env() (evaluated as its default argument only,
since .env is never read), string concatenation, and Class::class.
Anything it cannot evaluate — storage_path(), closures, other calls —
resolves to null rather than raising. It never executes PHP.
Redaction is keyed on the config key, not the value, because the key is the trustworthy signal. It over-redacts by design: a false positive hides a value the agent could have seen; a false negative leaks a credential.
composer_deps reports the require block only, not require-dev, since
the target is the application's runtime dependency surface.
Default model table names are derived with a small snake-case +
pluralisation rule (User → users, Category → categories). It covers
the common cases, not every English irregular; models with an explicit
$table are always exact.
Jobs are read from app/Jobs only. Queueable classes elsewhere are not
discovered by the static backend.
The backend is selected once at startup, not per call, so a project does not flip between backends mid-session.
mcp_artisan/
paths.py project-root resolution and the path-containment check
redaction.py key-based secret redaction
phpparse.py defensive parser for the PHP subset in config/routes/models
static_backend.py source-only parsers (the default backend)
artisan_backend.py guarded, allowlisted php-artisan subprocess backend
service.py backend selection and the per-tool responses
server.py the MCP tool/resource surface over stdio
tests/
fixtures/laravel-app/ hand-built minimal Laravel app
test_*.py unit, protocol, and negative safety testsPython 3.12+. The only runtime dependency is the official mcp SDK. PHP is
optional and only enables the artisan backend.
MIT.
Direct composer requires with versions, plus Laravel and PHP versions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It specifies the output content (direct requires, Laravel and PHP versions) but does not mention whether the operation is read-only, the possibility of errors if composer.json is missing, or any side effects. This is a modest disclosure for a simple inspection tool.
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 a single, brief sentence that concisely states what the tool provides. It is front-loaded with the key information and contains no extraneous words. It earns a high score for efficiency.
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 simple, zero-parameter read-only inspection tool, the description is adequate: it tells the agent what the tool returns. It does not specify the input source (e.g., composer.json) or exact formatting, but due to the low complexity and lack of structured schema, this is not a significant gap.
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 tool has zero parameters, and the input schema is empty. According to the rubric, a baseline of 4 is appropriate for no-parameter tools. The description does not need to explain any parameters, and it does not introduce any parameter-related ambiguity.
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 identifies the tool's purpose: listing direct composer requires with versions, plus Laravel and PHP versions. It distinguishes from sibling tools like list_routes and list_migrations because it focuses on dependencies. However, it uses a noun phrase rather than an explicit verb like 'list' or 'get', which slightly reduces clarity.
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 used to inspect project dependency information, but it does not explicitly state when to use it versus alternatives or provide any exclusions. For a tool with clearly distinct siblings, the implication is sufficient, but explicit guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Dotted config lookup (e.g. app.name). Secret-keyed values return . Never reads .env.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Dotted key, e.g. database.default. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It adds two valuable behavioral details: secret-keyed values return <redacted>, and .env is never read. It doesn't cover other behaviors like error handling, but for a simple lookup this is sufficient.
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 short sentences, front-loaded with the core action, then examples and caveats. Zero 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 tool is simple (one param, no output schema, no annotations). The description covers purpose, examples, redaction, and env exclusion, which is adequate for a config lookup. Could mention missing-key behavior but not essential.
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 100% (the one parameter is fully described). The description's example 'app.name' adds marginal value beyond the schema's example, but doesn't compensate beyond the baseline.
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 a specific verb+resource: "Dotted config lookup" with an example. It is distinct from all sibling tools (routes, migrations, models, etc.), so purpose is unambiguous.
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 (config lookup) and an important exclusion: "Never reads .env." This implies when not to use the tool, though it doesn't name an alternative explicitly. Still, usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One route by name or URI.
| Name | Required | Description | Default |
|---|---|---|---|
| name_or_uri | Yes | Route name (e.g. users.index) or URI (e.g. /users). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, and the description provides no behavioral context beyond the tool's name. Nothing is disclosed about the return value, error behavior if the route is not found, or whether this is a read-only 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 extremely concise but perhaps too terse. It is a grammatical fragment rather than a complete sentence, and while it wastes no words, it sacrifices clarity and completeness.
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?
With no output schema and no behavioral disclosure, the description does not explain what 'describing' a route entails. An agent would not know what information to expect in return, making the tool under-specified for effective use.
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 input schema already fully documents the single parameter with concrete examples (users.index, /users). The description adds no additional parameter semantics, so the baseline of 3 applies.
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 'One route by name or URI' clearly indicates the tool operates on a single route, distinguishing it from list_routes. However, it is a fragment rather than a full sentence, so it lacks explicit verb phrasing like 'Show details for'.
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?
No guidance is provided on when to use this tool versus alternatives like list_routes. There is no mention of use cases, prerequisites, or situations where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Queued job classes with their queue, tries and timeout.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states what information is returned but does not mention whether the operation is read-only, any side effects, permission requirements, or limitations. For a list operation this is a minor gap, but it leaves some ambiguity.
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 extremely concise, consisting of a single short phrase that immediately conveys the tool's purpose. There is no fluff or redundant information.
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 the simplicity of the tool (no parameters, no output schema), the description is mostly complete, listing the returned fields. However, it does not clarify the scope (e.g., all queues vs specific) or potential variations in behavior, making it adequate but not fully comprehensive.
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 tool has zero parameters, so the description need not elaborate on parameter semantics. The baseline of 4 applies because there are no parameters to explain.
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 identifies the function as listing queued job classes with their queue, tries, and timeout. It distinguishes this tool from siblings by its specific focus on jobs and queues, though it could be more explicit with a verb like 'list'.
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?
No guidance is provided on when to use this tool versus the sibling tools. There is no mention of prerequisites, alternatives, or any context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Migration files on disk, plus applied/pending state when a database is reachable.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the conditional behavior regarding database reachability, which is useful, but it does not mention whether the operation is read-only, potential side effects, or output format. For a simple listing tool, this is acceptable but not comprehensive.
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 a single, concise clause that immediately states the core purpose and the database-conditioned extra detail. Every word adds value, making it highly 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?
For a simple parameterless tool with no output schema, the description adequately conveys the essential output: migration files on disk, plus state when possible. It does not specify return format, but the context suggests a list, and no complex behavior requires additional explanation.
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 tool has zero parameters, so the baseline is 4. The description adds no parameter details, but none are required given the empty input schema.
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 identifies that the tool lists migration files and, when a database is reachable, includes applied/pending state. While it lacks an explicit verb, the tool name 'list_migrations' implies the action, and the resource is distinct from sibling tools like list_routes and list_models.
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?
No guidance is provided on when to use this tool versus alternatives. The only context is the conditional phrase 'when a database is reachable,' which is a behavioral nuance rather than an explicit usage recommendation or exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Eloquent models: table, fillable, casts, relations (static parse of app/Models).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 that the operation is a 'static parse' (non-invasive, read-only file analysis) and specifies the data it returns. It does not detail edge cases (e.g., hidden files, parsing limitations), but for a straightforward listing tool this is adequate transparency.
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 a single compact phrase, front-loading the core purpose and listing the return fields without any filler. Every word adds value, making it an excellent example of concise documentation.
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 the tool's simplicity (no params, no output schema), the description sufficiently outlines what the tool returns. It could detail the output format (e.g., array keys, type casting) but the current level is enough for an agent to understand the tool's scope and likely invocation result.
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 tool has zero parameters, so the schema provides no information. Per the rubric, a baseline of 4 applies for 0-param tools. The description adds no parameter details because none exist; the score reflects that the schema is fully complete as-is.
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 names the specific resource ('Eloquent models') and enumerates the exact attributes exposed (table, fillable, casts, relations). The scope ('static parse of app/Models') clarifies it's a code inspection tool, distinguishing it from siblings like list_routes or composer_deps which target different resources.
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 inspecting Eloquent model definitions, and the sibling list makes the alternative clear. However, there is no explicit 'when to use' statement or exclusion of other tools, so the guidance remains implicit rather than direct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
All HTTP routes: methods, uri, name, middleware, controller@action.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It does list the fields returned, but it does not explicitly mention read-only status, pagination, ordering, or any limitations. For a simple listing operation, this is adequate but 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 a single concise sentence that directly states the tool's purpose and the data returned. Every word earns its place, with no redundancy or filler.
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 no parameters and no output schema, the description lists the exact fields returned and is effectively complete for basic use. However, it omits details about whether the list is ordered, paginated, or if any routes are excluded, so it is not a full 5.
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 input schema has zero parameters, so the baseline is 4. The description adds value by specifying the output structure, which is helpful even though there are no parameters to describe.
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 specifies that the tool returns all HTTP routes with their methods, URI, name, middleware, and controller@action. This is a distinct resource and distinguishes it from sibling tools like describe_route, which likely targets a single route.
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 does not explicitly mention when to use this tool versus alternatives, nor does it give any exclusions. However, the behavior is obvious: it lists all routes, so usage is implied. No alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Counts and versions for cheap orientation, in one call.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not explain what is counted, what versions refer to, whether the call is read-only, or what the response structure looks like. 'Cheap orientation' hints at low cost but is not a concrete behavioral trait.
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 a single sentence with no redundant words. It is front-loaded with the core action ('Counts and versions') and efficient. However, its brevity contributes to under-specification, but that is penalized in other dimensions, not here.
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 there are no annotations and no output schema, the description is the sole source of context. It fails to specify what counts are provided, what versions are reported, or the format of the result. This is inadequate for an agent to reliably select and invoke the tool, especially when siblings offer more explicit functionality.
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 tool has zero parameters, and the schema coverage is 100% (empty schema). Per the baseline for parameterless tools, the description does not need to explain parameters, and it does not undermine the schema. No additional parameter semantics are required.
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 says 'Counts and versions for cheap orientation,' which indicates the tool provides aggregated counts and version information for a quick overview. However, it does not specify which resources are counted or whose versions are returned, making the purpose somewhat vague compared to the more specific sibling 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?
No usage guidance is provided. The description implies using this for 'cheap orientation' but does not state when to choose this tool over siblings like list_routes or list_models, nor does it mention any exclusions or prerequisites.
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. Dates show when Glama detected each change.
v0.1.0composer_depsconfig_getdescribe_routelist_jobs_and_queueslist_migrationslist_modelslist_routesproject_summaryEach tool targets a distinct aspect of a Laravel application: routes, migrations, models, jobs, config, dependencies, and a summary. describe_route is the only detailed view of list_routes, which is a common and clear pattern. No two tools overlap in purpose.
Most tools follow a verb_noun snake_case pattern (list_routes, list_migrations, config_get). However, composer_deps and project_summary are noun-first, deviating from the otherwise consistent verb-first style. The naming is still predictable and readable.
With 8 tools, the set is well-scoped for a Laravel artisan inspection server. Each tool covers a meaningful portion of the domain without redundancy or bloat. The count feels appropriate for orientation and common development tasks.
The surface covers core Laravel inspection needs: routes, migrations, models, jobs, config, and dependencies. Minor gaps exist, such as lack of direct controller listing or cache/event inspection, but these are workarounds and not critical for the stated purpose of cheap orientation.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Code intelligence for LLMs. Analyze, search, and retrieve code from any public git repository.
Read-only AI project discovery, verification, comparison, shortlisting, and stack planning.
Read-only AI coding tools for change verification, release readiness, capacity, and guidance.
Code intelligence platform for AI agents. 20 tools for architecture, security & impact analysis.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/0mandrock1/mcp-artisan'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
