Feature: Enable MCP use

I would like my Squad to be able to interact with MCP services and follow the configuration of an mcp.json file. This will enable the Squad to interact with many services that provide this endpoint.

This could allow the Squad to review logs and metrics in the Aspire dashboard while testing deployments.

A key MCP that I'd like the Squad to be able to connect to is Trello.

@csharpfritz

Thanks for the feature request, @csharpfritz! This is a great signal — your video work on Squad validated a lot of our assumptions, and MCP integration is a natural next direction.

I've written up a proposal (034-mcp-integration.md) covering the architecture for this. Here are the key points:

The Goal: Squad agents can use MCP services (Trello, Aspire, Slack, custom APIs) configured in mcp.json. This unlocks:

Trello board management for roadmap/planning work alongside GitHub Issues
Aspire dashboard monitoring during deployments (metrics, logs, validation)
Any other MCP service your team uses

The Approach: We think the Copilot platform already injects MCP tools automatically — you configure mcp.json, agents get access. But agents don't know what's available. The proposal adds:

MCP Discovery — coordinator reads mcp.json at session start, lists available tools to agents
Smart Routing — agents know which MCP tools exist and can decide when to use them
Ceremony Hooks — workflows like deployment validation include MCP checks (e.g., \check Aspire metrics before marking done)

No new npm dependencies (stays zero-dependency), all prompt-level changes.

Before we commit, I need to validate one thing: does the Copilot platform automatically make MCP tools available when configured in mcp.json? That's a quick spike (WI-1 in the proposal) — if yes, we're good to go. If no, we adjust.

For Your Feedback:

Are Trello board sync + Aspire monitoring the right priorities?
Any other MCP services you'd want to connect?
Does the discovery/awareness approach feel right, or would you want more ceremony structure upfront?

Let me know your thoughts. This could fit v0.3.0 Wave 2 or v0.4.0 depending on what we learn from the platform validation spike.

Yes, it automatically makes MCP tools available when they're wired up in a variety of the JSON files on disk; either in the user root, the workspace root, and so on. This is a well-documented pattern. I think you would need to restart the Copilot instance to get the MCP, unless that's been updated since I last tried it. The team should do more research and experimentation to figure out what we can do.

@csharpfritz

Full Proposal: 034 — MCP Integration for Squad Agents

Click to expand full proposal text

Proposal 034: MCP Integration for Squad Agents

Author: Keaton (Lead)
Date: 2026-02-11
Status: Draft
Requested by: @csharpfritz via GitHub Issue #11
Builds on: Proposal 032a (Provider Abstraction), 032c (Label Taxonomy), Platform Capabilities Analysis
Version target: v0.3.0 or v0.4.0 (see Priority Recommendation below)

1. Vision

Fritz (@csharpfritz) has requested that Squad agents be able to interact with MCP (Model Context Protocol) services configured in mcp.json. This would enable Squad to:

Connect to Trello — manage boards, cards, and workflows alongside GitHub Issues
Monitor Aspire dashboards — review logs and metrics during deployments
Extend to any MCP service — external tools that expose MCP endpoints

The current state: Squad agents can use tools only through the GitHub Copilot platform. The platform itself supports MCP tools when configured in the user's environment, but Squad has no awareness of what MCP tools are available or how to route agents to use them.

The core question this proposal answers: Does Squad need to do anything special to use MCP tools, or does the Copilot platform already make them available automatically?

2. Problem Statement

2.1 Current Constraint

Squad agents spawn through the GitHub Copilot CLI with access to a fixed set of tools (grep, glob, view, shell, etc.). When the user configures MCP services in their mcp.json, those tools become available to the Copilot platform globally.

The gap: Squad agents don't know what MCP tools are available. They can't:

Discover available MCP capabilities (Trello, Aspire, database connectors, etc.)
Route work intelligently ("The monitoring team should check Aspire, not GitHub Issues")
Document which MCP integrations enable which workflows

2.2 Use Cases Driving This

Trello Integration (Primary):

Teams using Trello for roadmap/project management alongside GitHub Issues
Squad could synchronize priorities between Trello and GitHub
Agents could create Trello cards for non-code work (design, content, marketing)

Aspire Dashboard Monitoring (Primary):

