Skip to main content
Glama
Sign In
aidemd-mcp/server

aidemd-mcp/server

by aidemd-mcp
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

aide_info

Reports startup readiness by checking stale artifacts, server version drift, brain config migration, and brain MCP entry health so orchestrators know when to continue or recover.

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 running server — never against the latest published version, so files that match the version the project runs are current even when a newer release exists. 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, launch, versionsBehind, highlights } or null) — soft notification. Non-null when the running server is older than the latest published version, whatever launch the project's aide entry uses — a global install or npx, pinned or not. installed is the running server's version. launch (global or local) picks the remedy: global → npm i -g @aidemd-mcp/server@{latest}; local → first install latest into the npx cache, then move the project's aide pin to it with aide_upgrade({ category: "mcp", targetVersion: latest }), never a hand edit of .mcp.json; if the install fails, switch nothing; once the newer server runs, /aide:upgrade offers to switch the entry to the global command. versionsBehind (1 or more) counts the published releases after installed up to latest; highlights holds 0–3 one-line notes of what they added or fixed (empty when the release notes were unavailable). Show the count and highlights briefly, never the changelog. Either upgrade takes effect only in a new session. It never gates the pipeline. Null when there is no aide entry, the running version is unknown, the server 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: npx-launch, 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.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "aide_info"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.15

TDQS

A4.9/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 behavioral burden and does so thoroughly: it explains that no path validation or disk stat occurs, that missing `.aide/versions.json` collapses to `[]`, that offline checks fail silently, that upgrades only take effect in a new session, and that soft fields never gate the pipeline. It also documents every `brain.status` value, its shape, and its remediation.

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 description is front-loaded with purpose and uses bold field headers and status lists to make a complex return contract navigable. It is long, and the sync remediation text is repeated almost verbatim for `no-mcp-entry` and `mcp-drift`, which is a minor conciseness cost for an otherwise structured definition.

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 and no annotation coverage, so the description must fully explain the tool's return shape and operational meaning. It does: every top-level field, null condition, status enum, fault shape, hint array, and gating consequence is documented.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has zero parameters, so baseline is 4; the description adds meaningful context by stating no parameters are needed and that the tool uses the server's working directory. That is the only parameter-like semantic relevant here.

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 opens with a precise role: a boot-time reporter invoked by the orchestrator at startup. It then enumerates the exact top-level fields returned (`outdated`, `behind`, `brainMigration`, `brain`), making the tool's scope unmistakable and distinct from diagnostic siblings like `aide_inspect` or `aide_validate`.

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 explicitly states when the tool is used (boot-time startup), how the orchestrator must branch on each field, and which conditions are soft notifications versus hard gates. It also tells the agent to halt only when `brain.status` is not `'ok'`, and that the other fields never gate the pipeline.

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