de en es ja ko ru zh

ai-disk-doctor-integrations

Name: ai-disk-doctor-integrations
Author: quzhiii

by quzhiii

Overview Schema Source Related Servers Discussions Admin

JavaScript

Local

AI Disk Doctor 集成

面向 AI Disk Doctor Core 的通用本地 Agent 技能和只读 MCP 服务器。

此仓库是集成与分发层。它不实现第二个扫描器、清理器、风险引擎、恢复模型或策略系统。本地 Core 仍然是执行和策略的事实来源。

Alpha 范围

MCP 服务器暴露四个工具：

工具	行为	Core 副作用
`core_status`	检查 Core 可用性和所需命令面	无
`scan_summary`	运行现有的 `aidisk scan --json` 契约	Core 可能会保存 `.aidisk/reports/scan-*.json`
`ai_model_inventory`	运行现有的 `aidisk models inventory --json` 契约	无预期副作用
`scan_history`	列出本地 Core 拥有的快照元数据	无

I0 不暴露 clean、restore、quarantine、delete、任意 shell 或任意文件系统变更工具。在公共 Core 提供合并后的 M1C 可解释性契约之前，explain_storage 有意不包含在内。

Related MCP server: local-tools-mcp-server

安装

先决条件

Node.js 18 或更高版本。
AI Disk Doctor Core v1.7.0 或兼容的更高版本 Core，位于 PATH 中，命令名为 aidisk/aidisk.exe。
当 Core 二进制文件安装在其他位置时，设置 AIDISK_EXE。

从检出安装：

git clone https://github.com/quzhiii/ai-disk-doctor-integrations.git
cd ai-disk-doctor-integrations
npm install
npm start

对于确定性的本地安装，请固定仓库检出版本或使用带标签的发布版本。npm 依赖在 package-lock.json 中固定为 @modelcontextprotocol/sdk 1.30.0。

该进程使用 MCP stdio 传输，应由 MCP 客户端启动，而不是作为独立的交互式程序打开。

OpenCode

OpenCode 支持在 opencode.json 或 opencode.jsonc 中声明项目级 MCP：

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "ai-disk-doctor": {
      "type": "local",
      "command": ["node", "C:/absolute/path/to/ai-disk-doctor-integrations/src/server.js"],
      "cwd": "C:/absolute/path/to/your-workspace",
      "enabled": true
    }
  }
}

对于全局安装，请为 command 参数使用绝对路径，并在需要时在 environment 中设置 AIDISK_EXE。将 cwd 设置为应存储 Core 快照的用户工作区，而不是集成检出目录。然后使用 opencode mcp list 或让代理检查 core_status。已检入的示例位于 adapters/opencode/opencode.jsonc。

OpenCode Agent 技能从 .opencode/skills、.claude/skills 或 .agents/skills 中发现。对于项目或用户安装，将 skills/ai-disk-doctor 复制或符号链接到其中一个位置。

Qwen Code

Qwen Code 通过 qwen mcp 或 settings.json 支持本地 stdio MCP 服务器：

qwen mcp add --scope user --transport stdio ai-disk-doctor node ./src/server.js

等效的 .qwen/settings.json 条目：

{
  "mcpServers": {
    "ai-disk-doctor": {
      "command": "node",
      "args": ["/absolute/path/to/ai-disk-doctor-integrations/src/server.js"],
      "cwd": "/absolute/path/to/your-workspace",
      "env": { "AIDISK_EXE": "aidisk" },
      "trust": false
    }
  }
}

仓库根目录通过其 qwen-extension.json 成为 Qwen 扩展包。在 npm install 之后，将仓库作为本地扩展安装；参见 adapters/qwen/README.md。规范技能仍然是同一个技能，而不是 Qwen 特定的治理实现。

CodeBuddy / WorkBuddy

使用已安装产品支持的本地 MCP 配置界面，并将其指向相同的 node ./src/server.js stdio 进程。将其工作目录设置为 Core 快照历史应存放的工作区。不包含任何 Expert 角色或供应商特定的风险逻辑。在官方、可本地测试的 CodeBuddy / WorkBuddy 客户端契约可用之前，暂缓确定具体打包方式；参见 adapters/codebuddy/README.md。

TRAE

使用 TRAE 文档中记载的项目 MCP 配置，并添加相同的本地 stdio 进程。将其工作目录设置为 Core 快照历史应存放的工作区。在本地有 TRAE 客户端可供验证之前，暂缓确定具体项目打包方式；参见 adapters/trae/README.md。