During deployments, agents could check Aspire metrics to validate success
Log review during incident response without leaving the CLI
Real-time observability for CI/CD pipelines

Secondary Use Cases:

Jira integration for teams in hybrid Jira/GitHub shops
Slack notifications from agent work
Database query tools (e.g., Snowflake, BigQuery)
Custom internal APIs exposed via MCP

2.3 Architectural Constraint: Zero Dependencies

Squad has zero npm dependencies by design. This constraint applies to MCP integration:

Squad cannot npm install MCP client libraries
Squadron cannot shell out to mcp-cli or similar package-based tools
MCP discovery and interaction must work through the GitHub Copilot platform OR the gh CLI

3. Technical Assessment

3.1 Three Architecture Options

Option A: Platform-Native (Zero Work)

Hypothesis: The Copilot platform already injects MCP tools into the agent's context if they're configured in mcp.json. Squad does nothing special.

How it works:

User configures mcp.json in their project
User runs copilot with Squad
Copilot platform automatically makes those MCP tools available to spawned agents
Agents call MCP tools the same way they call gh CLI tools — through the platform

Evidence:

The Copilot platform is the MCP host — it reads mcp.json and connects to services
When agents spawn, they inherit the platform's tool context
No special "MCP discovery" is needed — the platform handles it transparently

Work Required: 0 hours. Maybe a doc update ("MCP tools work automatically if configured in mcp.json").

Risk: If the platform doesn't automatically inject MCP tools, this fails silently — agents try to use an MCP tool and get "tool not found."

Option B: Awareness Layer (Low Effort)

Hypothesis: MCP tools ARE available, but agents don't know about them. Adding discovery improves UX and routing.

How it works:

At session start, Squad reads mcp.json from the project root
Extracts the list of available MCP tools (e.g., trello:createCard, aspire:queryMetrics)
Passes this list to agent spawn prompts so they know what's available
Optionally adds an MCP discovery section to routing.md

Implementation:

# Coordinator reads mcp.json at init
mcp_tools=$(jq '.mcpServers | keys' < mcp.json 2>/dev/null || echo '[]')

# Pass to agent spawn
copilot task --prompt "Available MCP tools: $mcp_tools. Route work accordingly."

Work Required: 4-6 hours. Prompt engineering in squad.agent.md + optional routing.md updates.

Benefit: Agents have explicit knowledge of what's available. Lead can route work to the right agent knowing Aspire/Trello tools exist.

Option C: Routing Integration (Medium Effort)

Hypothesis: MCP tools matter enough to affect how work gets routed and executed.

How it works:

Do everything in Option B (awareness)
Extend routing.md with MCP tool → agent mappings
Add MCP-specific ceremony hooks (e.g., "agent checks Aspire before deployment concludes")
Document MCP workflows alongside GitHub Issues workflows

Implementation:

# routing.md additions

## MCP Tool Routing

| MCP Service | Primary Agent | Use Cases |
|-------------|--------------|-----------|
| `trello:*` | Lead | Priority sync, roadmap tracking |
| `aspire:*` | Fenster (Infra) | Deployment monitoring, metrics review |
| `slack:*` | Scribe | Async notifications, summaries |

## Deployment Ceremony (with MCP)

1. Core Dev deploys
2. Tester validates
3. Lead checks Aspire metrics (if available)
4. Scribe posts status to Slack (if available)

Work Required: 8-12 hours. Awareness layer + ceremony design + documentation + testing.

Benefit: MCP-aware workflows become first-class. Agents know when to use what tool.

3.2 Copilot Platform Behavior: Critical Unknown

THIS IS THE GATE. Before proceeding beyond documentation, we need to validate:

Q1: When mcp.json is configured, does the Copilot CLI automatically inject MCP tools into spawned agents' context?

Q2: Can an agent reference an MCP tool by name (e.g., call mcp:trello:createCard)? Or does it need special syntax?

Q3: What does MCP tool failure look like to an agent? Graceful error, or silent "tool not found"?

Q4: Can agents discover available MCP tools at runtime, or must we read mcp.json ourselves?

These answers determine which option we pursue:

If Q1=yes and Q2/Q3 are graceful: Option A works, we just document
If Q1=yes but discovery is opaque: Option B adds visibility
If Q1=yes but ceremonies benefit from awareness: Option C adds workflows

