Skip to main content
Glama
aidemd-mcp

aidemd-mcp/server

by aidemd-mcp
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

aide_info

Checks AIDE artifact versions, global server updates, brain config migration, and brain MCP wiring at startup, returning soft notices and a hard gate that tells the orchestrator whether to continue.

Instructions

Boot-time reporter called by the orchestrator at startup. Returns independent top-level fields that the orchestrator must branch on separately:

outdated (array of stale artifact keys) — soft notification. Compares the host's .aide/versions.json against the canonical manifest shipped with this npm package. Each element names an artifact key that is behind. An empty array means everything is current. A missing .aide/versions.json (old install predating version tracking) silently collapses to []. Staleness is informational — the orchestrator continues with a heads-up to the user.

behind ({ installed, latest } or null) — soft notification. Non-null only when the project's aide entry launches a globally installed server that is older than the latest published version. Suggest npm i -g @aidemd-mcp/server once and continue — it never gates the pipeline. Null when the server is launched locally, is current, or the version check could not run (offline checks pass silently).

brainMigration ({ staleSections, legacyLauncher } or null) — soft notification. Non-null when the brain config has sections whose text matches an earlier template version, or a legacy brain launcher (legacyLauncher lists the reasons: unpinned, unversioned, older-pin, missing-auto-confirm). Mention it once and suggest /aide:brain config; it never gates the pipeline and never changes brain.status.

brain (precondition state) — hard gate. Reports whether the host's brain MCP entry is wired and consistent. Shape: { status, name?, fault?, hints } — name is absent on no-brain-aide and brain-aide-invalid; fault is present only on brain-aide-invalid. The orchestrator must halt and direct the user to resolve the issue before continuing if status is not 'ok'. No path validation is performed — the package never stats any directory on disk; state derives entirely from comparing .aide/config/brain.aide against .mcp.json.

The five brain.status values:

  • ok — .aide/config/brain.aide exists, satisfies the required-section contract, and the host's .mcp.json brain entry matches the parsed mcpServerConfig. name is the user-declared descriptive label from brain.aide. The pipeline may proceed.

  • no-brain-aide — .aide/config/brain.aide is absent. No name field. Remediation: run /aide:brain config, which creates the config.

  • brain-aide-invalid — the file exists but falls short. fault.kind is missing-sections (with fault.sections naming each missing required section) or malformed (with fault.reason). No name field. Remediation: run /aide:brain config.

  • no-mcp-entry — brain.aide parsed successfully but the host's .mcp.json is absent, malformed, or has no mcpServers.brain key. name is present. Remediation: run sync with the same launcher the project's aide MCP entry uses — aidemd-mcp sync when the project's aide MCP entry runs the globally installed aidemd-mcp, or npx -y @aidemd-mcp/server@<version> sync with the version that entry pins when it runs through npx.

  • mcp-drift — brain.aide and .mcp.json both exist but their brain entries disagree on command or args. name is present. Remediation: run sync with the same launcher the project's aide MCP entry uses — aidemd-mcp sync when the project's aide MCP entry runs the globally installed aidemd-mcp, or npx -y @aidemd-mcp/server@<version> sync with the version that entry pins when it runs through npx.

hints is always present on every status — an array of candidate brain root paths the orchestrator can surface during recovery.

No parameters needed — uses the server's working directory.

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.15

TDQS

A4.3/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does so thoroughly: it discloses that staleness is informational only, that a missing versions.json silently collapses to [], that `behind` is null when offline, that no path validation or directory stat ever occurs, and exactly which statuses require halting. These are genuine behavioral traits beyond anything the schema provides.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The response is long, but it is front-loaded with the soft-vs-hard-gate distinction and uses bolded field names as scannable anchors, so the structure aids navigation. It is dense rather than wasteful, though the two lengthy remediation paragraphs about `no-mcp-entry`/`mcp-drift` contain duplicated wording that could be tightened.

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?

There is no output schema, so the description must fully describe the return shape — and it does, covering every top-level field, the null conditions, the five `brain.status` values with their faults and remediations, and the always-present `hints` array. An agent has everything needed to interpret and branch on the result.

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 tool takes zero parameters, so per the rubric the baseline is 4. The description adds a small amount of useful context by noting that the call relies on the server's working directory, which explains how a zero-arg tool determines its target, but there are no parameter semantics to enrich further.

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 opens with a specific use case — 'Boot-time reporter called by the orchestrator at startup' — and enumerates the exact fields returned (outdated, behind, brainMigration, brain), making the resource and function unambiguous. However, it never differentiates itself from plausible siblings like aide_inspect or aide_validate, which also sound like status/config readers, so it falls short of the rubric's 5.

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?

It clearly states the invocation context (called by the orchestrator at startup) and gives explicit branching guidance: soft notifications that never gate, versus `brain` as a hard gate where the orchestrator 'must halt' when status is not 'ok'. It never names an alternative tool to use instead, so it stops short of 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools