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.

A new division of labor

MCS creates a clear separation between interface definition, prompt optimization, and call execution. This separation produces distinct roles that can develop independently:

Role	Responsibility	AI knowledge required?
ToolDriver developer	Bridges an external system (REST, CAN-Bus, filesystem, ...). Implements list_tools() and execute_tool().	No. Pure technical integration.
Driver author	Wraps a ToolDriver (or builds a standalone driver). Invests in model-specific prompt optimization via get_driver_system_message() and get_function_description().	Yes. Understands LLM behavior, prompt engineering, model-specific quirks.
Prompt engineer	Optimizes prompt configurations for specific model/tool combinations. Can deliver prompt packages that drivers load dynamically (see Section 10).	Yes. Deep expertise in model behavior, but no bridging or app logic.
AI application developer	Builds the client. Picks drivers, calls get_driver_system_message() + process_llm_response(), manages the conversation loop.	Minimal. The driver handles the hard parts.

This is, of course, idealized. In practice, one person often fills multiple roles. But the separation creates flexibility: each layer can improve independently without breaking the others. A better prompt doesn't require a code change in the app. A new transport doesn't require prompt knowledge. A new LLM model doesn't require rewriting the bridge.

Prompt engineering becomes a reusable investment

Today, prompt engineering is fragmented. Every application reinvents the same patterns for the same APIs. Knowledge about what works for which model is scattered across blog posts, Discord threads, and private repositories.

MCS changes this by embedding prompt logic into the driver layer. When someone invests time in optimizing a system prompt for a specific capability/model combination, that investment is encapsulated inside the driver. Every application using that driver benefits immediately -- without any change to application code.

This transforms prompt engineering from a per-project burden into a one-time investment with compounding returns. Combined with the dynamic prompt loading concept (Section 10), prompt configurations become tradeable, versionable artifacts -- similar to firmware that can be loaded at runtime.

Drivers as versionable components

Because MCS drivers follow a standard contract, they can be treated like any other software component:

• Versioned via semver and published to package registries (PyPI, npm, crates.io, ...)
• Tested independently with automated test suites
• Deployed via existing CI/CD pipelines and container toolchains
• Composed freely -- mix and match drivers via orchestrators without changing client code

This is fundamentally different from MCP's approach where each API requires a dedicated wrapper server. MCS drivers are libraries, not services. They carry no runtime overhead, no additional network hops, no separate process lifecycle.

No special treatment for LLMs

A key consequence of the MCS approach: the LLM becomes a regular part of the architecture, not a special case.

Because MCS reuses existing transports and standards (HTTP, OAuth2, OpenAPI, ...), all existing infrastructure applies directly:

• API gateways, rate limiting, and access control work unchanged
• OAuth2, API keys, Basic Auth, mTLS -- proven authentication, not reinvented
• Logging and monitoring (ELK, Datadog, Prometheus, ...) capture driver calls like any other library call
• CORS rules, firewalls, and network policies apply as-is
• Test automation, containerization, and deployment pipelines require no LLM-specific tooling

No special middleware, no dedicated protocol servers, no LLM-specific security layer. The LLM integration fits into the existing software architecture like any other module.

What this enables

When these pieces come together, an ecosystem becomes possible:

• Community-driven drivers for common capabilities, tested across models, shared via package registries
• Specialized prompt packages optimized for specific model families, loadable at runtime
• Curated toolset definitions (see Section 10) that cherry-pick API endpoints and provide LLM-optimized descriptions, shareable via git
• A central discovery index (mcs-pkg) that complements existing package managers without being a prerequisite (see below)

Each of these can develop at its own pace, by different people, with different expertise. The driver contract is the stable center that holds it all together.

Package naming convention

Discoverability as the guiding principle

The naming convention exists primarily for discoverability -- on two levels:

1. Package registries (PyPI, npm, crates.io): A developer searches mcs-driver- and immediately finds all available drivers. mcs-driver-rest finds the REST driver, mcs-driver-csv the CSV driver, and so on. The convention ensures that web-based package browsers -- which often cannot evaluate capability metadata -- still deliver meaningful listings.

2. IDE / IntelliSense: Where the language supports namespace packages or similar mechanisms, SDKs should use them so that all installed drivers appear under a shared prefix. In Python: from mcs.driver. lists all installed drivers; from mcs.driver.csv import shows the available classes. Without namespace packages, the developer must know the package name by heart -- with namespaces, the IDE guides them automatically.

The responsibility for language-specific implementation (which namespace mechanisms, which import paths, which file structure) lies with each SDK. The spec defines only the logical prefix scheme.

Six package classes

The naming is capability-based: the driver name carries the capability (what it does for the LLM), not the protocol+transport pair. The transport is the adapter's concern. Orchestrators receive their own prefix because they are a conceptually different category: they do not bridge to an external system but compose other drivers.

