🗃️ 1. MCS Motivation Overview
1 item
📄️ 2. Core Idea
MCS defines a thin glue layer between a Language Model and any existing interface such as REST, GraphQL, CAN-Bus, EDI, or even filesystems.
🗃️ 3. Minimal Driver Contract
1 item
📄️ 4. ToolDriver & Adapter
The ToolDriver as the canonical interface unit
📄️ 5. Orchestrator
An Orchestrator is a router in its core, but an interface author at the end. It constructs a new, curated tool interface by aggregating tools from multiple ToolDrivers, resolving name collisions, setting priorities, enriching descriptions, and deciding the order and density of tools presented to the LLM.
📄️ 6. Decorators
The Orchestrator showed the first kind of composition:
📄️ 7. Configuration & Instantiation
All driver configuration happens via the constructor. URLs, auth tokens, proxies, adapter selection, connection parameters -- everything a driver needs is passed at creation time. This decouples configuration from functionality and keeps the client agnostic: it does not need to know what a specific driver requires internally.
📄️ 8. Optional Capabilities
MCS keeps the base contract tiny. Optional behavior is signaled via capability flags in DriverMeta. Consumers must feature-detect before invoking an optional method: check that the flag is present in meta.capabilities, then call the method on the layer that resolvecapability returns — *not necessarily on the driver instance you hold*, since a decorator delegates the interface but not arbitrary methods. The client-side pattern below shows the full detect → resolve → call sequence.
📄️ 9. Autostart Convention
MCS uses established interfaces directly -- HTTP endpoints that already run on servers, local libraries called in-process. There is no need to start an extra server just to talk to a tool. You would never spin up a FastAPI server to access the local filesystem, yet that is exactly what MCP does with its STDIO-based servers. MCS eliminates that layer entirely.
📄️ 10. Security, Usability and Integration
MCS is intentionally not a security framework. Its goal is to connect LLMs to external systems directly and minimally by reusing established technologies (HTTP, OpenAPI, OAuth, Docker, ...) instead of inventing a new protocol stack.
🗃️ 11 · LLM Prompt Patterns
1 item
📄️ 12. Ecosystem and Division of Labor
The previous sections describe individual building blocks: the driver contract, the ToolDriver, the adapter pattern, the orchestrator, prompt patterns, and self-healing. This section explains what they enable together.
📄️ 13. Relation to MCP
MCS does not compete with MCP directly. It generalizes the same idea of standardizing LLM external system connections without imposing a new wire protocol or stack. MCP updates in 2025 (e.g., streamable HTTP transport, OAuth Resource Servers with mandatory Resource Indicators per RFC 8707) have improved its robustness, but vulnerabilities persist. Mostly because of the new protocol stack. MCP uses it and MCS shows that this is not needed.
📄️ 14. Versioning & Compatibility
MCS follows Semantic Versioning (MAJOR.MINOR.PATCH) for the specification document itself, ensuring clear evolution while maintaining backward compatibility where possible.
📄️ 15. Next Steps
Core Standard Enhancements (Define in Spec for Consistency Across SDKs)