Summary
Cooper currently lacks a reliable way to discover, enumerate, and prioritize Model Context Protocol (MCP) servers that are already configured in a developer’s environment.
Modern MCP setups commonly allow servers to be configured from multiple sources (CLI flags, agent definitions, user config, repository config, defaults), each with well-defined precedence rules. Without understanding this hierarchy, Cooper risks:
Duplicating MCP servers that already exist
Ignoring higher‑priority MCP configurations
Shadowing or overriding active MCP servers unintentionally
Providing an incomplete or misleading view of available tools
This issue proposes adding first‑class MCP discovery with priority awareness so Cooper can interoperate cleanly with existing MCP‑based workflows.
Problem Statement
In real‑world setups, MCP servers are often configured through multiple layers, such as:
Session‑level configuration (e.g. CLI flags)
Agent‑level configuration (agent metadata or frontmatter)
User‑level global configuration
Repository‑level configuration
Implicit or default MCP servers
Each layer may override or extend lower‑priority layers. Today, Cooper does not:
Discover MCP servers across these layers
Understand which MCP definitions are effective vs overridden
Expose MCP metadata (source, scope, type) for decision‑making
This makes it difficult for Cooper to act as a good citizen in MCP‑enabled environments.
Proposed Feature
- MCP Configuration Discovery with Priority Awareness
Add support for discovering MCP servers in priority order, from highest to lowest:
Session‑level MCP servers
MCPs explicitly provided for the active run (e.g. CLI arguments)
Agent‑level MCP configuration
MCPs defined as part of an agent’s configuration or metadata
User‑level global MCP configuration
Persistent MCPs available across projects for a given user
Repository‑level MCP configuration
MCPs shared with a project or team via repo config
Implicit / default MCP servers
MCPs that are automatically available unless overridden
When MCP names collide, higher‑priority definitions override lower‑priority ones, and Cooper should surface the effective configuration.
- MCP Server Type Awareness
Cooper should not assume all MCP servers are the same.
Discovery should preserve and expose MCP server type and launch semantics, such as:
Built‑in MCP servers
Local stdio MCP servers
Proxied MCP servers (e.g. stdio → HTTP)
MCPs launched via external commands or package runners
This metadata is critical for correct reuse, display, and orchestration.
- MCP Discovery Abstraction / API
Introduce an internal (and potentially public) abstraction that:
Enumerates discovered MCP servers
Annotates each MCP with:
Source (session, agent, user, repo, default)
Priority
Effective vs overridden status
Server type / launch method
Provides a stable interface for:
Agent orchestration
Tool selection
CLI or UI inspection
Future MCP registries or marketplaces
Benefits
Prevents MCP duplication and shadowing
Makes Cooper interoperable with existing MCP setups
Improves predictability and debuggability
Enables richer multi‑agent and tool‑driven workflows
Lays groundwork for MCP marketplaces and discovery tooling
Non‑Goals
Dynamically reloading MCP configuration mid‑session
Defining or enforcing precedence rules for other tools
Managing authentication or secrets for MCP servers
Summary
Cooper currently lacks a reliable way to discover, enumerate, and prioritize Model Context Protocol (MCP) servers that are already configured in a developer’s environment.
Modern MCP setups commonly allow servers to be configured from multiple sources (CLI flags, agent definitions, user config, repository config, defaults), each with well-defined precedence rules. Without understanding this hierarchy, Cooper risks:
Duplicating MCP servers that already exist
Ignoring higher‑priority MCP configurations
Shadowing or overriding active MCP servers unintentionally
Providing an incomplete or misleading view of available tools
This issue proposes adding first‑class MCP discovery with priority awareness so Cooper can interoperate cleanly with existing MCP‑based workflows.
Problem Statement
In real‑world setups, MCP servers are often configured through multiple layers, such as:
Session‑level configuration (e.g. CLI flags)
Agent‑level configuration (agent metadata or frontmatter)
User‑level global configuration
Repository‑level configuration
Implicit or default MCP servers
Each layer may override or extend lower‑priority layers. Today, Cooper does not:
Discover MCP servers across these layers
Understand which MCP definitions are effective vs overridden
Expose MCP metadata (source, scope, type) for decision‑making
This makes it difficult for Cooper to act as a good citizen in MCP‑enabled environments.
Proposed Feature
Add support for discovering MCP servers in priority order, from highest to lowest:
Session‑level MCP servers
MCPs explicitly provided for the active run (e.g. CLI arguments)
Agent‑level MCP configuration
MCPs defined as part of an agent’s configuration or metadata
User‑level global MCP configuration
Persistent MCPs available across projects for a given user
Repository‑level MCP configuration
MCPs shared with a project or team via repo config
Implicit / default MCP servers
MCPs that are automatically available unless overridden
When MCP names collide, higher‑priority definitions override lower‑priority ones, and Cooper should surface the effective configuration.
Cooper should not assume all MCP servers are the same.
Discovery should preserve and expose MCP server type and launch semantics, such as:
Built‑in MCP servers
Local stdio MCP servers
Proxied MCP servers (e.g. stdio → HTTP)
MCPs launched via external commands or package runners
This metadata is critical for correct reuse, display, and orchestration.
Introduce an internal (and potentially public) abstraction that:
Enumerates discovered MCP servers
Annotates each MCP with:
Source (session, agent, user, repo, default)
Priority
Effective vs overridden status
Server type / launch method
Provides a stable interface for:
Agent orchestration
Tool selection
CLI or UI inspection
Future MCP registries or marketplaces
Benefits
Prevents MCP duplication and shadowing
Makes Cooper interoperable with existing MCP setups
Improves predictability and debuggability
Enables richer multi‑agent and tool‑driven workflows
Lays groundwork for MCP marketplaces and discovery tooling
Non‑Goals
Dynamically reloading MCP configuration mid‑session
Defining or enforcing precedence rules for other tools
Managing authentication or secrets for MCP servers