3.3 Zero-Dependency Constraint Is Satisfied

Copilot platform is the MCP host: We don't import MCP libraries
Agent spawning is unchanged: The task tool already passes context to agents
mcp.json reading is trivial: jq is already available on all platforms Squad targets

No new npm dependencies required in any option.

3.4 Provider Abstraction (032a) Implications

Proposal 032a defines provider abstraction as command-template-level, not code-level. MCP integration fits this model:

// Pseudo-code — not actual implementation
function hasCapability(capability) {
  // Check if MCP tool is available
  return mcp_tools.includes(capability);
}

// Coordinator checks before routing
if (!hasCapability("trello:createCard")) {
  // Route to GitHub Issues instead, or inform user
}

No code-level changes needed. This is all prompt-level logic in squad.agent.md.

4. Recommended Approach: Option B + Documentation

Rationale:

Option A risks silent failures. If the platform doesn't auto-inject, agents will fail mysteriously.
Option B adds safety and UX. Explicit discovery prevents surprises and enables smarter routing.
Option C is premature. Ceremonies should emerge from real usage, not speculation.
Zero-dependency maintained. jq parsing of mcp.json is trivial.

Scope: 4-6 hours, primarily prompt engineering. Ship as part of v0.3.0 Wave 2 or v0.4.0.

5. Implementation Plan

Phase 1: Platform Behavior Validation (Prerequisite)

Owner: Lead (Keaton) + Brady
Effort: 2-3 hours (spike)
Gate: Do NOT proceed to Phase 2 until this answers Q1-Q4 above

Acceptance Criteria:

Test MCP tool availability with a simple Copilot CLI session
Confirm mcp.json is read automatically and tools are available
Document the platform behavior in .ai-team/agents/keaton/history.md
Assess risk — if platform behavior is uncertain, escalate

Phase 2: MCP Discovery in Coordinator (If Phase 1 Is Clear)

Owner: Verbal (Prompt Engineer)
Effort: 3-4 hours
Dependencies: Phase 1 gate passed

Add to squad.agent.md coordinator:

At session start: Read mcp.json and extract available services
In agent spawn prompts: Include a section: "Available MCP tools: [list]"
In routing logic: If an agent should use an MCP tool, remind it of the tool name and basic usage

Code changes: ~40-60 lines of prompt text. Zero JavaScript changes.

Acceptance Criteria:

Coordinator reads and parses mcp.json (handle missing file gracefully)
Agent spawn prompts include MCP tool list
Routing decisions reference MCP availability
Error handling: if mcp.json is malformed, coordinator warns user but continues

Phase 3: Routing Extensions (Optional, Phase 2+)

Owner: Keaton (Lead)
Effort: 2-3 hours
Dependencies: Phase 2 complete, real usage data

Update routing.md with:

MCP Tool → Agent Matrix: Which agents should use which MCP tools
Ceremony hooks: When to invoke MCP tools (e.g., "post-deployment check Aspire")
Examples: Trello sync workflow, Aspire monitoring during deployments

Acceptance Criteria:

routing.md updated with MCP section
At least one ceremony (e.g., Deployment) includes MCP steps
Documentation in docs/features/mcp-integration.md (if ship as feature)

6. Work Items

WI-1: MCP Platform Behavior Spike

Agent: Keaton (Lead)
Size: 2-3 hours
Priority: P0 (blocking all other work)
Dependencies: None

Validate Copilot platform MCP support:

Run a simple session with mcp.json configured
Attempt to use an MCP tool from an agent prompt
Document results in history.md
Assess: proceed to WI-2, defer, or escalate to Brady

Acceptance Criteria:

Test session completed and documented
Q1-Q4 answered with evidence
Decision recorded in history.md

WI-2: MCP Discovery Prompt Engineering

Agent: Verbal (Prompt Engineer)
Size: 3-4 hours
Priority: P1 (if WI-1 is green)
Dependencies: WI-1 complete

Implement MCP discovery in squad.agent.md:

Parse mcp.json at session start
Build available tools list
Pass to agent spawn contexts

Acceptance Criteria:

mcp.json is parsed correctly
Available tools list is passed to agents
Error handling works (missing/malformed mcp.json)
Tested in a session with Trello MCP configured

WI-3: Routing Documentation

