Devkit For Strapi Mcp

The running DevKit server: its version (the one to name in a bug report), the licence tier, which tools really run (without a licence the Pro tools answer an upsell), the indexed roots and how current the index is (`freshness`).

Takes no parameters.

List the Strapi projects discovered in the workspace (name, root, Strapi version, counts, `freshness`). Call this first in a multi-project workspace, then pass `from`/`project` to the other tools; project_info gives one project in full.

Takes no parameters.

One project in full: Strapi version, TS or JS, package manager, API prefix, counts, every local and installed plugin with whether DevKit verifies refs into it (and if not, why), health and freshness. Call it to orient yourself, or when a plugin ref comes back `external`.

Index a Strapi project from an ABSOLUTE path: its root or any file/folder inside it (a folder is also scanned downward, for monorepos). Use it when a tool returns `noProject`. Idempotent; returns the projects now known.

Rescan every project from disk and rebuild the index. Rarely needed: each call already re-indexes what changed on disk. For a project added since startup, or edits made outside on a project whose `freshness.diskTracking` is 'off'.

List the real content-type UIDs (e.g. api::article.article) of a Strapi project. Use these exact UIDs — do not invent them.

List the real component UIDs (e.g. shared.seo) of a Strapi project.

List the real refs of a project's services, controllers, policies and middlewares (optionally one kind). Use the exact refs returned.

The data model as a Mermaid `erDiagram`, read from the schemas: content-types (optionally components) with their fields, one line per association with its cardinalities, media and the plugin types they link to. For a README, a doc or an issue.

The real attributes (fields, relations, components) of a content-type or component: use it instead of guessing field names.

The file(s) defining a Strapi ref, tagged by kind — installed plugins included (in node_modules).

Call this before writing a magic string: is this Strapi ref real in the project, as Strapi registers names (an API file `hasAccess.js` is `has-access`)? valid | unknown (+ didYouMean) | external: in a plugin DevKit cannot verify (project_info says why).

Every call-site of a ref (or `ref#method`) in the project's own code (src/, config/, database/migrations): the total, then a page of `path:line:col [via] snippet` lines (1-based). A UID written as a plain value counts as `[literal]`; `unresolvedCalls` are the Strapi calls whose UID DevKit cannot read, which may reach it too.

The HTTP route table — the project's routes, createCoreRouter's auto-CRUD and the plugins' (`origin`) — with method, mounted `fullPath`, handler, policies, middlewares, auth and where each is declared. With `pipeline: true`: what a request goes through, in Strapi's order, each step's status (`not-found-by-strapi`: Strapi throws at startup). Use it to explain a 401/403 or a startup error about a policy or middleware.

Definitions no Strapi ref reaches: methods, content-types, components, services, policies, middlewares. Only Strapi refs count, so a method called directly in TS still appears — verify before deleting. `onlyArchivedCallers`: only called by migrations Strapi never runs; `requiredByPath`: its file is loaded by path, so the module is used.

The Strapi call forms DevKit indexes (`via` tag + example) and those it does not (`indexed: false`): whether find_references/list_unused can be trusted for a pattern.

Takes no parameters.

Magic strings that point at nothing (refs into plugins DevKit cannot verify are skipped). After apply_edits, it should return none.

strapi-plugin-config-sync, from the files only (no database): its version, its options and where each comes from (the warnings say which default exclusions a short `excludedConfig` drops), the sync directory and its files by status — `ok`, `excluded`, `invalid` (not JSON), or of a type not registered here.

The diff config-sync's admin page shows, from the real plugin: each entry that differs between config/sync and the database (`different`, `only-in-db`, `only-in-sync-dir`), what differs in a few words, and its `likelyDirection` (import | export | unknown) from the file's git history. It includes what a Strapi start changes by itself: after changing a schema, a controller or a route, export those entries and commit them with the code. It loads the project's Strapi the way config-sync's CLI does, which writes to the database as a `strapi develop` start does (schema sync, migrations): a local development database only — a remote one, or a Strapi 4 database under Strapi 5 code, is refused first. A few seconds.

Write entries from the database into config/sync with the plugin's own export, in the exact form config-sync compares. Only entries that differ; one only in config/sync has its file deleted. Commit the files with the code that caused them. It loads the project's Strapi the way config-sync's CLI does, which writes to the database as a `strapi develop` start does (schema sync, migrations): a local development database only — a remote one, or a Strapi 4 database under Strapi 5 code, is refused first.

Apply config/sync entries to the database with the plugin's own import (a role, a content-manager view, a setting). `keys` is required, never everything; an entry only in the database is deleted from it. The entries still different afterwards are exported back (`reexport`), so the diff converges. Refused with NODE_ENV=production. It loads the project's Strapi the way config-sync's CLI does, which writes to the database as a `strapi develop` start does (schema sync, migrations): a local development database only — a remote one, or a Strapi 4 database under Strapi 5 code, is refused first.

Where a content-type's relation fields are used by name in queries (populate, filters, where), nested levels included. Before retargeting or removing a relation.

Refs matching a glob (`plugin::billing.*`, `api::*`, `*`; only `*` is special), each with the kinds it resolves to.

The refs `ref` uses: relations in its schema, services/controllers it calls…

The refs that use `ref`: what would break if it moved or changed.

Plan renaming a service/controller method: its declaration, every call-site and, for a controller, the route handlers. Writes nothing: review the plan, then `apply_edits` its `planId`.

Plan renaming a content-type, component, service, controller, policy or middleware: every call-site and route handler, and the files. The `warnings` list the UIDs Strapi also stores in the database, which the plan does not migrate. Writes nothing: review, then `apply_edits` its `planId`.

Plan moving a service/controller/policy/middleware, or a content-type with its whole resource (service, controller, routes; relation targets repointed), to another namespace: every call-site rewritten, the files relocated. Refused whole if unsafe. Writes nothing: review, then `apply_edits`.

plan_move for several refs to one namespace, in one plan, so the refs between them stay right. Refused whole if any is unsafe.

Plan a new local plugin (package.json and a strapi-server.js that registers its folders) and its entry in `config/plugins` (else a warning says what to add). Writes nothing: review, then `apply_edits`.

create_plugin and plan_move in one plan: a new local plugin, and these services/controllers/policies/middlewares moved into it. Refused whole if unsafe.

Plan changing the `target` of a content-type's relation field in schema.json. Refused if the field isn't a relation or the target is unknown; warns about a bidirectional relation's orphaned inverse. Writes nothing: review, then `apply_edits`.

Plan renaming an attribute in schema.json and, for a relation, its populate/filters usages. NOT a complete field rename: object access (`entity.field`, `data: { field }`, destructuring) is not rewritten — the warnings say to review it by hand. Writes nothing: review, then `apply_edits`.

⚠️ Writes files: applies exactly the reviewed plan (plan_*, create_plugin, extract_to_plugin) by its `planId`. If a file it touches changed since, nothing is written.

⚠️ Writes files: plan_rename_* and apply_edits in one call, without review. Prefer those two to review first.