hve-squad MCP server
Summary: The hve-squad MCP server exposes the hve-squad as model-invocable tools so an MCP host (VS Code Copilot locally, or Copilot Studio remotely) can run squad research, planning, review, architecture, full-pipeline, and federation work against the deployed cast.
Run per-role intents —
squad_research(investigate/explore),squad_plan(break down/sequence),squad_review(quality/go-no-go, with task-fit council),squad_architect(system design/tradeoffs).Run the whole squad —
squad_runis the catch-all: the Coordinator classifies the request and routes research → plan → implement → review with council gates.Run federation workflows —
squad_federateroutes across named sub-squads,initbuilds/expands a federation,promoteadopts an existing single squad, andmode=autopilotwith no target runs a federation-wide meta-pipeline.Shape the call — every tool takes
request(required) plus optionalprofile,tier,owner,mode,context,squad; the catch-alls adddiscovery(quick/standard/deep/skip) andinit/promote.Delegated mode (local, stdio) — the server runs no model; it returns
systemPrompt,matchedRouting,framedRequest, andstateContext, and VS Code drives its own subagent dispatch loop against the real deployed cast.Embedded mode (remote HTTP / Copilot Studio) — the server runs stages server-side via Azure OpenAI and returns finished
squad-guided / embeddedadvisory artifacts, behind Entra auth, per-tool scopes, tenant isolation, gates, and cost caps.Gated async pipeline —
squad_run/squad_federatehold at a non-bypassable Human Gate; an operator releases a run out-of-band viaPOST /admin/approve, thensquad_statuspolls it to completion (file or Azure Table run-state; optional background worker for long runs).Optional synthetic tools (operator-flagged, remote only) —
squad_status,squad_render_pptx(YAML →.pptx+ short-lived SAS link),squad_memory_read/_write/_sync(CAS squad memory, file/table/Graph backends),squad_business_plan(plain-language plan), andsquad_backlog(validated JSON epic/story/task contract).Built-in guardrails — requirements intake gate, discovery gate (offered, not automatic; skipped on unattended runs), task-fit council sizing, per-role model routing, and AES-256-GCM encryption at rest for run artifacts.
Boundary — outputs are advisory text (plus rendered files via
squad_render_pptx); code-executing implement/deploy is a deferred expansion, and neither ADO/Jira writes nor M365 Copilot/Cowork are targeted.
Allows agents in GitHub Copilot (VS Code) to invoke the hve-squad AI squad for research, planning, review, architecture, and full advisory pipeline tasks.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@hve-squad MCP serverResearch the impact of quantum computing on cryptography"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
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 + |
Embedded advisory hero tools ( | 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 ( | 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 ( | Copilot Studio (remote HTTP) | Opt-in ( | First file-output tool. Renders content YAML to a |
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/autonomousrun to one compiled artifact).Releasable by an operator.
squad_runholds at a non-bypassable Human Gate; an operator with the distinctSquad.Operateapp role releases a held run via the out-of-bandPOST /admin/approveroute (never atools/call), after which asquad_statuspoll 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) ortable(Azure Table Storage, cross-replica ETag compare-and-swap). Thetablebackend + 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 callerrequest/contextare 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=truethe 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 |
| research, investigate, explore | Squad Researcher | auto |
| plan, break down, sequence | Squad Lead | confirm |
| review, validate, check quality (+ council go/no-go) | Squad Reviewer (+ council) | auto / confirm |
| architecture, system design, components | System Architecture Reviewer | auto |
| full classify-and-dispatch pipeline (catch-all) | Squad Coordinator | confirm + gates |
| 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 |
|
|
| Poll an async run by id. |
|
|
| Render content YAML to a |
|
|
| Read / CAS-write / batch-flush the project's own squad memory. |
|
|
| A plain-language business plan for a non-technical stakeholder. |
|
|
| 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_federatemaps 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 explicitsquad=<name>— and runs each scoped to its own root. Passinitto build a federation (propose → confirm → create) on a fresh project or to add a sub-squad to an existing federation (Expansion Mode: seedmembers/<new>/and register it infederation.md+meta-routing.md), orpromoteto adopt an existing single squad (a top-levelteam.md) into a federation as its first sub-squad, relocating its state intact (propose → confirm → migrate → seed → route).The
squadinput on the five coarse tools targets a single sub-squad directly (squad_researchwithsquad=azurescopes tomembers/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 — 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:
| Dispatches | Produces |
|
| the brief (the recommended default) |
|
| framing, solution themes, brief |
|
| framing, themes, objections, riskiest assumption, brief |
| nothing | a |
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 |
| structure, components, integration, or topology |
Security |
| identity, secrets, exposure, threats, or regulated data |
Cost |
| billable resources, budget, pricing, or FinOps |
Product-fit |
| scope, user-facing behavior, priorities, or acceptance criteria |
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 setsSQUAD_MCP_REMOTE_PIPELINE_ENABLED=truewith a durable run-state backend (filelocal dir, ortable= Azure Table Storage for multi-replica).squad_runholds at a non-bypassable Human Gate; an operator releases a held run out-of-band viaPOST /admin/approve(distinctSquad.Operaterole), thensquad_statusdrives 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 |
| local directory | in-file version+hash | single-replica / dev |
| Azure Table Storage | ETag | multi-replica / production |
| SharePoint document library or OneDrive via Microsoft Graph | native | one readable |
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 flattenedworkItems[]carrying stableref/parentRefids.
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.jsRegister in VS Code (delegated / local mode)
Build once (
npm install && npm run build).Copy the
serversentry fromsquad-src/.github/skills/squad/mcp-server.template.jsoninto your workspace.vscode/mcp.json.Choose the command form:
published package:
npx -y @hve-squad/mcp;local build:
nodewith an absolute path tosquad-mcp/dist/src/server.js.
Reload VS Code. Ask Copilot to "research X with the squad"; the
squad_*tools become available, andsquad_researchreturns 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) suitesAdditive-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
Remote deploy runbook: host/RUNBOOK.md (ACA + Entra + Copilot Studio connector).
Dual-mode decision record: docs/planning/adrs/0001-dual-mode-mcp-exposure-delegated-vs-embedded.md (delegated vs embedded, trust boundary, ARCH-1/ARCH-2).
IaC: host/infra/main.bicep · connector: generated/copilot-studio-connector/README.md.
Conformance (security) proof:
test/conformance/(auth rejection, cross-tenant, gate carry-through, remote async, pipeline exposure).
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 toolssquad_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.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Optional autonomy mode for the turn. | |
| tier | No | Optional model-tier hint overriding the coordinator's cost-first default. | |
| owner | No | Optional Member Name from team.md to pick a specific named member. | |
| squad | No | Optional federation sub-squad to target (state under .copilot-tracking/squad/members/<name>/); omit outside a federation. | |
| context | No | Optional free-form context (existing design, constraints, IaC) to frame the review. | |
| profile | No | Optional squad profile to seed when the project has no squad yet. | |
| request | Yes | The architecture or system-design question this turn. |
TDQS
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| init | No | 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. | |
| mode | No | Optional 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). | |
| tier | No | Optional model-tier hint forwarded to the selected sub-squad's run. | |
| owner | No | Optional Member Name forwarded to the selected sub-squad's run. | |
| squad | No | Optional sub-squad name to target directly, overriding meta-routing. | |
| context | No | Optional free-form context to frame the federation turn. | |
| profile | No | Optional profile hint forwarded to a sub-squad's Init when it has no squad yet. | |
| promote | No | 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. | |
| request | Yes | The work for the federation this turn (routed to one or more sub-squads). | |
| routing | No | 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. | |
| discovery | No | 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. |
TDQS
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Optional autonomy mode for the turn. | |
| tier | No | Optional model-tier hint overriding the coordinator's cost-first default. | |
| owner | No | Optional Member Name from team.md to pick a specific named member. | |
| squad | No | Optional federation sub-squad to target (state under .copilot-tracking/squad/members/<name>/); omit outside a federation. | |
| context | No | Optional free-form context (research artifacts, constraints) to frame the plan. | |
| profile | No | Optional squad profile to seed when the project has no squad yet. | |
| request | Yes | The work to plan this turn. |
TDQS
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Optional autonomy mode for the turn (autonomous validator loop or autopilot pipeline). | |
| tier | No | Optional model-tier hint overriding the coordinator's cost-first default. | |
| owner | No | Optional Member Name from team.md to pick a specific named member. | |
| squad | No | Optional federation sub-squad to target (state under .copilot-tracking/squad/members/<name>/); omit outside a federation. | |
| context | No | Optional free-form context (files, constraints, prior findings) to frame the request. | |
| profile | No | Optional squad profile to seed when the project has no squad yet. | |
| request | Yes | The research question or topic for the squad this turn. |
TDQS
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Optional autonomy mode for the turn. | |
| tier | No | Optional model-tier hint overriding the coordinator's cost-first default. | |
| owner | No | Optional Member Name from team.md to pick a specific named member. | |
| squad | No | Optional federation sub-squad to target (state under .copilot-tracking/squad/members/<name>/); omit outside a federation. | |
| context | No | Optional free-form context (the change, plan, or design under review). | |
| profile | No | Optional squad profile to seed when the project has no squad yet. | |
| request | Yes | What to review, validate, or take to council this turn. |
TDQS
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Optional autonomy mode: autonomous (bounded validator loop) or autopilot (full gated pipeline). | |
| tier | No | Optional model-tier hint overriding the coordinator's cost-first default. | |
| owner | No | Optional Member Name from team.md to pick a specific named member. | |
| squad | No | Optional federation sub-squad to target (state under .copilot-tracking/squad/members/<name>/); omit outside a federation. | |
| context | No | Optional free-form context to frame the pipeline. | |
| profile | No | Optional squad profile to seed when the project has no squad yet. | |
| request | Yes | The work for the squad this turn (any intent; the Coordinator classifies it). | |
| routing | No | 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. | |
| discovery | No | 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. |
TDQS
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.
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.
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.
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.
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.
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.
2 tool updates
v0.9.0- Changed
squad_federate1 field changed- added
Input schema / properties / routingAdded 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" +}
- Changed
squad_run1 field changed- added
Input schema / properties / routingAdded 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 tool updates
v0.6.3- Changed
squad_federate1 field changed- added
Input schema / properties / discoveryAdded 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" +}
- Changed
squad_run1 field changed- added
Input schema / properties / discoveryAdded 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" +}
1 tool update
v0.2.9- Changed
squad_federate2 fields changed- changed
Input schema / properties / init / descriptionPrevious 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." - added
Input schema / properties / promoteAdded 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" +}
6 tool updates
v0.2.1- Changed
squad_architect1 field changed- added
Input schema / properties / squadAdded 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" +}
- Added
squad_federate - Changed
squad_plan1 field changed- added
Input schema / properties / squadAdded 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" +}
- Changed
squad_research1 field changed- added
Input schema / properties / squadAdded 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" +}
- Changed
squad_review1 field changed- added
Input schema / properties / squadAdded 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" +}
- Changed
squad_run1 field changed- added
Input schema / properties / squadAdded 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 tool updates
v0.1.1- First observed
squad_architect - First observed
squad_plan - First observed
squad_research - First observed
squad_review - First observed
squad_run
TDQS
Scored across 6 tools
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.
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.
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.
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
Related MCP Connectors
MCP server for your apps' tools and custom tools, plus hosted AI agents and approval-gated workflows
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
MCP server for building and testing AI agents with multi-model experimentation and insights.
Control plane for autonomous software labor. Agents claim objectives over MCP with audit trail.
Related MCP Servers
- FlicenseAqualityFmaintenanceMCP server that exposes 300+ AI agents as tools via a single API key. Supports listing agents, invoking any agent with chat-completion style messages, checking agent health, and retrieving platform statistics.54-
- AlicenseDqualityCmaintenanceThe intelligent execution layer for coding agents, exposed as an MCP server for high-stakes engineering projects. It enables AI agents to manage plans, tasks, and integrations via tool calls.25MIT
- AlicenseNot gradedqualityDmaintenanceA Model Context Protocol (MCP) server that turns multiple AI coding agents into a coordinated team that chats, debates, remembers, audits security, and works in parallel on the same project.MIT
- FlicenseAqualityDmaintenanceAn MCP server that exposes tools for sub-agent style reasoning across multiple LLM providers, enabling delegation of prompts to various models and running critique loops, debates, red-teaming, and answer ranking.6-