Core 诊断

# Verify the Core directly
aidisk --help

# Verify the integration server syntax
npm run check

# Override the Core executable
# Windows PowerShell:
$env:AIDISK_EXE = 'C:\\Tools\\aidisk.exe'
# POSIX shells:
export AIDISK_EXE=/opt/aidisk

如果 Core 缺失或返回格式错误/不兼容的输出，core_status 会报告结构化失败。MCP 进程不会下载 Core、克隆仓库、联系云服务，或静默替换为其他扫描器。

安全边界

MCP 传输仅限本地 stdio。
服务器仅启动配置的 aidisk 可执行文件，并使用固定的只读子命令。
不存在任意 shell 或任意命令工具。
不存在清理、隔离执行、恢复、删除或变更工具。
scan_summary 标记为 readOnlyHint: false，因为当前 Core 扫描持久化可能会写入 AI Disk Doctor 拥有的快照。它仍然是 destructiveHint: false，不会修改用户/工作区文件。
根据 Core 契约，模型清单仅包含元数据；此集成不会读取提示词、转录、源代码、文档、令牌、cookie 或凭据内容。
提供给工具的路径仅传递给相应的 Core 命令或历史元数据读取器。此集成不会递归读取这些路径。

代理绝不能通过 shell 命令删除路径来绕过这些规则。如果未来的变更流程获得批准，它必须使用单独的授权界面。

开发

npm install
npm run check
npm test

要进行真实的 Core 冒烟测试，请安装/构建固定的 Core 修订版，将 aidisk 放入 PATH 或设置 AIDISK_EXE，然后运行 npm test。当未设置 AIDISK_EXE 时，跳过真实 Core 测试。其余协议测试使用临时目录和 Core 缺失场景；它们不会假装已安装供应商客户端。

许可证

集成源代码采用 MIT 或 Apache-2.0 双重许可。参见 LICENSE-MIT 和 LICENSE-APACHE。Core 的许可仍由公共 Core 仓库管辖。

状态

I0 Alpha。此仓库不是商业版 Desktop，不包含账户、计费、授权、遥测、云同步或专有 Desktop 代码。

Available Tools

4 tools

ai_model_inventoryAI Model And Cache InventoryA

Read-onlyIdempotent

Use AI Disk Doctor's existing metadata-only model inventory with Core defaults and return a bounded asset projection. It does not read model, prompt, source, token, or credential contents and does not mutate files.

ParametersJSON Schema

Name	Required	Description	Default
`tool`	No	Optional Core inventory tool selector.

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	Yes
`tool`	Yes
`roots`	Yes
`assets`	Yes
`summary`	Yes
`truncated`	Yes
`provenance`	Yes
`generated_at`	No
`total_assets`	Yes
`schema_version`	No
`returned_assets`	Yes
`stale_after_days`	No

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds key behavioral context: it explicitly states 'does not read model, prompt, source, token, or credential contents' and 'does not mutate files.' This goes beyond the hints by specifying what is not read and what is not mutated, which is valuable for the agent. No contradiction with annotations.

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

Conciseness5/5

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

The description is a single, concise sentence that states purpose, scope, and key behavioral constraints. It is front-loaded with the action ('return a bounded asset projection') and includes critical exclusions. Every clause earns its place, with no fluff.

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?

Given that the tool has an output schema (which presumably describes the return projection), the description doesn't need to explain return values. The tool is simple (1 optional parameter) and has strong annotations. The description covers behavior and constraints well. It is complete enough for the agent to understand what the tool does and what it avoids. The only minor gap is not providing more context on when to use it vs. siblings, but given the simplicity, a 4 is justified.

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 description coverage is 100%, meaning the schema documents the 'tool' parameter with its enum values. The description adds context by saying 'Optional Core inventory tool selector,' but this is largely redundant with the schema's 'Optional Core inventory tool selector' description. Since the schema already covers the parameter well, the description adds minimal extra meaning, but it does reinforce the optionality, so a baseline 3 is appropriate.

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 clearly states that the tool returns a 'bounded asset projection' using 'AI Disk Doctor's existing metadata-only model inventory with Core defaults.' It specifies the resource (model inventory) and the action (return a projection), which is clear enough. However, it does not explicitly distinguish from sibling tools like scan_summary or core_status, though the resource and action are specific enough to imply differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage by stating it uses 'Core defaults' and an optional tool selector, but it does not provide explicit when-to-use guidance or mention alternatives. It doesn't say when to use this tool vs. siblings, but the context of a metadata-only inventory is somewhat clear. The guidance is implied rather than explicit, so it earns a 3.

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

