Turn MCP usage into learned metadata
AdaptiveMCP is a learning layer over Model Context Protocol (MCP) primitives. It observes how MCP tools are actually used and attaches learned metadata to existing primitives — it does not replace MCP, redefine tools, or add protocol abstractions. Clients adapt from real signal instead of guessing.
Status: experimental. The packages are published, but the API may shift before 1.0.
- 🧩 A learning layer, not a new protocol — observes tool usage and attaches learned metadata to existing MCP primitives.
- 📊 The store is authoritative — all metadata lives in a SQLite store (
node:sqlite); thetools-metadata.yamlview is a derived projection, recomputed whenever metadata changes — never edited by hand. - 🔌 Server governs, client executes — the server publishes a narrow, server-governed resource (
dev.adaptivemcp/tools-metadata); the client reads it, adapts, and reports observations back, degrading gracefully on any host that ignores it. - 💪 Modular, dependency-light packages — all
@adaptivemcp/*libraries are published to npm.
Data always flows in one direction: event → MemoryStore → derived YAML view.
The packages above are the core. They are exercised and documented by sibling projects:
- 📦 adaptive-mcp — the monorepo with the
@adaptivemcp/*sources, runnable examples, and thedev.adaptivemcp/tools-metadataSEP draft. - 🤖 agent — an MCP-native agent host (
@adaptivemcp/agent) that owns both the LLM completion and the tool execution, so the learning loop runs against a real client rather than only synthetic demos. - 🧹 qc — QueryCleaner, a real third-party MCP server (Python) that publishes
dev.adaptivemcp/tools-metadata; the agent drives it end to end in CI. - 📚 adaptivemcp.github.io — the documentation site, adaptivemcp.dev.
- 📚 Docs & examples: adaptivemcp.dev
- 🚀 Getting started: adaptivemcp.dev/guide/getting-started
- 📦 Packages: adaptivemcp.dev/packages
- 🧪 Examples: adaptivemcp.dev/examples
We're just getting started 💪