Skip to main content
Glama

hve-squad MCP server

An outbound Model Context Protocol (MCP) server that exposes the hve-squad as coarse, model-invocable tools (five per-role intent tools plus squad_federate for the opt-in federation of sub-squads) so MCP hosts can call the squad directly.

This is the outbound inverse of the squad's existing inbound MCP template (squad-src/.github/skills/squad/mcp.template.json, which registers servers the squad consumes). This package ships the squad's own server, which other hosts consume.

Documentation: https://peter-n91.github.io/hve-squad-mcp/ · Contributing: CONTRIBUTING.md · License: MIT ·

Status — what works today (read this first)

This server has two execution modes, at different maturity levels. Be precise about which one a claim refers to.

Mode

Host

State

Behaves as the full APM package?

Delegated (stdio)

VS Code GitHub Copilot (local)

Works

Yes — VS Code dispatches the real deployed cast. Needs the built package + apm install of the cast; install with npx -y @hve-squad/mcp or a local build.

Embedded advisory hero tools (squad_research, squad_review, squad_plan, squad_architect)

Copilot Studio (remote HTTP)

Works, deployable via host/RUNBOOK.md

Advisory parity. Each runs one server-side dispatch via Azure OpenAI, resolving the real from-disk persona from the full bundled cast (91 agents), under Entra auth, gates, tenant isolation and cost caps. Advisory (text) output only — no code execution or deploy.

Embedded async advisory pipeline (squad_run, squad_status)

Copilot Studio (remote HTTP)

Works end-to-end; single-replica (file) or multi-replica (Azure Table)

Advisory parity — full cast, full advisory stages. Data-driven routing runs research → plan → council → review → backlog over the real cast. Advisory (text) only; code-executing implement/deploy is a deferred execution expansion.

Deterministic render (squad_render_pptx)

Copilot Studio (remote HTTP)

Opt-in (SQUAD_MCP_ENABLE_RENDER_PPTX=true)

First file-output tool. Renders content YAML to a .pptx with in-image python-pptx and returns a short-lived Azure Blob user-delegation SAS download link (tenant-scoped path, SAS never logged, Squad.Render fail-closed scope, caller YAML is DATA). No model call.

The async pipeline (squad_run) runs the full advisory squad — data-driven routing over the full bundled cast, sequencing research → plan → (council) → review → backlog-handoff and producing a finished, sectioned advisory artifact. It is advisory parity: finished text deliverables, not code-executing implement/deploy (that is a separate, deferred execution expansion). Specifics:

  • Off by default (SQUAD_MCP_REMOTE_PIPELINE_ENABLED=false); the default remote surface is the advisory hero tools. Enabling the async pipeline requires a durable run-state backend.

  • Full cast + routing. Requests are routed to the real roster roles (researcher → lead → council members → tester) resolved from the SHA-pinned 91-agent cast bundle; the council is task-fit (one seat per lens the request touches) and synthesizes a most-restrictive-wins Council Verdict (Go / Go-With-Conditions / Stop). It honors mode (interactive pauses per stage; autopilot/autonomous run to one compiled artifact).

  • Releasable by an operator. squad_run holds at a non-bypassable Human Gate; an operator with the distinct Squad.Operate app role releases a held run via the out-of-band POST /admin/approve route (never a tools/call), after which a squad_status poll drives it to completion. Approvals are audited (approver + timestamp) and tenant-scoped.

  • Two run-state backends (SQUAD_MCP_RUN_STATE_BACKEND): file (single-replica, local dir) or table (Azure Table Storage, cross-replica ETag compare-and-swap). The table backend + a store-backed approval channel make release visible across replicas, so a multi-replica / scale-to-zero deployment is supported (WI-06). Per-stage artifacts, the Council Verdict, and caller request/context are AES-256-GCM encrypted at rest when a key is configured.

  • Long runs (>240s) are handled by an optional background worker (an ACA Job): with SQUAD_MCP_WORKER_ENABLED=true the status poll is read-only and the worker drives approved runs off the request path (WI-1b4-WORKER).

Bottom line: a consumer can deploy this and get the full package locally in VS Code, the advisory hero tools in Copilot Studio today, and — with the pipeline enabled — the full advisory squad (routing + full cast + council) working end-to-end as an async pipeline, single-replica (file) or multi-replica (Azure Table) with a background worker for long runs. Advisory scope is text deliverables only; code-executing implement/deploy (a real tool-calling backend and a persistent workspace) is a deferred execution expansion — do not represent that part as available.

Distribution: local stdio (delegated) targets VS Code; the remote Streamable HTTP + Entra path (embedded) reaches Copilot Studio and is deployed per host/RUNBOOK.md. M365 Copilot and Cowork are not targeted yet.

Related MCP server: Keshro MCP

The tools

Each per-role tool maps 1:1 to a routing-table intent row in squad-routing.instructions.md (not to one of the ~200 agents); squad_federate maps to the Squad Federation Coordinator and drives the opt-in federation meta layer. The Squad Coordinator owns routing; these tools are shortcuts into it.

Tool

Routing intent

Primary role

Tier

squad_research

research, investigate, explore

Squad Researcher

auto

squad_plan

plan, break down, sequence

Squad Lead

confirm

squad_review

review, validate, check quality (+ council go/no-go)

Squad Reviewer (+ council)

auto / confirm

squad_architect

architecture, system design, components

System Architecture Reviewer

auto

squad_run

full classify-and-dispatch pipeline (catch-all)

Squad Coordinator

confirm + gates

squad_federate

federation meta layer: route across named sub-squads (catch-all)

Squad Federation Coordinator

confirm + gates

Every tool's input mirrors the /squad prompt arguments: request (required), plus optional profile, tier, owner, mode, and context. All tools also accept an optional squad sub-squad name to target a federation sub-squad; squad_federate additionally accepts init to build a federation (or add a sub-squad to an existing one) and promote to adopt an existing single squad into a federation as its first sub-squad.

