Skip to content

MCP_RESEARCH.md

Latest commit

 

History

History
152 lines (112 loc) · 5.54 KB

MCP_RESEARCH.md

File metadata and controls

152 lines (112 loc) · 5.54 KB

MCP Integration Research

Date: 2026-01-17
Status: Research only - NOT implementing yet

What We Discovered

GitHub Copilot CLI has native extensibility via MCP (Model Context Protocol):

MCP Features in Copilot CLI

  • Custom MCP servers can be added via --additional-mcp-config
  • Configuration can be inline JSON or from file
  • Multiple MCP servers supported
  • GitHub MCP server ships by default

Command Examples

# Add MCP server inline
copilot --additional-mcp-config '{"mcpServers": {"my-tool": {...}}}'

# Add MCP server from file
copilot --additional-mcp-config @/path/to/config.json

# Chain multiple configs
copilot --additional-mcp-config @base.json --additional-mcp-config @overrides.json

Current Approach (Keep This)

Our SDK wrapper (@barrersoftware/copilot-plugins):

  • ✅ Programmatic plugin system for SDK users
  • ✅ Slash command support
  • ✅ Dynamic plugin loading
  • ✅ Already published and working
  • ✅ Respects pre-release license (no code modifications)

Future Native Integration (If GitHub Wants It)

Two possible paths:

Path 1: SDK Plugin System (Current)

  • Keep as-is: wrapper around SDK
  • Users: Developers building apps with the SDK
  • Integration: Programmatic, JavaScript/TypeScript

Path 2: MCP Server Plugins (Native CLI)

  • Build plugins as MCP servers
  • Users: CLI users who want to extend Copilot CLI
  • Integration: Native, any language (MCP is language-agnostic)

Path 3: Hybrid (Best of Both)

  • SDK wrapper for programmatic use
  • MCP server option for CLI use
  • Same plugin logic, two interfaces

Next Steps (When Ready)

IF GitHub expresses interest in native integration:

  1. Study MCP Protocol

  2. Build MCP-Compatible Plugins

    • Convert our plugin system to MCP server format
    • Test with --additional-mcp-config
    • Maintain backward compatibility with SDK wrapper

  3. Propose to GitHub

    • Show both approaches working
    • Let them choose integration path
    • Offer to relicense for official inclusion

Why NOT Build This Yet

  • ✅ Wrapper works - Don't over-engineer
  • ✅ License respect - Study only, no modifications
  • ✅ Wait for demand - Ship MVP first, iterate based on feedback
  • ✅ Their decision - Let GitHub guide integration approach

References

Important Discovery

The CLI relies on the SDK as a dependency! This means:

  • ✅ We already know the SDK - That's what our plugin system wraps
  • ✅ No need to study CLI internals - The SDK is the core interface
  • ✅ Our wrapper is SDK-native - We're already at the right abstraction level
  • ✅ CLI repo has no source - Just installer and docs (binary distribution)

Implication: Our SDK-based plugin system is already positioned perfectly. The CLI uses the same SDK we're wrapping, so our plugins work at the foundational level.

Perfect Adoption Path

If GitHub wants to integrate this natively, they can:

  1. Add our plugin system to @github/copilot-sdk (the SDK package)
  2. CLI automatically benefits - Because @github/copilot depends on the SDK
  3. Zero CLI changes needed - No modifications to the CLI code
  4. Purely additive - Existing SDK users keep working, new users get plugins
  5. 610 lines of code - Small, focused, easy to review and merge

This is why we built at the SDK layer instead of trying to modify the CLI:

  • SDK is the foundation both the CLI and programmatic users share
  • Adding features to the SDK cascades to all consumers
  • No breaking changes, no architectural rewrites
  • GitHub can adopt without disrupting their CLI

Strategic Implications (POWERFUL!)

MASSIVE DISCOVERY: Since the CLI uses the SDK natively, plugins at the SDK layer can:

✅ Fix CLI bugs - Intercept and patch issues before CLI processes them
✅ Add CLI features - Enhance behavior at the foundation layer
✅ Work around limitations - Community can patch problems without waiting for GitHub releases
✅ Debug CLI issues - Full visibility into SDK layer for troubleshooting
✅ Extend the ecosystem - Any tool using the SDK gets plugin benefits

Example: Fixing a hypothetical CLI bug via plugin

class CLIBugFixPlugin {
  async onAfterReceive(context, response) {
    // Patch known issue at SDK layer
    if (response.data.buggyBehavior) {
      response.data.buggyBehavior = fixedValue;
    }
    return response;
  }
}

This positioning is incredibly powerful:

  • Community can fix issues faster than GitHub releases
  • Plugins become a testing ground for CLI features
  • SDK layer acts as a "patch layer" for the ecosystem
  • Users don't have to wait for official fixes

Note: This power comes with responsibility. We document it to show GitHub the value, not to encourage working around them. The goal is partnership, not circumvention.

Bottom Line: We're ready for native integration IF GitHub wants it, but our current wrapper is solid and respects all licenses. Research complete, implementation on hold pending demand.

🏴‍☠️ - Captain CP