aidemd-mcp/server

Overview Schema Source Related Servers Discussions Admin

aide_discover

Scan .aide spec files to map spec locations, types, and statuses; optionally drill into a path to get ancestor intent lineage plus subtree summaries and warnings.

Instructions

Scan for .aide spec files in this project. Returns a tree map of where specs live, following progressive disclosure.

Without a path: returns a lightweight project-wide map — file locations, type tags and each spec's one-line description; a plan or todo tag carries its status, e.g. [plan: approved]. Only the head of each file is read. Use this once to understand the project's spec architecture.

With a path: the response opens with the ancestor chain — the cascading intent lineage from project root down to the target directory, with each ancestor showing its description and alignment status (aligned/misaligned when set). The ancestor chain gives you the full inherited context before you read a single spec body. After the ancestor chain comes the detailed subtree of the target directory — summaries extracted from file content and anomaly warnings. Use this to drill into the area you're working on.

.aide files are progressive disclosure specs that live next to orchestrator code — they contain intent (strategy, implementation contracts, anti-patterns), research (sources, data, patterns), or QA checklists (todo). Read .aide files BEFORE reading code — they are the context layer between folder structure and implementation details.

File types (.aide, intent.aide, research.aide, plan.aide, todo.aide):

.aide — Intent spec (default). Strategy, contracts, anti-patterns.
intent.aide — Same as .aide, used only when research.aide exists in the same folder.
research.aide — Raw research. Sources, data points, pattern synthesis.
plan.aide -- Architect's implementation plan. Checkboxed steps for the implementor.
todo.aide — QA re-alignment document. Captures where implementation drifted from intent.

Never have both .aide and intent.aide in the same folder.

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_discover"
  }
}

Input Schema

Name	Required	Description	Default
`path`	No	Subdirectory to drill into. When provided, the response opens with the ancestor chain — the cascading intent lineage from root to target, each ancestor showing its description and alignment status — followed by the detailed subtree with summaries and warnings. When omitted, returns a shallow project-wide map (locations, type tags with plan/todo status, and spec descriptions).

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.15.0Oct 29, 2026

changedInput schema / properties / path / description

Previous value: -"Subdirectory to drill into. When provided, the response opens with the ancestor chain — the cascading intent lineage from root to target, each ancestor showing its description and alignment status — followed by the detailed subtree with summaries and warnings. When omitted, returns a shallow project-wide map (locations and types only)."New value: +"Subdirectory to drill into. When provided, the response opens with the ancestor chain — the cascading intent lineage from root to target, each ancestor showing its description and alignment status — followed by the detailed subtree with summaries and warnings. When omitted, returns a shallow project-wide map (locations, type tags with plan/todo status, and spec descriptions)."

First observedv0.3.15Apr 19, 2026

TDQS

A3.8/5.0

Behavior4/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 well: it discloses that only the head of each file is read, that responses open with an ancestor chain with alignment status, and that subtree output includes summaries and anomaly warnings. It does not address permissions, failures on a non-existent path, or depth limits of the scan.

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

Conciseness3/5

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

Front-loaded with the core behavior, which is good, but the two-mode explanation is duplicated almost verbatim between the description body and the schema description, and the length is heavy for a one-parameter read tool. The file-type glossary earns its place as reference material; the duplication does not.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/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 (and does) describe the return shape for both modes, and the tag taxonomy explains how to interpret [plan: approved]-style tags. Gaps remain on error behavior for invalid paths and on how deep the subtree scan descends.

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

Parameters3/5

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

Schema coverage is 100% and the single path parameter's schema description already spells out both modes, so the description largely restates it. The file-type taxonomy adds interpretive value for reading results but does not deepen understanding of the parameter itself, so this is the baseline 3.

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?

A specific verb and resource ('Scan for .aide spec files in this project') plus the return artifact ('tree map of where specs live'). The two modes are clearly scoped (project-wide map vs. subtree drill-down), but no sibling tool (aide_read, aide_inspect, aide_info) is named to contrast with, which is the only thing separating this from a 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?

Explicit usage contexts are given: 'Use this once to understand the project's spec architecture' and 'Use this to drill into the area you're working on', plus the workflow rule 'Read .aide files BEFORE reading code.' No when-not-to-use cases or named alternatives, 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