Agent: Keaton (Lead)
Size: 2-3 hours
Priority: P2 (ship after WI-2)
Dependencies: WI-2 complete

Update routing.md and create user-facing docs:

MCP tool → agent mapping
Ceremony examples (Trello, Aspire, Slack)
Configuration walkthrough

Acceptance Criteria:

routing.md includes MCP section
At least one ceremony with MCP steps documented
docs/features/mcp-integration.md created
Examples: Trello board sync, Aspire dashboard check

7. Fritz's Use Cases as Success Metrics

Trello Board Sync

Scenario: Fritz's team uses Trello for roadmap, Squad uses GitHub Issues for code work.

Success: An agent can:

Query Trello board state
Create a Trello card from a GitHub issue
Sync priorities between Trello and GitHub

Implementation: Lead routes high-level planning tasks to Trello; development tasks to GitHub. Example ceremony:

## Feature Request Triage (GitHub + Trello)

1. User files issue on GitHub
2. Lead reviews: is this code work or planning work?
3. If code: `squad` label, normal GitHub workflow
4. If planning: create Trello card, add to roadmap board

Aspire Dashboard Monitoring

Scenario: CI/CD pipeline deploys with Squad. Deployment needs validation.

Success: An agent can:

Query Aspire metrics during deployment
Validate success criteria (e.g., "error rate < 1%")
Decide to rollback or continue

Implementation: Tester/Infra agent checks Aspire metrics before marking deployment done. Example ceremony:

## Deployment Validation (with Aspire)

1. Core Dev deploys to staging
2. Tester runs integration tests
3. Tester OR Lead checks Aspire metrics (if available)
   - Query error rates, latency, resource usage
   - Validate success criteria
4. If green: promote to prod
5. If red: rollback with Aspire context in incident log

8. What We're NOT Doing (v0.3.0/v0.4.0)

No MCP server hosting. Squad doesn't run its own MCP servers. We only consume existing services.
No MCP authentication management. Users configure auth in mcp.json. We read, don't manage.
No custom MCP service development. That's beyond Squad's scope.
No mandatory MCP setup. MCP integration is opt-in. Squad works perfectly without mcp.json.
No MCP-specific ceremony hardcoding. Ceremonies are examples; users adapt them.

9. Risks

Risk	Likelihood	Impact	Mitigation
Copilot platform doesn't auto-inject MCP tools	Medium	High	WI-1 spike answers this; if yes, reassess or escalate
`mcp.json` parsing fails silently	Low	Medium	Robust error handling, coordinator warns user
MCP tool names/signatures vary by service	Medium	Low	Prompt examples, documentation for each service
User forgets `mcp.json` configuration	High	Low	Documentation, error message when tool not found
Agents overuse MCP tools (e.g., spam Trello)	Low	Medium	Usage guidelines in routing.md and prompt examples

10. Relationship to Issue #11

@csharpfritz's request is clear and well-motivated. This proposal:

Validates the direction — MCP integration aligns with Squad's GitHub-native + provider-agnostic strategy
Clarifies the architecture — MCP tools should already be available via the platform; we add visibility and routing
Prioritizes Fritz's use cases — Trello and Aspire are the design drivers
Defers speculation — WI-1 spike validates platform behavior before we commit to ceremonies
Keeps zero-dependencies — all implementation is prompt-level, no npm additions

The proposal is pragmatic: do the minimum (awareness layer) that unlocks both use cases without committing to ceremonies we haven't validated yet.

11. Priority Recommendation

Recommended: v0.3.0 Wave 2 or v0.4.0 Wave 1, depending on WI-1 results.

Reasoning:

Wave 1 (v0.3.0): GitHub-native proposals (032) and CCA adoption are the priority. MCP is additive.
Wave 2 (v0.3.0): If WI-1 shows platform auto-injection works, add MCP discovery (3-4 hours, low risk).
Wave 1 (v0.4.0): If WI-1 shows platform behavior is uncertain, defer to v0.4.0 and resolve platform questions first.

For Brady's call: Is Fritz's request urgent enough to pull into v0.3.0, or is v0.4.0 acceptable? My recommendation leans v0.4.0 (let proposal/CCA ship first), but if Brady wants MCP visible to users sooner, v0.3.0 Wave 2 is feasible.

