Specification

📄️ 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.

📄️ 4. ToolDriver & Adapter

The ToolDriver as the canonical interface unit

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. 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.

📄️ 7. 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 (i.e., check if the flag exists in meta.capabilities and then dynamically call the corresponding method).

📄️ 8. 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.

📄️ 9. 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.

🗃️ 10 · LLM Prompt Patterns

1 item

📄️ 11. 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.

📄️ 12. 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.

📄️ 13. Versioning & Compatibility

MCS follows Semantic Versioning (MAJOR.MINOR.PATCH) for the specification document itself, ensuring clear evolution while maintaining backward compatibility where possible.

📄️ 14. Next Steps

Core Standard Enhancements (Define in Spec for Consistency Across SDKs)

🗃️ 1. MCS Motivation Overview