Class	Schema	Examples
Driver (default, hybrid: MCSDriver + MCSToolDriver)	mcs-driver-<capability>[-<variant>]	mcs-driver-rest, mcs-driver-csv, mcs-driver-filesystem
Tool-only (bridging only, no LLM parsing)	mcs-driver-<capability>-toolonly[-<variant>]	mcs-driver-imap-toolonly, mcs-driver-smtp-toolonly
Standalone (MCSDriver without separate ToolDriver)	mcs-driver-<capability>-standalone[-<variant>]	mcs-driver-mail-standalone
Orchestrator (aggregates multiple ToolDrivers)	mcs-orchestrator-<strategy>[-<variant>]	mcs-orchestrator-basic, mcs-orchestrator-weighted
Adapter (technical, dependency of a ToolDriver)	mcs-adapter-<source>[-<variant>]	mcs-adapter-localfs, mcs-adapter-http, mcs-adapter-s3
Bundle (dependencies + default config only)	mcs-bundle-<capability>-<source>[-<variant>]	mcs-bundle-filesystem-localfs, mcs-bundle-csv-http

Discovery -- three main prefixes for searching package registries (e.g. on pypi.org):

mcs-driver-         # all drivers (hybrid, toolonly, standalone)
mcs-orchestrator-   # all orchestrators
mcs-adapter-        # all adapters

Design rationale

• Driver type defaults to hybrid (MCSDriver + MCSToolDriver). When a driver only supports one mode, the variant suffix makes this explicit (-toolonly, -standalone).
• [-<variant>] is freely chosen by the author to distinguish implementations, API-specific drivers, or capability restrictions.
• Adapters are purely technical building blocks. Whether they are published as separate packages or kept as internal libraries is an SDK decision -- but when published, they must be clearly recognizable as adapters.
• Bundles are thin packages that pull dependencies and export a default factory. They prevent name explosion when multiple capability+adapter combinations exist (e.g. mcs-bundle-filesystem-localfs instead of a dedicated mcs-driver-filesystem-localfs codebase).

Three naming levels (Spec vs SDK)

Level	Spec defines	SDK defines
Package manager	Logical prefix mcs-driver-<capability>	Mapping to ecosystem (PyPI, npm, crates.io, ...)
Import / module path	--	Language-idiomatic import convention for IDE autocompletion
Class / file naming	--	Internal structure and naming rules for code navigation

The spec only governs the first level (the logical prefix). The import convention and file layout are SDK-internal decisions -- but they are equally important because they determine how developers find and use drivers in their IDE. Predictable import paths enable autocompletion. Each SDK must document its full naming stack (package manager name -> import path -> class/file names) so that all three levels are consistent and discoverable.

Python (illustrative)

Installation:

pip install mcs-driver-rest             # default hybrid (REST-HTTP driver)
pip install mcs-driver-csv             # CSV driver
pip install mcs-driver-filesystem      # filesystem driver
pip install mcs-adapter-localfs        # adapter separately

IDE discovery via namespace packages:

from mcs.driver.rest import RestDriver              # MCSDriver + MCSToolDriver
from mcs.driver.csv import CsvDriver                # type "from mcs.driver." -> IDE lists all
from mcs.adapter.localfs import LocalFsAdapter      # adapter
from mcs.orchestrator.basic import BasicOrchestrator

Python uses implicit namespace packages (PEP 420, Python 3.3+). Each driver installs into mcs.driver.<capability> without conflicts. No __init__.py in src/, src/mcs/, or src/mcs/driver/.

npm (illustrative)

npm install mcs-driver-rest
npm install mcs-adapter-localfs
npm install mcs-bundle-filesystem-localfs

npm has no extras like Python -- bundles are particularly important as the "happy path" installation.

mcs-pkg: a discovery index, not a package manager

MCS does not introduce its own package manager. Drivers are published to existing registries (PyPI, npm, crates.io, ...) and must be discoverable and installable without a central MCS registry from day one.

mcs-pkg is planned as a directory/index -- a thin MCS-specific metadata layer on top of existing registries:

• Links to existing registries (PyPI, npm, GitHub)
• Machine-readable manifest per driver (or automatically extracted from DriverMeta)
• Labels: Verified / Reference / Community
• Compatibility matrix (Contract v0.5 ↔ driver v1.2.3)
• Security notes ("requires shell access", "reads local filesystem")
• Usage examples ("works with these orchestrators / LLMs")

This replaces nothing but adds an MCS-specific view. Each language ecosystem solves discovery through its own SDK and existing package infrastructure. mcs-pkg complements these later but must never be a prerequisite.

Trade-offs and risks

Too many conventions could make the ecosystem feel bureaucratic and raise the barrier to entry. Semantic emulation (e.g. exposing an object store as a filesystem adapter) can lead to surprising behavior when the underlying semantics diverge.

MCS addresses these risks structurally rather than ignoring them:

• Capabilities are cut semantically, not by transport. When two backends have fundamentally different semantics (hierarchical filesystem vs flat key-value store), they get separate ToolDrivers with honest tool descriptions instead of a leaky abstraction.
• Emulation is optional and clearly marked. An S3-backed filesystem adapter is valid but must document its caveats (rename = copy+delete, mkdir = no-op, eventual consistency) through tool descriptions, capability flags, or well-defined errors.
• Orchestrators own UX and conflict resolution. When multiple drivers or adapters interact, the Orchestrator takes responsibility for presenting a coherent interface to the LLM -- including namespacing, prioritization, and description quality.

The standard itself stays lean. SDKs and the directory/index structure handle discoverability and quality without requiring a central authority.