12. Decision Required

For Brady:

Approve this direction? (Platform-aware, discovery-focused, Trello/Aspire use cases as drivers)
Authorize WI-1 spike? (2-3 hours to validate Copilot platform MCP support)
v0.3.0 or v0.4.0? (Depends partly on WI-1 results and your sense of urgency)

For Fritz (@csharpfritz):

Validate our understanding — is Trello board sync + Aspire monitoring the right scope?
Share any other MCP services you'd prioritize alongside these two
Feedback on approach — does awareness/discovery feel like the right level, or do you need more ceremony guidance?

This proposal was created by Squad in response to GitHub Issue #11 by @csharpfritz.

I think the GitHub and Azure MCP services are also good first party services we should ensure work. Its a bit of a problem that we auth Copilot CLI and that doesn't give us access tokens to work with the GitHub MCP.

Awareness and discovery work nicely and fit with allowing us to work outside the squad with other agents

🚦 Sprint Plan: MCP Integration — GO for v0.4.0

Research phase complete. We have clarity on the architecture and remaining work.

What We Learned

From Brady: MCP tools automatically inject when configured via mcp.json — the plumbing exists. The team needs to focus on awareness (how agents discover tools) and documentation (how users configure them).

From Fritz:

GitHub and Azure MCP services are good first-party targets for validation
Auth is a real blocker — Copilot CLI auth doesn't provide access tokens that GitHub MCP expects
Discovery and awareness patterns work well in current implementation

Key Insight: This isn't about building MCP support — it's already there. This is about making it discoverable, routable, and documented.

Work Items

WI-1: MCP Discovery Mechanism

Owner: Verbal
What: Design how the coordinator discovers available MCP tools at session start and incorporates them into routing decisions
Acceptance Criteria:

Coordinator can enumerate MCP tools from configured servers
Tool metadata (name, description, parameters) is accessible for routing logic
Discovery happens once per session (performance consideration)

WI-2: Charter MCP Awareness

Owner: Verbal
What: Update agent spawn templates so agents receive MCP tool availability context
Acceptance Criteria:

Agent prompts include "Available MCP tools: [list]" when tools are configured
Templates clearly indicate which MCP servers are active
Agents understand when to delegate to MCP vs. built-in tools

WI-3: Sample mcp.json Configs

Owner: Fenster
What: Create reference configurations for GitHub MCP, Azure MCP, and Trello
Acceptance Criteria:

Three working sample configs in �xamples/mcp/
Each includes inline comments explaining required fields
Configs are tested against their respective MCP servers

WI-4: User-Facing Documentation

Owner: McManus
What: Write "Using MCP Tools with Your Squad" guide
Acceptance Criteria:

Explains what MCP is and why users would want it
Step-by-step setup for adding an MCP server to Squad
Includes at least one end-to-end example (GitHub or Azure recommended)
Links to sample configs from WI-3

WI-5: Auth Documentation

Owner: McManus
What: Document auth token scope requirements and known limitations
Acceptance Criteria:

Clearly flags Fritz's concern: Copilot CLI auth ≠ GitHub MCP auth
Explains workarounds where they exist (e.g., personal access tokens, OAuth flows)
Sets user expectations about which MCP servers may require additional auth setup
Includes troubleshooting section for common auth failures

WI-6: squad.agent.md Updates

Owner: Verbal
What: Update coordinator governance doc with MCP routing and discovery patterns
Acceptance Criteria:

New section: "MCP Tool Routing"
Describes how coordinator decides between built-in and MCP tools
Includes decision flowchart or pseudocode
Covers error handling when MCP servers are unreachable

Known Limitations (v0.4.0 Scope)

Auth Challenge: Per Fritz's observation, Copilot CLI's authentication model doesn't automatically grant access tokens for MCP servers like GitHub MCP. This will require users to provide their own auth tokens for certain MCP integrations. We'll document this clearly in WI-5 rather than attempt to solve it in this sprint.

Dependencies

WI-2 depends on WI-1 (need discovery design before updating templates)
WI-4 depends on WI-3 (docs reference the sample configs)
WI-6 depends on WI-1 (governance reflects actual implementation)

Parallel tracks:

WI-1 + WI-3 can start immediately
WI-5 can start immediately (auth research is independent)

Timeline Recommendation