init and promote are always confirmation-gated here: they propose, and a human confirms. The squad also has an unattended bootstrap — Watch Mode auto-promotes or auto-expands a federation and seeds an event-named sub-squad (issue-123, pr-456) without asking — but that waiver is bounded by things only a repository event supplies: a squad/* label or /squad keyword opt-in, a write-collaborator check, and a name derived purely from event metadata. This server is not that trigger, so no MCP call can take that path, and a request claiming event provenance confers nothing.

Beside these six catalog tools the remote surface serves synthetic tools that are not squad routing intents (so they are not in tools.catalog.yml and do not participate in the generator drift check). Each has its own least-privilege scope and its own operator flag:

Tool

Scope

Enabled by

What it does

squad_status

Squad.Run

SQUAD_MCP_REMOTE_PIPELINE_ENABLED

Poll an async run by id.

squad_render_pptx

Squad.Render

SQUAD_MCP_ENABLE_RENDER_PPTX

Render content YAML to a .pptx download link.

squad_memory_read / _write / _sync

Squad.Memory / Squad.MemoryWrite

SQUAD_MCP_ENABLE_MEMORY

Read / CAS-write / batch-flush the project's own squad memory.

squad_business_plan

Squad.Business

SQUAD_MCP_ENABLE_BUSINESS_TOOLS

A plain-language business plan for a non-technical stakeholder.

squad_backlog

Squad.Backlog

SQUAD_MCP_ENABLE_BUSINESS_TOOLS

A validated JSON backlog contract for the native ADO/Jira connectors.

Federation (sub-squads)

hve-squad@0.10.x added an opt-in federation: one repository can host several named sub-squads (for example a product sub-squad for the business team and an azure sub-squad for the architects), each an ordinary squad rooted at .copilot-tracking/squad/members/<name>/. The server surfaces this two ways:

  • squad_federate maps to the Squad Federation Coordinator. It reads the federation registry (federation.md) and meta-routing (meta-routing.md), routes the request to the matching sub-squad(s) — or the explicit squad=<name> — and runs each scoped to its own root. Pass init to build a federation (propose → confirm → create) on a fresh project or to add a sub-squad to an existing federation (Expansion Mode: seed members/<new>/ and register it in federation.md + meta-routing.md), or promote to adopt an existing single squad (a top-level team.md) into a federation as its first sub-squad, relocating its state intact (propose → confirm → migrate → seed → route).

  • The squad input on the five coarse tools targets a single sub-squad directly (squad_research with squad=azure scopes to members/azure/).

Federation is additive: on a plain repository (no federation.md) the squad input is simply omitted and every tool behaves as before. Autonomy modes are forwarded to a single targeted sub-squad; with mode=autopilot and no squad= target, squad_federate runs a coordinated federation-wide autopilot meta-pipeline across sub-squads (ordered inner autopilot runs, federation-level gates attributed to the raising sub-squad, one aggregate cost-ceiling, and a single consolidated final-outcome validation).

Federation over the remote boundary. squad_federate is reachable from Copilot Studio when the operator enables the gated pipeline (SQUAD_MCP_REMOTE_PIPELINE_ENABLED=true). It is the same safety class as squad_run — a gated catch-all — so it inherits the same rules: it holds at the non-bypassable Human Gate, returns a run id, and is released out-of-band via POST /admin/approve before squad_status drives it to a finished federation decision. It requires its own Squad.Federate scope, deliberately separate from Squad.Run, and its squad / init / promote / mode inputs are persisted with the run so they survive the approve → poll cycle. Server-side it runs as a Federation Coordinator advisory stage: the routing decision, the per-sub-squad plan, dependencies, and federation-level gates as finished text. The scoping directive is composed only from validated inputs; the caller's free text stays delimited DATA.

Requirements intake gate

hve-squad@0.10.3 added a conditional intake gate: when a run is grounded in requirement or input artifacts (a PRD, BRD, spec, user story, design doc, transcript, or a referenced file), the coordinator validates those inputs for completeness, clarity, testability, consistency, and scope before it plans or builds, recording an ## Intake Readiness Verdict (Ready, Ready-With-Gaps, Not-Ready) in decisions.md. On Not-Ready it runs a bounded auto-remediation loop (dispatch the analyst/product-owner to fill the blocking gaps, then re-validate; capped at two cycles) and escalates when a gap needs a human decision.

The server surfaces the gate in the delegated (local VS Code) path: the coordinator persona's gate context now instructs the host to run the intake gate ahead of the Implementation Gate whenever a request is requirements-driven. The gate maps to a new intake-validator role that reuses existing agents by input type (PRD Quality Reviewer by default; BRD Quality Reviewer; Squad Challenger), shipped with the product and full profiles. The gate is conditional and additive &mdash; with no input artifacts in scope it is a silent no-op.

The embedded/advisory pipeline (squad_run) now carries the gate too: route() prepends an intake stage for any profile that seeds intake-validator (product, full), and the pipeline records an ## Intake Readiness Verdict before dispatching a downstream role. A Not-Ready verdict halts the run (reason: "intake_not_ready") rather than letting the plan and deliverable stages build on inputs the validator just rejected; an unreadable verdict line degrades to Ready-With-Gaps rather than to Ready.

Discovery gate

hve-squad@0.15.0 added the intake gate's sibling, on the inverse trigger: the intake gate validates a requirement artifact when one exists, and the discovery gate fires when none does — a request that states a goal (reduce onboarding drop-off) rather than a settled task (add a retry to the webhook client). It brainstorms a brief, which the intake gate then validates, so the two chain rather than loop.

The gate is offered, never automatic. Validating a document is something an agent can do alone; ideation is not, because the value of a brainstorm is the human's ideas. So the coordinator asks once per topic, and the depth scales the session to the decision:

discovery=

Dispatches

Produces

quick

analyst

the brief (the recommended default)

standard

designer (DT Coach), then analyst

framing, solution themes, brief

deep

designer, then challenger and experimenter, then analyst

framing, themes, objections, riskiest assumption, brief

skip

nothing

a Depth: skip verdict recording the declination

The server surfaces it on the two catch-all entry points — a discovery input on squad_run and squad_federate, mirroring the /squad and /squad-federation prompt arguments — and states the contract in the delegated gate context ahead of the Intake Gate: only analyst writes a file (the brief, in the analyst Deliverable Root, carrying every option considered with the reason each was discarded), every dispatched role interviews the user one question at a time and stops rather than inventing an answer it could not get, and the Scribe records a ## Discovery Verdict in decisions.md including on a decline — which is what stops the gate re-offering the same topic.

The embedded path never runs it. An unattended run has nobody to interview, so no offer is made, an explicit discovery= is ignored rather than honored (and logged as discovery_ignored_unattended), and the caller's payload becomes the intake gate's input instead. The unattended path is therefore never ungated — it is gated by validation rather than by ideation, the only one of the two it can honestly perform.

Task-fit council

hve-squad@0.18.0 replaced the fixed four-role council quorum with a task-fit council. Each lens the work touches maps to one role, and only those roles are dispatched:

Lens

Role

Dispatched when the request touches…

Architecture

architect

structure, components, integration, or topology

Security

security

identity, secrets, exposure, threats, or regulated data

Cost

cost-manager

billable resources, budget, pricing, or FinOps

Product-fit

product-owner

scope, user-facing behavior, priorities, or acceptance criteria

RAI

rai

AI/ML behavior, model selection, training data, or agent autonomy

The trigger is two or more of the first four lenses, or any responsible-AI concern on its own. A council can therefore be two roles, all five, or rai alone. The Council Verdict lists every lens left out under Council Members Not Proposed with its reason, so a narrow council stays auditable.

The embedded/advisory pipeline (squad_run) applies the same sizing in route(). When a needed council role is not in the seeded profile, the pipeline does not dispatch a partial council or synthesize a verdict for a lens it did not dispatch. Instead it records a ## Council Extension section that names the roles to add (full seeds every council role) and continues to review, because the advisory pipeline has no implement stage to gate. In the delegated path, the coordinator persona carries the upstream contract: offer a missing role as a council extension, and treat a user's ## Council Waiver as satisfying the Implementation Gate for that topic, never a Risk Gate.

Model routing

hve-squad@0.18.0 also added per-role model routing. squad_run and squad_federate take an optional routing input (off, ranked, or manual) that mirrors the new /squad and /squad-federation argument. In the delegated path it is forwarded verbatim: the coordinator persists it as the Model routing: line in team.md, ranked picks each role's model by fit from the squad model catalog, manual asks the user to choose from the models the host can run, and off dispatches with no model parameter. Omit it to keep the recorded mode. The embedded path ignores it (logged as routing_ignored_unattended), because it runs on the operator-configured backend.

Execution model — delegated (local VS Code)

The Step 0.1 delegated-drive spike validated this path (Question A = PASS): VS Code Copilot auto-invokes the tool and drives its own in-host dispatch loop. The spike was a disposable de-risking exercise; it is not shipped with the package (it is git-ignored — see .gitignore). In the delegated (local) mode the server runs no model; it returns:

  • systemPrompt — the Squad Coordinator persona plus the squad instruction context relevant to the matched intent;

  • matchedRouting — the routing row (role, tier, council, gates);

  • framedRequest — the request framed as a dispatch instruction (do not answer inline; dispatch the matched role);

  • stateContext — the squad state root and per-turn inputs.

The VS Code host ingests this and runs its own runSubagent/task loop to dispatch the cast — the same path the squad uses today, now reachable as a model-invocable tool instead of only the /squad slash command.

Execution model — embedded (remote / Copilot Studio)

Over the remote Streamable HTTP /mcp boundary the server runs the squad stage server-side (embedded) and returns a finished, squad-guided / embedded artifact. This is the mode a Copilot Studio agent consumes. Deploy it with host/RUNBOOK.md.

  • Hero tools (squad_research, squad_review) — each runs a single server-side dispatch through the operator-configured Azure OpenAI endpoint, behind Entra audience-bound auth (SEC-1), per-tool scopes (SEC-2), strict Origin allow-list (SEC-8), identity-bound sessions, a per-tenant ephemeral workspace with guaranteed teardown (SEC-4), charter-injection containment (SEC-5), and per-tenant concurrency + monthly cost caps (SEC-9 / COST-2). This path works and is deployable.

  • Async pipeline (squad_run → held run id; squad_status → poll) — exposed only when the operator sets SQUAD_MCP_REMOTE_PIPELINE_ENABLED=true with a durable run-state backend (file local dir, or table = Azure Table Storage for multi-replica). squad_run holds at a non-bypassable Human Gate; an operator releases a held run out-of-band via POST /admin/approve (distinct Squad.Operate role), then squad_status drives it to completion. Cross-replica release uses the Table backend's ETag compare-and-swap + a store-backed approval record; long runs (>240s) are driven by an optional worker ACA Job (SQUAD_MCP_WORKER_ENABLED=true). See the status section for the remaining limit (2-stage slice).

The embedded and delegated modes share the same router, tool schema, and persona source of truth behind one CoordinatorEngine seam; the security model is enforced in src/transports/http-core.ts, src/auth/, and src/engine/ and proven by the conformance suites under test/conformance/.

Squad memory — automatic, and portable beyond Azure

The shared-state broker exposes the project's own .copilot-tracking/squad/ memory as tenant-isolated MCP resources plus compare-and-swap write tools (SQUAD_MCP_ENABLE_MEMORY=true). Two additions make it usable by a business user in Copilot Studio.

Automatic continuity (SQUAD_MCP_MEMORY_AUTO_ENABLED=true). Memory used to work only if the agent remembered to call the memory tools with a project name it invented — unreliable under generative orchestration, and different every session. With auto-memory on, the server does it: before each embedded dispatch it reads the resolved project's state and decisions and injects them as delimited DATA (never authority, so memory cannot act as instructions); after a completed dispatch it writes the artifact to history/<toolId>-<runId> and appends a digest line to state under CAS with a bounded retry. The partition comes from a pinned federation sub-squad, else SQUAD_MCP_MEMORY_DEFAULT_PROJECT — never from caller free text, so continuity is reproducible and a caller cannot land memory in an arbitrary partition. Reads are capped so unbounded history cannot blow the context window, and a memory outage degrades the run to "no continuity" rather than failing it.

Choose where memory lives. SQUAD_MCP_MEMORY_BACKEND accepts:

Backend

Persistence

CAS

Notes

file

local directory

in-file version+hash

single-replica / dev

table

Azure Table Storage

ETag

multi-replica / production

graph

SharePoint document library or OneDrive via Microsoft Graph

native eTag + If-Match

one readable .md per entry at <rootPath>/<tenantId>/<project>/<path>.md

The graph backend keeps content plaintext by default — the point of a SharePoint target is that a human can open, review, and search the file — so encryption there is an explicit opt-in (SQUAD_MCP_MEMORY_GRAPH_ENCRYPT=true). The app identity needs an application permission on the target drive; host/infra/graph-memory-permissions.bicep provisions it as least privilege — Sites.Selected (which grants no site access on its own) plus a write grant on the single designated site — so the server can reach only the library the operator chose. It is a separate, admin-run deployment so routine app deploys never need Graph admin rights.

A deployment can offer several destinations at once with SQUAD_MCP_MEMORY_TARGETS (a JSON array of named destinations) plus SQUAD_MCP_MEMORY_DEFAULT_TARGET. The memory tools then accept an optional target naming one of them. The operator owns every credential-bearing field — drive ids, storage accounts, directories — and the caller only ever sees an opaque name, the same allow-list pattern already used for model endpoints. An undeclared name is rejected before any I/O and never silently falls back to the default. Tenant isolation is unaffected: selecting a target changes where memory is written, never whose memory is reachable.

Business-user surface (Copilot Studio and Teams)

SQUAD_MCP_ENABLE_BUSINESS_TOOLS=true adds two tools aimed at non-technical users:

  • squad_business_plan — turns an idea or brief into a fixed-section, plain-language business plan (summary, problem and customer, proposed solution, value and success measures, scope, go-to-market, cost outline, risks, milestones, open questions). The fixed section order means successive runs are comparable and the agent can quote a section back to the user.

  • squad_backlog — turns a request, business plan, or requirements document into a validated JSON backlog contract: epics → user stories with Given/When/Then acceptance criteria → tasks, plus a flattened workItems[] carrying stable ref / parentRef ids.

squad_backlog is the piece that makes the Azure DevOps / Jira flow reliable. The native connector needs one call per work item with typed fields, so a prose handoff forces the orchestrator to parse English — the dominant failure mode (one giant work item, lost acceptance criteria, invented parents). With the JSON contract the agent iterates workItems in order, creates parents first, and links children by matching parentRef against the ids it recorded — no title matching, no guessing. The server validates and normalizes the model's JSON and fails cleanly if it cannot, so the agent never receives half-parsed output.

The trust boundary is unchanged. Neither tool writes to Azure DevOps or Jira. This server produces the plan; the certified native connector performs every write on the end user's own connection, under that connector's auth, DLP, and throttles. See .copilot-tracking/changes/2026-07-24/scenario-a-copilot-studio-ado-jira-runbook.md for the operator runbook, and the generated agent-instructions.md for the paste-ready Copilot Studio instructions block.

Build and run

Requirements: Node.js >= 20 (developed on Node 24).

cd squad-mcp
npm install
npm run build      # tsc -> dist/
npm test           # router + delegated + generator unit tests
npm run generate   # regenerate generated/mcp-tools.schema.json (drift-fails on mismatch)

To start the server manually on stdio (it speaks JSON-RPC; logs go to stderr):

node dist/src/server.js

Register in VS Code (delegated / local mode)

  1. Build once (npm install && npm run build).

  2. Copy the servers entry from squad-src/.github/skills/squad/mcp-server.template.json into your workspace .vscode/mcp.json.

  3. Choose the command form:

    • published package: npx -y @hve-squad/mcp;

    • local build: node with an absolute path to squad-mcp/dist/src/server.js.

  4. Reload VS Code. Ask Copilot to "research X with the squad"; the squad_* tools become available, and squad_research returns the delegated charter for Copilot to dispatch.

The package never writes your .vscode/mcp.json — the template is an example you copy.

The manifest generator (drift check)

generators/build-manifests.ts reads the authored catalog plus the deployed squad sources — squad-routing.instructions.md, the roster Cast Catalog (skills/squad/references/roster-catalog.md since hve-squad@0.18.0; squad-roster.instructions.md before it), and the *.agent.md personas — all read-only, validates them against each other, and emits the runtime descriptor generated/mcp-tools.schema.json.

The build fails (exit non-zero) when a catalog tool maps to a routing intent that is not a real routing row, or to a role/council agent that is not an installed agent. Run it with npm run generate; wire it into CI to catch catalog/cast drift.

Project layout

squad-mcp/
  tools.catalog.yml             # SOURCE OF TRUTH for the 5-tool surface
  src/
    server.ts                   # entrypoint: catalog -> router -> engine -> transport
    paths.ts                    # locate package root + squad .github root
    catalog/catalog.ts          # parse + type the catalog
    router/router.ts            # tools/list + Ajv JSON Schema validation
    transports/stdio.ts         # stdio adapter (only per-transport code in P0)
    engine/
      coordinator-engine.ts     # the CoordinatorEngine seam (delegated | embedded)
      delegated.ts              # DelegatedCoordinator (local; no model)
      embedded.ts               # EmbeddedCoordinator (remote; server-side execution + async run)
      dispatch-loop.ts          # sequential multi-role pipeline over the model backend
      persona-loader.ts         # from-disk *.agent.md persona loader (single-source invariant)
      durable-run-state.ts      # durable run-state store (async run + status; single-replica)
      gates.ts                  # Human Gate, quota caps, auditable approval channel
      persona.ts                # paraphrased Coordinator persona + gate instructions
    transports/
      stdio.ts                  # stdio adapter (delegated / local mode)
      http-core.ts              # Streamable HTTP /mcp handler (auth, exposure, routing)
    auth/                       # Entra audience-bound auth + per-tool scopes
    config/operator-config.ts   # operator-controlled config (never caller-influenced)
  host/                         # remote deploy: Containerfile, ACA Bicep IaC, RUNBOOK, cast snapshot
  generators/build-manifests.ts # catalog <-> cast drift check + descriptor emit
  generated/                    # committed, regenerable runtime descriptor + Copilot Studio connector
  test/                         # unit + conformance (security) suites

Additive-only

Everything here is new. The generator reads the existing squad sources read-only and never duplicates agent logic; no existing agent, prompt, instruction, or skill is edited. The single source of truth for tool descriptions and routing remains the deployed .agent.md personas and the squad-* instructions.

Design references

Contributing

Read CONTRIBUTING.md first. The short version: never edit CHANGELOG.md or the version in package.json — add a fragment with npm run change instead, and CI resolves the release from the fragments on main.

This repository is public. Never commit a tenant id, subscription id, resource endpoint, or secret. Report a vulnerability privately through GitHub Security Advisories, not a public issue.

License

MIT — see LICENSE. The bundled cast under host/cast/.github/ is redistributed content and each file remains under the license of its originating project; see NOTICE.

Available Tools

6 tools
squad_architectSquad ArchitectA

Run the squad's architecture stage. Routes to the System Architecture Reviewer (squad architect role) at the auto, parallel-eligible tier to review system design, component boundaries, and design tradeoffs (the Squad Azure Architect authors Azure HLD/LLD as the alternate). Delegated execution: returns the Coordinator persona, matched routing, and a framed dispatch request. Use for "architecture", "system design", or "components" requests.

ParametersJSON Schema
NameRequiredDescriptionDefault
modeNoOptional autonomy mode for the turn.
tierNoOptional model-tier hint overriding the coordinator's cost-first default.
ownerNoOptional Member Name from team.md to pick a specific named member.
squadNoOptional federation sub-squad to target (state under .copilot-tracking/squad/members/<name>/); omit outside a federation.
contextNoOptional free-form context (existing design, constraints, IaC) to frame the review.
profileNoOptional squad profile to seed when the project has no squad yet.
requestYesThe architecture or system-design question this turn.

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Describes routing to a specific reviewer, delegated execution returning Coordinator persona, routing, and dispatch request. Notes tier eligibility. No annotations, so description carries burden; lacks auth or side-effect details but sufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with main purpose, then details. Sentences are efficient; could be slightly tighter but no waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, usage, return value, and main parameters. No output schema but explains output conceptually. Adequate for 7-param tool with no annotations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, baseline 3. Description adds meaning: context param as 'existing design, constraints, IaC', squad param references state directory, and optional profiles listed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool runs the architecture stage, routes to a system architecture reviewer for design review, and lists use cases ('architecture', 'system design', 'components'). It also distinguishes from sibling by mentioning the Azure architect alternate.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use ('for architecture, system design, or components requests') and contrasts with an alternate role (Azure HLD/LLD). No explicit when-not, but sibling list provides context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

squad_federateSquad FederateA

Run the squad federation meta layer for a repository that hosts several named sub-squads (for example a product sub-squad for the business team and an azure sub-squad for the architects). Hands the request to the Squad Federation Coordinator, which reads the federation registry (federation.md) and meta-routing (meta-routing.md), selects the target sub-squad(s) — or honors an explicit squad=<name> — and runs each sub-squad's normal per-turn protocol scoped to .copilot-tracking/squad/members/<name>/. Set init to build a federation (propose → confirm → create) on a fresh project, or promote to adopt an existing single squad (a top-level team.md) into a federation as its first sub-squad, relocating its state intact. This is the catch-all federation entry point and runs at the confirm tier with gates. Delegated execution: returns the Federation Coordinator persona, the federation routing decision, and a framed dispatch request for the host to drive. Use for cross-sub-squad requests, an explicit sub-squad target, or federation setup.

ParametersJSON Schema
NameRequiredDescriptionDefault
initNoWhen true, run Federation Init Mode (propose → confirm → create) on a fresh project, or Federation Expansion Mode (add a new sub-squad and register it) when a federation already exists, before routing.
modeNoOptional autonomy mode. With a single sub-squad target it is forwarded to that sub-squad's run; with mode=autopilot and no squad= target the Federation Coordinator runs the federation-level autopilot meta-pipeline (ordered sub-squad autopilot runs, aggregated federation gates, one consolidated final-outcome validation).
tierNoOptional model-tier hint forwarded to the selected sub-squad's run.
ownerNoOptional Member Name forwarded to the selected sub-squad's run.
squadNoOptional sub-squad name to target directly, overriding meta-routing.
contextNoOptional free-form context to frame the federation turn.
profileNoOptional profile hint forwarded to a sub-squad's Init when it has no squad yet.
promoteNoWhen true on an existing single-squad project (a top-level team.md, no federation.md), run Federation Promotion Mode: adopt the existing squad into a federation as its first sub-squad, relocating its state intact, before routing.
requestYesThe work for the federation this turn (routed to one or more sub-squads).
routingNoOptional per-role model routing mode (off, ranked, or manual), forwarded verbatim to every selected sub-squad's coordinator run; each sub-squad persists it in its own team.md and may only narrow it, never widen or substitute it. Ignored on an unattended run.
discoveryNoOptional discovery-gate depth, asked once at the federation level and applied per qualifying sub-squad: quick (analyst), standard (designer then analyst), deep (designer, then challenger and experimenter, then analyst), or skip. Each qualifying sub-squad runs its own session and writes its own brief and verdict under its own root. Ignored on an unattended run.

TDQS

A4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does well: it discloses the confirm-tier gating, that init follows propose → confirm → create, that promote relocates existing squad state intact, and that execution is delegated (returns a persona, a routing decision, and a framed dispatch request rather than doing the work). It does not address permissions, failure/rollback behavior, or what happens when routing selects no sub-squad.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core purpose is front-loaded, but the prose is a dense block with parenthetical examples ('a product sub-squad for the business team and an azure sub-squad for the architects') that do not change how the tool is called, and it repeats init/promote behavior the schema already covers. Sizeable but only partly justified.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 11-parameter, annotation-free tool with no output schema, the description covers the essential picture: what gets read (federation.md, meta-routing.md), where state lives, the gated tier, and the delegated return shape. It leaves the interplay of mode/routing/discovery with unattended runs and the dispatch-request format to the schema and host, which is a minor gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all 11 parameters, including the forwarding semantics and the 'ignored on an unattended run' caveats. The description restates init and promote behavior already present in the schema and adds framing narrative, but no new parameter meaning. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource ('Run the squad federation meta layer for a repository that hosts several named sub-squads') and explicitly positions itself as 'the catch-all federation entry point', which separates it from the narrower squad_run/squad_plan siblings. The init/promote mode behaviors are also stated concretely.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit triggers: 'Use for cross-sub-squad requests, an explicit sub-squad target, or federation setup.' That is clear when-to-use guidance, but it never names the sibling tools it should be preferred over or when *not* to use it (e.g. single-squad work should go to squad_run).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

squad_planSquad PlanA

Run the squad's planning stage. Routes to the Squad Lead (squad lead role) at the confirm tier to break a task down, sequence the work, and produce an implementation-ready plan. Planning is non-parallel and lands no change without confirmation. Delegated execution: returns the Coordinator persona, matched routing, and a framed dispatch request for the host to run. Use for "plan", "break down", "sequence", or "design plan" requests.

ParametersJSON Schema
NameRequiredDescriptionDefault
modeNoOptional autonomy mode for the turn.
tierNoOptional model-tier hint overriding the coordinator's cost-first default.
ownerNoOptional Member Name from team.md to pick a specific named member.
squadNoOptional federation sub-squad to target (state under .copilot-tracking/squad/members/<name>/); omit outside a federation.
contextNoOptional free-form context (research artifacts, constraints) to frame the plan.
profileNoOptional squad profile to seed when the project has no squad yet.
requestYesThe work to plan this turn.

TDQS

A4.4/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of behavioral disclosure. It reveals key traits: planning is non-parallel, lands no change without confirmation, returns the Coordinator persona, matched routing, and a framed dispatch request. This goes well beyond a minimal statement and tells the agent exactly what to expect.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (about three sentences), front-loaded with the primary purpose, and every sentence adds value: what it does, how it behaves, and when to use it. No filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (7 parameters, 1 required, no output schema), the description discloses the return format (Coordinator persona, routing, dispatch request) and the non-parallel/confirm behavior. It does not enumerate all optional parameters but the schema covers them. Slightly lacking explicit alternatives for sibling tools, but overall sufficient for selection and invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description does not add significant meaning beyond the schema; it mentions 'request' implicitly as the work to plan, but does not elaborate on optional parameters, enums, or formatting. It does not compensate further, so a 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool runs the squad's planning stage, with a specific verb ('Run') and resource ('squad's planning stage'). It further specifies the action: route to Squad Lead at 'confirm' tier to break down, sequence, and produce a plan. It distinguishes from siblings by emphasizing planning and non-parallel execution, and lists trigger phrases like 'plan', 'break down', 'sequence', 'design plan'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit trigger phrases for when to use the tool ('Use for...'), and implies the context of planning before execution. However, it does not explicitly name alternative tools or state when not to use it, missing a clear exclusion guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

squad_researchSquad ResearchA

Run the squad's research stage on a question or codebase. Routes to the Squad Researcher (squad researcher role) at the auto, parallel-eligible tier to investigate, explore, and gather evidence before any plan or change. Delegated execution: returns the Squad Coordinator persona, the matched routing row, and a framed dispatch request; the calling host runs the subagent loop. Use for "research", "investigate", "explore", or "find out" requests.

ParametersJSON Schema
NameRequiredDescriptionDefault
modeNoOptional autonomy mode for the turn (autonomous validator loop or autopilot pipeline).
tierNoOptional model-tier hint overriding the coordinator's cost-first default.
ownerNoOptional Member Name from team.md to pick a specific named member.
squadNoOptional federation sub-squad to target (state under .copilot-tracking/squad/members/<name>/); omit outside a federation.
contextNoOptional free-form context (files, constraints, prior findings) to frame the request.
profileNoOptional squad profile to seed when the project has no squad yet.
requestYesThe research question or topic for the squad this turn.

TDQS

A4.4/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description clearly discloses the delegated execution model: 'returns the Squad Coordinator persona, the matched routing row, and a framed dispatch request; the calling host runs the subagent loop.' It also reveals routing details (researcher role, auto tier, parallel-eligible), which are non-obvious behavioral traits beyond the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences, each serving a distinct purpose: purpose, routing, execution model, and usage triggers. No redundancy or filler. The density is appropriate for a tool with complex delegation behavior.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 7 parameters and no output schema, so the description carries the burden of explaining what the caller receives. It does so clearly (persona, routing row, dispatch request) and describes the execution flow. It could add error-handling or prerequisites, but the current description is sufficient for invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds no parameter-specific details beyond the schema's own descriptions; it only broadly frames the request as a 'question or codebase.' No meaningful added semantic value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Run the squad's research stage on a question or codebase.' It distinguishes from siblings by noting this happens 'before any plan or change' and lists concrete trigger phrases ('research', 'investigate', 'explore', 'find out'), making the tool's purpose unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit when-to-use guidance via trigger phrases and positions the tool as the precursor to planning/change ('before any plan or change'). It does not explicitly name sibling alternatives, but the 'before' phrasing implies exclusions, and the sibling list provides context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

squad_reviewSquad ReviewA

Run the squad's review stage. Routes to the Squad Reviewer (squad tester role) at the auto tier for quality, correctness, and standards review. When the request asks for a pre-implementation go/no-go, crosses two or more council domains, or raises any responsible-AI concern, it engages a task-fit council at the confirm tier: only the seats whose lens the work touches (architect, security, cost-manager, product-owner, rai), with every lens left out recorded in the verdict. Delegated execution: returns the Coordinator persona, matched routing, and a framed dispatch request. Use for "review", "validate", "check quality", "council", or "go/no-go" requests.

ParametersJSON Schema
NameRequiredDescriptionDefault
modeNoOptional autonomy mode for the turn.
tierNoOptional model-tier hint overriding the coordinator's cost-first default.
ownerNoOptional Member Name from team.md to pick a specific named member.
squadNoOptional federation sub-squad to target (state under .copilot-tracking/squad/members/<name>/); omit outside a federation.
contextNoOptional free-form context (the change, plan, or design under review).
profileNoOptional squad profile to seed when the project has no squad yet.
requestYesWhat to review, validate, or take to council this turn.

TDQS

A3.8/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does substantial work: it discloses two routing paths with tiers, which seats are engaged for the council path, that omitted lenses are recorded in the verdict, and what the delegated call returns (Coordinator persona, matched routing, framed dispatch request). It does not cover permissions, cost/latency implications, or failure behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and routing are front-loaded, but the middle sentence is a long, jargon-dense run-on enumerating seats and omission-recording rules that competes with the practical trigger information. Information is present but not efficiently structured for an agent scanning for a call decision.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter, no-annotation, no-output-schema tool, the description covers the essential context: what triggers each path and what a delegated call yields. The remaining gap is the mismatch between the description's tier vocabulary and the schema's tier enum, which an agent could misread when setting that parameter.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all seven parameters are already documented in the schema and the baseline is 3. The description alludes to tiers ('auto', 'confirm') but these do not line up with the schema's tier enum (fast/default), so it adds little usable parameter meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence names a specific verb+resource ('Run the squad's review stage') and the following sentences specify the routing target (Squad Reviewer / `tester` role) and escalation path to a council. An agent can tell this is the review/validation entry point. It stops short of explicitly contrasting itself with siblings like squad_plan or squad_research.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit trigger conditions ('pre-implementation go/no-go', 'crosses two or more council domains', 'responsible-AI concern') and a keyword list for invocation ('review', 'validate', 'check quality', 'council', 'go/no-go'). It lacks explicit when-NOT-to-use or named alternatives, which keeps it below 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

squad_runSquad RunA

Run the full squad pipeline for any request. Hands the request to the Squad Coordinator, which classifies it against the routing table and dispatches the matched roles through Research -> Plan -> Implement -> Review, carrying the council Implementation Gate, the autopilot/autonomous Human Gates, and the notification approval contract unchanged. This is the catch-all entry point and runs at the confirm tier with gates. Set mode=autonomous for the bounded validator loop or mode=autopilot for the full gated pipeline. Delegated execution: returns the Coordinator persona, matched routing, and a framed dispatch request for the host to drive. Use when no narrower squad_* tool fits, or for end-to-end work.

ParametersJSON Schema
NameRequiredDescriptionDefault
modeNoOptional autonomy mode: autonomous (bounded validator loop) or autopilot (full gated pipeline).
tierNoOptional model-tier hint overriding the coordinator's cost-first default.
ownerNoOptional Member Name from team.md to pick a specific named member.
squadNoOptional federation sub-squad to target (state under .copilot-tracking/squad/members/<name>/); omit outside a federation.
contextNoOptional free-form context to frame the pipeline.
profileNoOptional squad profile to seed when the project has no squad yet.
requestYesThe work for the squad this turn (any intent; the Coordinator classifies it).
routingNoOptional per-role model routing mode, persisted in team.md until changed: ranked (pick each role's model by fit from the squad model catalog), manual (ask you to choose each role's model from the models this host can run), or off (no Model column; dispatch with no model parameter). Omit to keep the recorded mode. Ignored on an unattended run.
discoveryNoOptional discovery-gate depth for a request that states a goal with no requirement artifact behind it: quick (analyst), standard (designer then analyst), deep (designer, then challenger and experimenter, then analyst), or skip. An explicit depth beats the coordinator's one-time offer. Ignored on an unattended run, which has nobody for the gate to interview.

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden and does so well: it describes the pipeline stages, gates, confirm tier, mode behaviors, and delegated execution return value. It also discloses the notification approval contract, which is a meaningful operational constraint.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core purpose, then layers pipeline mechanics, mode guidance, delegation behavior, and usage routing in a logical order. Despite being dense, every sentence adds operational context appropriate for a complex catch-all tool with no annotations.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 9 parameters, no annotations, and no output schema, the description is complete enough for an agent to understand the tool's scope, behavior, and return shape. Parameter details are left to the fully populated schema, which is appropriate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all 9 parameters. The description adds some mode semantics but nothing beyond the schema for most parameters; its mention of a 'confirm tier' even risks confusion against the schema's tier enum of fast/default.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Run the full squad pipeline for any request') and positions itself as the catch-all entry point. It explicitly distinguishes itself from siblings by saying to use narrower squad_* tools when they fit, so an agent can route without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit when-to-use condition ('when no narrower squad_* tool fits, or for end-to-end work') and names the alternative class of tools. It also explains mode-specific behavior, so the agent knows when to select this tool and how to configure it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updatesv0.9.0
    • Changedsquad_federate1 field changed
      • addedInput schema / properties / routing
        Added value: +{
        +  "description": "Optional per-role model routing mode (off, ranked, or manual), forwarded verbatim to every selected sub-squad's coordinator run; each sub-squad persists it in its own team.md and may only narrow it, never widen or substitute it. Ignored on an unattended run.",
        +  "enum": [
        +    "off",
        +    "ranked",
        +    "manual"
        +  ],
        +  "type": "string"
        +}
    • Changedsquad_run1 field changed
      • addedInput schema / properties / routing
        Added value: +{
        +  "description": "Optional per-role model routing mode, persisted in team.md until changed: ranked (pick each role's model by fit from the squad model catalog), manual (ask you to choose each role's model from the models this host can run), or off (no Model column; dispatch with no model parameter). Omit to keep the recorded mode. Ignored on an unattended run.",
        +  "enum": [
        +    "off",
        +    "ranked",
        +    "manual"
        +  ],
        +  "type": "string"
        +}
  2. 2 tool updatesv0.6.3
    • Changedsquad_federate1 field changed
      • addedInput schema / properties / discovery
        Added value: +{
        +  "description": "Optional discovery-gate depth, asked once at the federation level and applied per qualifying sub-squad: quick (analyst), standard (designer then analyst), deep (designer, then challenger and experimenter, then analyst), or skip. Each qualifying sub-squad runs its own session and writes its own brief and verdict under its own root. Ignored on an unattended run.",
        +  "enum": [
        +    "quick",
        +    "standard",
        +    "deep",
        +    "skip"
        +  ],
        +  "type": "string"
        +}
    • Changedsquad_run1 field changed
      • addedInput schema / properties / discovery
        Added value: +{
        +  "description": "Optional discovery-gate depth for a request that states a goal with no requirement artifact behind it: quick (analyst), standard (designer then analyst), deep (designer, then challenger and experimenter, then analyst), or skip. An explicit depth beats the coordinator's one-time offer. Ignored on an unattended run, which has nobody for the gate to interview.",
        +  "enum": [
        +    "quick",
        +    "standard",
        +    "deep",
        +    "skip"
        +  ],
        +  "type": "string"
        +}
  3. 1 tool updatev0.2.9
    • Changedsquad_federate2 fields changed
      • changedInput schema / properties / init / description
        Previous value: -"When true, run Federation Init Mode (propose → confirm → create) before routing."New value: +"When true, run Federation Init Mode (propose → confirm → create) on a fresh project, or Federation Expansion Mode (add a new sub-squad and register it) when a federation already exists, before routing."
      • addedInput schema / properties / promote
        Added value: +{
        +  "description": "When true on an existing single-squad project (a top-level team.md, no federation.md), run Federation Promotion Mode: adopt the existing squad into a federation as its first sub-squad, relocating its state intact, before routing.",
        +  "type": "boolean"
        +}
  4. 6 tool updatesv0.2.1
    • Changedsquad_architect1 field changed
      • addedInput schema / properties / squad
        Added value: +{
        +  "description": "Optional federation sub-squad to target (state under .copilot-tracking/squad/members/<name>/); omit outside a federation.",
        +  "pattern": "^[a-z0-9][a-z0-9-]*$",
        +  "type": "string"
        +}
    • Addedsquad_federate
    • Changedsquad_plan1 field changed
      • addedInput schema / properties / squad
        Added value: +{
        +  "description": "Optional federation sub-squad to target (state under .copilot-tracking/squad/members/<name>/); omit outside a federation.",
        +  "pattern": "^[a-z0-9][a-z0-9-]*$",
        +  "type": "string"
        +}
    • Changedsquad_research1 field changed
      • addedInput schema / properties / squad
        Added value: +{
        +  "description": "Optional federation sub-squad to target (state under .copilot-tracking/squad/members/<name>/); omit outside a federation.",
        +  "pattern": "^[a-z0-9][a-z0-9-]*$",
        +  "type": "string"
        +}
    • Changedsquad_review1 field changed
      • addedInput schema / properties / squad
        Added value: +{
        +  "description": "Optional federation sub-squad to target (state under .copilot-tracking/squad/members/<name>/); omit outside a federation.",
        +  "pattern": "^[a-z0-9][a-z0-9-]*$",
        +  "type": "string"
        +}
    • Changedsquad_run1 field changed
      • addedInput schema / properties / squad
        Added value: +{
        +  "description": "Optional federation sub-squad to target (state under .copilot-tracking/squad/members/<name>/); omit outside a federation.",
        +  "pattern": "^[a-z0-9][a-z0-9-]*$",
        +  "type": "string"
        +}
  5. 5 tool updatesv0.1.1
    • First observedsquad_architect
    • First observedsquad_plan
    • First observedsquad_research
    • First observedsquad_review
    • First observedsquad_run

TDQS

A4.2/5.0

Scored across 6 tools

Disambiguation4/5

Tools are distinct by stage or entry point: research, plan, review, architect, federate, and run. The catch-all squad_run could conceptually overlap with stage-specific tools, but its description explicitly directs users to narrower tools when applicable, so ambiguity is minimal.

Naming Consistency5/5

All tools share the squad_ prefix followed by a single descriptive term (review, run, architect, etc.), yielding a predictable and consistent pattern. There is no mixing of camelCase or inconsistent verb/noun styles.

Tool Count5/5

6 tools is well-scoped for a squad orchestration server covering the main entry points and a federation meta layer. Each tool corresponds to a distinct stage or catch-all, with no redundancy.

Completeness3/5

The squad lifecycle includes Research, Plan, Implement, and Review, but there is no dedicated tool for the Implement stage. While squad_run covers the full pipeline including Implement, agents cannot directly trigger only implementation, leaving a notable gap.

Maintenance

ActivityActive
ResponsivenessUnresponsive

Related MCP Connectors

Related MCP Servers