core_statusAI Disk Doctor Core StatusA

Read-onlyIdempotent

Check local AI Disk Doctor Core availability, required command surface, semantic version, and compatibility provenance without scanning or modifying files.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	Yes
`core`	Yes
`server`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

The description adds contextual detail beyond the annotations by listing specific aspects checked (availability, command surface, semantic version, compatibility provenance) and explicitly reaffirms non-invasive behavior. Annotations already declare readOnly and idempotent, so the description enhances rather than contradicts them.

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

Conciseness5/5

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

A single, well-structured sentence conveys all essential details without redundancy. Every phrase earns its place, and the sentence is front-loaded with the primary action and resource.

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?

Given the tool is low-complexity (no parameters) and an output schema exists, the description sufficiently covers what the tool checks (availability, command surface, version, provenance) and its side-effect-free nature. It is complete for an information-only status check.

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 has no parameters and the schema is fully covered. Since there are no parameters to describe, the description is not expected to elaborate on them, and the zero-parameter baseline of 4 is appropriate.

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 uses a clear verb ('Check') with a specific resource ('local AI Disk Doctor Core availability, required command surface, semantic version, and compatibility provenance'). It differentiates from sibling tools like scan_summary and ai_model_inventory by emphasizing it does not scan or modify files.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies this is a safe read-only status check but does not explicitly state when to choose it over alternatives. It notes it avoids scanning and modifying, which hints at contrast with scan_summary, but lacks explicit when-to-use or when-not-to-use guidance.

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

latest_diffAI Disk Doctor Latest DiffA

Read-onlyIdempotent

Use Core-owned latest snapshot discovery and diff semantics through aidisk diff --latest --json. No reports directory or paths are accepted from the model.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	Yes
`tool`	Yes
`after`	No
`before`	No
`changes`	Yes
`summary`	Yes
`truncated`	Yes
`provenance`	Yes
`generated_at`	No
`total_changes`	Yes
`returned_changes`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds no contradictory information; it explains that the tool uses Core-owned semantics and the `--latest --json` options, which is additional context beyond the annotations, though it doesn't describe side effects because there are none.

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

Conciseness5/5

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

The description is concise, consisting of two sentences that are front-loaded with the purpose and immediately state the key constraint (no paths accepted). Every word adds value.

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?

Given the tool has no parameters, an output schema exists (though not detailed), and annotations cover safety traits, the description is complete for its purpose. It might benefit from clarifying the return format, but the output schema presumably handles that, so this is adequate.

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 has zero parameters, and the schema description coverage is 100%, meaning no parameters need explanation. The description clarifies the inherent behavior (using latest snapshot and JSON output) without needing to describe parameter semantics, so it adequately handles the absence of parameters.

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 clearly states the tool performs 'Core-owned latest snapshot discovery and diff semantics' via the `aidisk diff --latest --json` command, which is a specific verb and resource. It distinguishes itself from siblings by indicating it uses Core-owned semantics and does not accept paths or reports directories.

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?

The description implies when to use this tool: when the model needs the latest diff using Core-owned discovery. It explicitly notes that no reports directory or paths are accepted, which guides usage, but does not explicitly contrast with sibling tools such as scan_summary or ai_model_inventory.

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

scan_summaryAI Disk Doctor Scan SummaryA

Run AI Disk Doctor's existing non-destructive scan and return a bounded projection of Core JSON evidence. The current Core CLI may persist an AI Disk Doctor-owned snapshot under .aidisk/reports; it does not mutate user files.

ParametersJSON Schema

Name	Required	Description	Default
`category`	No	Optional Core rule category filter. The integration validates only bounds; Core owns category semantics.

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	Yes
`tool`	Yes
`policy`	No
`summary`	Yes
`volumes`	Yes
`scan_time`	No
`truncated`	Yes
`provenance`	Yes
`top_findings`	Yes
`total_findings`	Yes
`returned_findings`	Yes

TDQS

A4.5/5.0

Behavior5/5

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