Sprint target: 2 weeks

Week 1: WI-1, WI-3, WI-5 (discovery, samples, auth research)
Week 2: WI-2, WI-4, WI-6 (awareness, user docs, governance)

— 🏗️ Keaton (Lead) · Posted by Squad

@csharpfritz

MCP Integration — Design Proposal from Verbal (Prompt Engineer)

I've done a deep dive into how MCP actually works with Squad's architecture. Here's what I found and what I'm proposing.

The Key Insight: Squad Already Has MCP — Agents Just Don't Know It

MCP servers configured in the user's Copilot environment (.copilot/mcp-config.json, .vscode/mcp.json, etc.) are automatically injected as available tools at session start. The GitHub MCP server in this repo is proof — it's already active in every Squad session. The issue isn't "enable MCP" — it's "teach agents what MCP tools are available and how to use them."

This fits perfectly with Squad's prompt-level architecture. Zero dependencies, zero runtime changes.

Architecture: Three Layers

Layer 1 — MCP Discovery Skill (shipped today)

Created .ai-team/skills/mcp-tool-discovery/SKILL.md — a comprehensive skill that teaches agents:

How to detect which MCP tools are in their context
Domain-specific usage patterns for Trello, Aspire, GitHub, Azure, Notion
Graceful degradation when tools are missing (never crash, always fall back)
How to guide users through MCP configuration

This follows the same pattern as the human-notification skill — Squad teaches the pattern, users bring the infrastructure.

Layer 2 — Coordinator MCP Context Injection (WI-2, next sprint)

When spawning agents, the coordinator enumerates available MCP tools and injects a block into spawn prompts:

MCP TOOLS AVAILABLE IN THIS SESSION:
- GitHub MCP: ✅ (issues, PRs, code search, actions)
- Trello MCP: ✅ (boards, cards, lists)
- Aspire MCP: ❌ (not configured)

This eliminates per-agent discovery overhead. Agents know immediately what's available.

Layer 3 — User Documentation (WI-4/WI-5)

Setup guides for configuring MCP servers with Squad. Includes auth limitations — Fritz flagged this: Copilot CLI auth ≠ GitHub MCP auth. Users may need separate tokens for certain MCP servers.

Platform Constraint: Sub-Agent MCP Inheritance

This is the biggest finding from the research. Sub-agents spawned via the task tool may NOT inherit MCP tools from the parent session. This is a platform-level limitation (tracked upstream in both Copilot CLI and Claude Code repos).

What this means for Squad:

The coordinator (parent session) has full MCP access ✅
Spawned agents via task tool may not have MCP access ⚠️
explore sub-agents definitely don't have MCP access ❌

Design response: For MCP-dependent operations, the coordinator should either:

Handle the MCP calls directly before spawning agents (pre-fetch data)
Verify tool availability in the sub-agent's context
Instruct agents to fall back to CLI equivalents (gh, az, etc.)

This constraint may be resolved by future platform updates. The skill patterns work unchanged when that happens.

Fritz's Use Cases — How They'd Work

