Ecosystem Intelligence MCP
by AvaTar-ArTs
README.md
# Ecosystem Intelligence MCP
A sellable prototype for bounded, read-only understanding of local project directories. It is designed to help an AI assistant inventory projects, identify technology markers, and read selected text files without executing code or exposing arbitrary filesystem paths.
## Product documents
- [What This Is](WHAT-THIS-IS.md)
- [What This Can Do](WHAT-THIS-CAN-DO.md)
- [Changelog](CHANGELOG.md)
- [Advanced Handoff](HANDOFF.md)
- [Build and Review Record](BUILD-AND-REVIEW-RECORD.md)
- [Next Phase Specification](NEXT-PHASE.md)
- [Session Checkpoint](CHECKPOINT-2026-08-08.md)
## Tools
- `inventory_roots` — shows the configured allowlist.
- `summarize_project` — bounded directory structure, file counts, extensions, markers, and representative text-file paths.
- `read_project_file` — reads a small recognized text/project file under an approved root with sensitive-path filtering and redaction.
- `analyze_project` — infers purpose and capabilities from bounded evidence, with confidence, readiness, unknowns, and safety metadata.
It also exposes `ecosystem://policy` as a resource describing the safety model.
## Run locally
```bash
npm install
ECOSYSTEM_ROOTS="$HOME/Documents" npm start
```
The server communicates over MCP stdio. It does not execute project code, mutate files, follow symlink escapes, inspect unconfigured roots, or read arbitrary binary files. Common sensitive paths are excluded and common secret patterns are redacted.
## Package direction
`manifest.json` is MCPB-ready for a future downloadable bundle. Before selling, add signed release artifacts, a privacy policy, support documentation, a second platform test, and a hosted/paid tier only after validating demand.
## Product boundary
The commercial moat should be the interpretation layer: project-purpose extraction, capability overlap, maturity scoring, and actionable productization recommendations. Keep those higher-level features separate from the local filesystem adapter so the product can later support uploaded manifests, Git repositories, or a hosted service.
TDQS
A4.3/5.0
Scored across 4 tools
Disambiguation5/5
Each tool has a clearly distinct purpose: listing roots, summarizing projects, reading files, and analyzing project purpose. There is no overlap or ambiguity between them.
Naming Consistency5/5
All tool names follow the consistent verb_noun pattern in snake_case (inventory_roots, summarize_project, read_project_file, analyze_project). This makes the API predictable and easy to navigate.
Tool Count5/5
With only 4 tools, the server is tightly scoped to its purpose of inspecting and analyzing projects. Each tool is essential and there is no bloat.
Completeness5/5
The tool surface covers the full workflow: discover roots, summarize structure, read specific files, and derive an analysis. No obvious missing operations for the stated domain.
Maintenance
ActivitySlowing
ResponsivenessNo issues