What can you do with this server?

This server is a non-destructive diagnostic MCP integration layer for AI Disk Doctor Core, exposing read-only/bounded tools for checking Core status, scanning, model inventory, diffing, capability discovery, and explainability. * core_status: Checks local Core availability, expected/tested version, command surface, and compatibility status. * scan_summary: Runs a non-destructive Core scan and returns a bounded projection of findings; may persist a Core-owned snapshot under .aidisk/reports. * ai_model_inventory: Returns metadata-only model/cache inventory from Core, without reading model, prompt, source, token, or credential contents. * latest_diff: Invokes Core's aidisk diff --latest --json to summarize changes between the latest snapshots. * aidisk_capabilities: Discovers Core's machine-readable capability contract and explainability readiness gate (no model input, no side effects). * aidisk_workspace_explain: Runs read-only Core explainability with no snapshot and optional validated category, returning bounded storage/evidence/handling summaries. * The server is strictly non-destructive: no clean, restore, quarantine, delete, arbitrary shell, executable, rules, or filesystem mutation tools are exposed.

How do I use ai-disk-doctor-integrations?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ai-disk-doctor-integrations Run a disk scan summary and show me the report" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

de en es ja ko ru zh

ai-disk-doctor-integrations

by quzhiii

Overview Schema Source Related Servers Score Discussions Admin

JavaScript

Local

AI Disk Doctor Integrations

Universal local Agent Skill and non-destructive diagnostic MCP server for AI Disk Doctor Core.

This repository is an integration and distribution layer. It does not implement a second scanner, cleaner, risk engine, recovery model, policy system, history engine, or explainability engine. The local Core remains the execution and policy source of truth.

Current Alpha Scope

The MCP server exposes six tools:

Tool	Behavior	Model-facing inputs	Core side effect
`aidisk_capabilities`	Discover Core's machine-readable capability contract and evaluate the explainability readiness gate	None	None
`aidisk_workspace_explain`	Run Core explainability through the fixed no-snapshot diagnostic contract and return bounded storage/evidence/handling summaries	`category?`	None
`core_status`	Check Core availability, required command surface, and compatibility provenance	None	None
`scan_summary`	Run `aidisk scan --json` and return bounded Core evidence	`category?`	Current Core CLI may save `.aidisk/reports/scan-*.json`
`ai_model_inventory`	Run `aidisk models inventory --json` with Core defaults and return bounded assets	`tool?`	None intended
`latest_diff`	Run Core-owned `aidisk diff --latest --json` and return bounded changes	None	None

The current Alpha exposes no clean, restore, quarantine, delete, arbitrary shell, arbitrary executable, arbitrary rules/policy path, arbitrary reports directory, or arbitrary filesystem mutation tool. aidisk_workspace_explain is read-only and invokes only aidisk explain --json --snapshot skip with an optional validated category selector.

Current Core Baseline

Tested Core baseline: v1.8.0 release at 3e3f38535af74dcb168c7c1f01773a1b80fee052.
Pinned Core provides agent-capabilities-v1 and agent-diagnostic-cli-v1, embedding explainability-v1 schema 1 in the fixed explain --json --snapshot skip response.

Related MCP server: mcp-readonly-code-server

Install

Prerequisites

Node.js 18 or newer.
AI Disk Doctor Core v1.8.0 on PATH as aidisk/aidisk.exe, or set AIDISK_EXE. On Windows x86_64, I3 setup can acquire the official release automatically when neither is supplied.
This integration is tested against Core release v1.8.0 at 3e3f38535af74dcb168c7c1f01773a1b80fee052. Runtime compatibility is checked by core_status and the machine-readable aidisk capabilities --json contract; current Core binaries do not expose a runtime git revision, so the exact revision is recorded as release provenance rather than claimed from runtime detection.

Install from a checkout:

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

The process uses MCP stdio transport and should be started by an MCP client. The npm dependency set is locked in package-lock.json.

I3 Self-Service Alpha

For the Windows-first Claude Code path, use the package-managed setup and verification commands documented in docs/I3_SELF_SERVICE.md:

npm install
node scripts/i3.mjs setup --workspace C:\path\to\workspace --core C:\path\to\aidisk.exe
node scripts/i3.mjs verify --workspace C:\path\to\workspace --core C:\path\to\aidisk.exe

Setup refuses to overwrite an unowned same-name Claude registration. The safe Alpha launch uses a temporary strict MCP configuration with only the existing diagnostic MCP tools and denies host mutation/shell tools. feedback writes a local redacted receipt only when explicitly requested; uninstall removes only the package-owned local Claude registration.

OpenCode

OpenCode supports project-local MCP declarations in opencode.json or opencode.jsonc:

{
  "$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",
      "environment": { "AIDISK_EXE": "aidisk" },
      "enabled": true
    }
  }
}

Set cwd to the user workspace where Core snapshots should be stored, rather than the integration checkout. Then use opencode mcp list or ask the agent to check core_status. The checked-in example is under adapters/opencode/opencode.jsonc.

OpenCode Agent Skills are discovered from .opencode/skills, .claude/skills, or .agents/skills. Copy or symlink skills/ai-disk-doctor into one of those locations for a project or user installation.

Qwen Code

Qwen Code supports local stdio MCP servers and extensions in current official documentation. Equivalent .qwen/settings.json entry:

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

The repository root is a Qwen extension package through qwen-extension.json; see adapters/qwen/README.md. The locally installed Qwen CLI in this environment was too old to expose documented MCP/extension subcommands, so client smoke is not claimed.

CodeBuddy / WorkBuddy

Exact packaging is deferred until an official, locally testable CodeBuddy / WorkBuddy client contract is available; see adapters/codebuddy/README.md. No Expert persona or vendor-specific risk logic is included.

TRAE

TRAE MCP and Skill docs exist, but exact project packaging is deferred until a TRAE client is locally available for validation; see adapters/trae/README.md.

Safety Boundary

MCP transport is local stdio only.
core_status.server.mode is non-destructive-diagnostic: the server exposes no destructive action, but scan_summary can cause Core-owned snapshot persistence.
The server starts only the configured aidisk executable with fixed allowlisted argv.
aidisk_capabilities accepts no model-facing input and invokes only the fixed aidisk capabilities --json argv.
Model-facing inputs are limited to aidisk_workspace_explain.category, scan_summary.category, and ai_model_inventory.tool.
aidisk_workspace_explain first checks aidisk capabilities --json, then invokes only aidisk explain --json --snapshot skip with an optional validated --category. It rejects missing/unsupported contracts, malformed response envelopes, and snapshot-writing behavior.
No model-facing rules, policy, root, reports directory, executable, shell, cleanup, quarantine, restore, or delete parameter exists.
scan_summary is non-destructive but readOnlyHint: false because current Core CLI scan persists a Core-owned snapshot. It is destructiveHint: false and does not modify user/workspace files.
Output is bounded: scan findings, model assets, diff changes, Core stdout/stderr capture, error evidence, and MCP text content all have hard limits.
Model inventory is metadata-only according to the Core contract; this integration does not read prompt, transcript, source, document, token, cookie, credential, or model binary contents.
aidisk_capabilities does not parse human help text or infer support from version numbers. Missing, malformed, or unsupported capability contracts fail closed.

Agents must never bypass these rules by deleting paths with shell commands. If a future mutation flow is approved, it must use a separate Desktop-mediated authorization surface.

Development

npm install
npm run check
npm test
npm audit --audit-level=moderate
git diff --check
cargo fmt --manifest-path spikes/rust-direct-core/Cargo.toml -- --check
cargo run --manifest-path spikes/rust-direct-core/Cargo.toml

For a real Core smoke, use the official Core v1.8.0 release or build release baseline 3e3f38535af74dcb168c7c1f01773a1b80fee052, set AIDISK_EXE to that binary, and run npm test. CI includes a current-release AIDISK_EXE smoke in addition to protocol-only Node tests and the Rust direct-Core spike.

License

The integration source is dual-licensed under MIT or Apache-2.0. See LICENSE-MIT and LICENSE-APACHE. Core licensing remains governed by the public Core repository.

Status

I3 Self-Service Safe Alpha. This repository is not the commercial Desktop and contains no accounts, billing, entitlements, telemetry, cloud synchronization, or proprietary Desktop code.

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. Dates show when Glama detected each change.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0

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

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

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
turva-mcp A
dev.turva
Read-only MCP server for turva.dev, an agent-readiness audit and advisory service.
Autonomous Agents Developer Tools Security
52
RZ AI Labs A
com.rzailabs
Read-only MCP server for RZ AI Labs — query its services, workshops, and contact info.
AI & Machine Learning Customer Support
42

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 4 months ago (2026-05-04 04:27 UTC)
1
MIT
mcp-readonly-code-server
John0615
F
license
B
quality
C
maintenance
A read-only MCP server that exposes a local code workspace to AI clients via stdio, providing file browsing and text search capabilities with path safety rules.
Updated 2 months ago (2026-07-18 08:30 UTC)
1
-
local-tools-mcp-server
fenhuayue
F
license
A
quality
C
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 2 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 a month ago (2026-08-07 13:16 UTC)
1
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/quzhiii/ai-disk-doctor-integrations'

If you have feedback or need assistance with the MCP directory API, please join our Discord server