Trello (@csharpfritz's top request):

User configures Trello MCP server in .copilot/mcp-config.json
Coordinator detects trello_* tools at session start
When user says "sync my issues to Trello" → coordinator routes to an agent with Trello MCP context
Agent reads Trello board state, maps GitHub issue statuses to Trello columns, creates/moves cards

Aspire Dashboard:

User configures Aspire MCP server
After deployment, agent queries aspire_check_health, aspire_get_metrics
Reports: "Deployment healthy — error rate 0.1%, p99 latency 45ms"
If unhealthy: pulls logs via aspire_get_logs and surfaces the problem

GitHub MCP (@csharpfritz also flagged this):

Already working. Squad's existing pattern: MCP for reads, gh CLI for writes.
Auth gap is real — Copilot CLI auth token may not satisfy GitHub MCP's token requirements. Documented in WI-5.

Azure MCP:

Same pattern. Configure the server, agents detect azure_* tools, use them for resource monitoring/management.

What's in Scope for v0.4.0

Work Item	Owner	Status	Description
WI-1: Discovery Skill	Verbal	✅ Done	`.ai-team/skills/mcp-tool-discovery/SKILL.md`
WI-2: Coordinator Context Injection	Verbal	🔜 Next	Add MCP tool enumeration to spawn templates
WI-3: Sample Configs	Fenster	🔜 Planned	Reference `mcp-config.json` files for GitHub, Trello, Azure
WI-4: User Documentation	McManus	🔜 Planned	"Using MCP Tools with Your Squad" guide
WI-5: Auth Documentation	McManus	🔜 Planned	Token scope requirements and known limitations
WI-6: squad.agent.md Updates	Verbal	🔜 Planned	MCP routing section in coordinator

What's Post-v0.4.0

Domain-specific MCP skills (Trello workflows, Aspire monitoring ceremonies)
MCP tool → agent routing rules in routing.md
Two-way MCP interactions (receiving events, not just calling tools)
Platform inheritance improvements (when Copilot CLI supports sub-agent MCP)

Why This Approach

Squad's MCP strategy follows the same principle as notifications: Squad teaches the pattern, users bring the infrastructure. We don't ship Trello connectors. We don't manage MCP server lifecycle. We teach agents how to detect what's available and use it intelligently.

This means Squad scales with the MCP ecosystem — every new MCP server that ships is automatically usable by Squad agents. No Squad release required. The skill system is the multiplier.

— ⚛️ Verbal (Prompt Engineer) · Squad

docs: MCP setup guide, notifications update, plugin marketplace guide (…

test: add tests for MCP config and plugin marketplace (#11, #29)

feat: MCP integration support in coordinator and CLI (#11)

Delivered in PRs #38 (docs), #39 (tests), #40 (coordinator + CLI). MCP Integration section in squad.agent.md, sample .copilot/mcp-config.json on init, step-by-step setup guide at docs/features/mcp.md, and 10 MCP config tests.

docs(guides): add squad template patterns and role mapping guides

Feature: Enable MCP use #11

Description

Activity

bradygaster commented on Feb 11, 2026

bradygaster commented on Feb 11, 2026

bradygaster commented on Feb 11, 2026

Full Proposal: 034 — MCP Integration for Squad Agents

Proposal 034: MCP Integration for Squad Agents

1. Vision

2. Problem Statement

2.1 Current Constraint

2.2 Use Cases Driving This

2.3 Architectural Constraint: Zero Dependencies

3. Technical Assessment

3.1 Three Architecture Options

Option A: Platform-Native (Zero Work)

Option B: Awareness Layer (Low Effort)

Option C: Routing Integration (Medium Effort)

3.2 Copilot Platform Behavior: Critical Unknown

3.3 Zero-Dependency Constraint Is Satisfied

3.4 Provider Abstraction (032a) Implications

4. Recommended Approach: Option B + Documentation

5. Implementation Plan

Phase 1: Platform Behavior Validation (Prerequisite)

Phase 2: MCP Discovery in Coordinator (If Phase 1 Is Clear)

Phase 3: Routing Extensions (Optional, Phase 2+)

6. Work Items

WI-1: MCP Platform Behavior Spike

WI-2: MCP Discovery Prompt Engineering

WI-3: Routing Documentation

7. Fritz's Use Cases as Success Metrics

Trello Board Sync

Aspire Dashboard Monitoring

8. What We're NOT Doing (v0.3.0/v0.4.0)

9. Risks

10. Relationship to Issue #11

11. Priority Recommendation

12. Decision Required

csharpfritz commented on Feb 11, 2026

bradygaster commented on Feb 13, 2026

🚦 Sprint Plan: MCP Integration — GO for v0.4.0

What We Learned

Work Items

WI-1: MCP Discovery Mechanism

WI-2: Charter MCP Awareness

WI-3: Sample mcp.json Configs

WI-4: User-Facing Documentation

WI-5: Auth Documentation

WI-6: squad.agent.md Updates

Known Limitations (v0.4.0 Scope)

Dependencies

Timeline Recommendation

bradygaster commented on Feb 13, 2026

MCP Integration — Design Proposal from Verbal (Prompt Engineer)

The Key Insight: Squad Already Has MCP — Agents Just Don't Know It

Architecture: Three Layers

Platform Constraint: Sub-Agent MCP Inheritance

Fritz's Use Cases — How They'd Work

What's in Scope for v0.4.0

What's Post-v0.4.0

Why This Approach

bradygaster commented on Feb 13, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions