`aide_validate` encodes judgements like "an orchestrator with 3+ helper imports ought to have a .aide" that only mean anything once you have adopted AIDE. `aide_info` and `aide_upgrade` are about the methodology's own version rather than your specs, and `aide_upgrade` says outright that it is not for editing user .aide files — worth knowing before you point it at a project. The naming rules are enforced rather than documented: creating a research.aide renames an existing .aide to intent.aide, so a scaffold call can rename a file you never named. `aide_inspect` is the exception, reading TypeScript and JavaScript symbols and answering a question about code rather than about specs.
A server for the AIDE spec convention: it maps and reads .aide files, creates new ones under the naming rules, validates the set, reports which methodology artifacts are behind the canonical manifest, and looks up a code symbol's contract.
- Discovery shaped by whether you pass a `path`: `aide_discover` called without one returns a project-wide map of spec locations and types only, and called with a `path` opens on the ancestor chain — the cascading intent lineage from the project root down to the target.
- `aide_read` returns a spec's content, its classified type of intent, research, plan or todo, the related specs sitting in the same directory, and the links found in the content, including relative paths, inline references and URLs.
- Naming rules applied at creation rather than described: `aide_scaffold` writes an intent spec as .aide, has it become intent.aide once research.aide exists in the same folder, and renames an existing .aide when a research spec is created next to it.
- A health check from `aide_validate` covering orphaned specs in folders with no orchestrator, orchestrators carrying 3+ helper imports but no .aide, a .aide and an intent.aide colliding in the same folder, broken links, a research.aide with no intent spec, and specs whose frontmatter has no description field.
- Version reporting on the methodology itself: `aide_info` returns the artifact keys whose versions in the host's .aide/versions.json are behind the manifest shipped with the package, and `aide_upgrade` compares those artifacts against the canonical versions and returns the result grouped by `category`.
- `aide_init` bootstraps AIDE into a project and returns structured JSON, reporting each step's `status` as would-create, would-overwrite, would-skip or exists alongside its category and filePath.
- `aide_inspect` returns the JSDoc, signature and kind of a named symbol across ts, tsx, js, jsx, mjs and cjs sources, answering what it accepts and returns from the contract alone without opening the file.
- `aide_brain` reaches the brain mid-task, taking `kind` as orientation or config.
No credentials are configured — what it needs is a project on disk holding the .aide specs, and, for `aide_info` to have anything to compare, a `.aide/versions.json` in that project to read against the manifest shipped with the package.
One command — npx -y @aidemd-mcp/server@latest