Description goes beyond annotations by explicitly disclosing non-destructive behavior, no mutation of user files, and potential snapshot persistence under .aidisk/reports. Annotations have readOnlyHint: false, but description clarifies safety profile, adding significant value.

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

Conciseness5/5

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

Two sentences efficiently convey purpose, scope, side effects, and safety. No redundant phrasing or filler; carefully front-loaded with the core action and outcome.

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?

For a single optional parameter tool with output schema present, description covers purpose, return projection, side effects, and guarantees about user files. Includes relevant environmental detail (CLI snapshot). Complete enough for agent to safely invoke.

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?

The only parameter 'category' has full schema description (100% coverage) explaining it as an optional Core rule category filter with bounds validation. The tool description does not add extra semantics, but schema already provides adequate meaning, so baseline 3 is appropriate.

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?

Description uses specific verb 'Run' with clear resource 'AI Disk Doctor's existing non-destructive scan' and states output 'bounded projection of Core JSON evidence'. It clearly distinguishes from siblings (core_status, ai_model_inventory, latest_diff) by focusing on scan execution and non-destructiveness.

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?

States when to use (run scan) and provides context about non-destructive nature, but does not explicitly mention alternatives or when not to use. Sibling tools are present, but no comparative guidance given. Clear purpose implies usage context, but no exclusions.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesv0.1.0-alpha.2Aug 20, 2026
- First observedai_model_inventory
- First observedcore_status
- First observedlatest_diff
- First observedscan_summary

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.1/5.0

Scored 2026-08-20 15:31 across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: scan_summary runs a scan, core_status checks the Core installation, ai_model_inventory lists models, and latest_diff computes diffs. No overlap or ambiguity in their responsibilities.

Naming Consistency3/5

All names are lowercase snake_case, but they do not follow a consistent verb_noun pattern. scan_summary starts with a verb, while core_status, ai_model_inventory, and latest_diff are noun-led or adjective-noun, creating slight inconsistency.

Tool Count4/5

With 4 tools, the set is small but well-focused on the disk doctor integration's core needs: scanning, status, inventory, and diffing. It is neither bloated nor insufficient for the stated purpose.

Completeness4/5

The tools cover primary operations (scan, check status, list models, diff latest snapshots), but lack explicit snapshot management or detailed per-file reporting. Minor gaps that an agent could potentially work around.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

ORANO Personal Context MCP
io.github.manuvamp
Read-only MCP server: let AI agents read your ORANO saved-video library, tasks, and memory.
Knowledge & Memory Entertainment & Media Project Management
1
ORANO MCP Server
io.github.infotik
Read-only MCP server exposing a user ORANO library to their own AI agent.
Note Taking Knowledge & Memory Search
1
operant-mcp A
io.github.saagpatel
Read-only MCP server for the OPERANT AI operating-agent calibration benchmark.
Autonomous Agents Agent Orchestration Testing & QA Tools
52
ovanek-mcp
io.github.yofor
Ovanek MCP: Model Context Protocol server for Ovanek platform tools; writes are dry-run by default.
1

Related MCP Servers

CodeAudit MCP
Code Analysis Testing & QA Tools Developer Tools
priyanshuchawda
A
license
Not graded
quality
C
maintenance
A read-only MCP server for AI coding agents to inspect repositories, audit code quality, route engineering skills, and plan safe issue/PR workflows.
Updated 5 months ago (2026-05-04 04:27 UTC)
1
MIT
local-tools-mcp-server
fenhuayue
F
license
A
quality
D
maintenance
A read-only MCP server that enables AI assistants to search files, list directories, retrieve system info, and get file metadata on the local file system.
Updated 3 months ago (2026-07-20 09:22 UTC)
4
-
autopsy-mcp
Databases Search File Systems
th0r10293847
A
license
Not graded
quality
C
maintenance
Read-only MCP server that exposes Autopsy digital forensics case data as tools, enabling LLM clients like Cline to browse filesystems, query artifacts, and search keywords without modifying the case.
Updated 2 months ago (2026-08-07 13:16 UTC)
1
MIT
Sumi-Docs-MCP
Documentation Access Search RAG Systems
starSumi
A
license
Not graded
quality
B
maintenance
Read-only MCP server for Markdown, MDX, and OpenAPI docs, exposing list, search, fetch, and OpenAPI spec tools over stdio.
Updated a month ago (2026-09-09 10:43 UTC)
1
MIT