Reactive Multi Agent MCP Server is a .NET 10 Model Context Protocol server for hub-and-spoke multi-agent orchestration inside GitHub Copilot Chat and any MCP-capable client.

It gives AI assistants a durable, structured orchestration layer for decomposing complex requests into typed tasks, routing them to domain-specialist agents, tracking execution waves with dependency awareness, recording structured artifacts, and persisting session state across restarts — all backed by a local SQLite store with no external dependencies.

It is implemented in C# on net10.0 using ModelContextProtocol 1.4.0.

Click to install in your preferred environment:

Note: These install links are prepared for the intended NuGet package identity CP.Reactive.Multi.Agent.MCP.Server. If the latest package has not been published yet, use the manual source-build configuration below.

Without structured orchestration, AI agents tackle complex requests sequentially, have no shared state between turns, and cannot hand work off between specialists. Reactive Multi Agent solves this by giving the AI host:

• Decompose any user request into typed tasks with agent assignments, execution phases, and dependency graphs — automatically
• Route each task to the right domain-specialist: C#, ReactiveUI, WPF, WinForms, Avalonia, MAUI, Blazor, MCP, CI, docs, migration, testing, or review
• Parallelise independent tasks in the same execution wave without extra orchestration code
• Persist session state durably in SQLite so sessions survive restarts and can be resumed mid-execution
• Track structured artifacts (source files, config, blueprints, test plans, reviews) and handoff items across agent boundaries
• Recover from context-window limits, network loss, and token budget exhaustion with automated checkpoint, retry, and resume policies
• Supervise in-flight sessions: detect stalled tasks, silent heartbeats, stale supervisor actions, and escalate automatically
• Manage specialist sub-agent lifecycles with meaningful AgentName values, stable AgentSessionId correlation, and explicit shutdown instructions when work completes
• Audit every maintenance sweep with trend-aware health reports (stable / improving / worsening) persisted per session

This server is intended for:

• Copilot Chat workflows that require multi-step, multi-specialist code generation across a full application
• AI agents building .NET solutions from scratch that span multiple UI frameworks or technology stacks
• Long-running orchestration sessions that need checkpoint/resume continuity across context resets
• Orchestration pipelines where structured artifacts and handoff items need to flow between agents

Reactive Multi Agent organises work using a hub-and-spoke model with a central orchestration control plane:

Tasks within an execution wave are independent and can run in parallel. The orchestrator determines the wave assignment from the dependency graph it constructs during request decomposition.

Wave 1 ──► [architect]                  (blocking: all others depend on this)
Wave 2 ──► [csharp] [reactiveui] [mcp]  (independent — run in parallel)
Wave 3 ──► [tester] [docs]              (depend on wave 2 outputs)
Wave 4 ──► [reviewer]                   (depends on tester + docs)

Each task tracks a RecoveryState with automatic policy recommendations:

All session state is stored locally in SQLite — no external services or API keys are required.

When this server is active, agents should follow the Reactive Multi Agent Protocol:

The orchestration/control-plane agent should use GPT-5.5 or an equivalent highest-capacity model so it can hold the complete request, dependency graph, session state, specialist outputs, and final synthesis context. Smaller specialist agents may be used only for bounded worker tasks after the orchestration session has been created.

1. Call multiagent_orchestrate_request with the user's top-level request to create the session and get the full execution plan. If the MCP host discovers tools by creation semantics, call the explicit alias multiagent_create_session; both tools create the same durable session payload. This is the required first write tool before any specialist worker agent call because worker tools require the returned sessionId and task ids.
2. Inspect session.plan.executionWaves — work through waves in phaseOrder order.
3. Within each wave, dispatch all tasks to their assigned specialist agent tools in parallel when the client supports parallel tool calls.
4. Each specialist agent tool call returns an AgentTaskPacket with agentName, agentSessionId, executionPrompt, lifecycleInstruction, and nextSteps. Use agentName as the visible sub-agent name and keep agentSessionId as the correlation id.
5. When a specialist agent produces output, call its tool again with workSummary, artifacts, handoffItems, risks, and markComplete: true.
6. If the returned packet has shutdownRequired: true, close the named sub-agent immediately and do not continue work in that agent context.
7. If an agent hits a context limit, call its tool with createCheckpoint: true and checkpointSummary, then later resume with multiagent_resume_task.
8. Periodically call multiagent_supervisor_plan to check for stalled tasks, silent heartbeats, and supervisor actions that need acknowledgement.
9. Call multiagent_get_maintenance_report on a schedule to receive trend-aware health diagnostics and auto-applied policy actions.
10. Call multiagent_finalize_session to merge all completed specialist outputs into a unified response.
11. Use the create_multi_agent_plan, create_specialist_agent_prompt, and merge_multi_agent_results prompts as guided shortcuts for the above workflow.

Every worker tool returns an AgentTaskPacket. MCP clients should treat these fields as lifecycle instructions:

When shutdownRequired is true, the correct client behavior is to close the named sub-agent and release the agent-scoped session. Start a fresh named sub-agent only after a later task packet asks for additional work.

All tools and resources execute through a safe JSON wrapper. If a tool fails validation or throws, the server returns an error envelope instead of terminating the MCP host:

{
  "ok": false,
  "operation": "multiagent_session_status",
  "error": {
    "type": "ArgumentException",
    "message": "sessionId is required."
  },
  "guidance": "The MCP server handled the failure and returned a safe error payload instead of terminating the host process."
}

Prompt failures return a safe fallback text response naming the failed operation and exception. Blank required parameters are reported in the same safe shape so clients can ask the user for the missing value.

Decomposes a user request into a full orchestration plan and creates a persisted session.

This is the required session-creation tool. Call it before any multiagent_*_agent worker tool, then pass the returned sessionId and task taskId values into worker calls. The returned startup payload includes the orchestratorModelRequirement field, which instructs clients to keep orchestration/control-plane context on GPT-5.5 or an equivalent highest-capacity model.

Parameters:

• userRequest — the top-level user request to decompose
• constraints (optional) — comma-separated constraints to apply during decomposition (e.g. "no external packages,net10 only")
• desiredArtifacts (optional) — comma-separated list of desired output artifact types (e.g. "source files,tests,docs")
• preferredAgents (optional) — comma-separated agent ids to prioritise during routing
• maxParallelAgents (default: 4) — maximum number of agents that may run concurrently within a wave

Returns: the created OrchestrationSession and an OrchestrationSummary with task status, ready tasks, and blocked tasks.

When to use: Call this once per user request at the start of every multi-agent workflow. The returned sessionId is required by all subsequent tool calls.

Explicit session-creation alias for multiagent_orchestrate_request.

Some MCP clients rank or filter tools by direct creation terms. This alias prevents those clients from seeing only specialist worker tools and assuming no orchestration endpoint exists. It accepts the same parameters and returns the same startup payload as multiagent_orchestrate_request.

Parameters: Same as multiagent_orchestrate_request.

When to use: Use this at the start of a workflow when the host asks for a create-session style tool, or when multiagent_orchestrate_request is not surfaced by the client's tool search. Do not call worker tools until either multiagent_orchestrate_request or multiagent_create_session has returned a sessionId and task ids.

Returns the current state of an orchestration session including supervisor status.

Parameters:

• sessionId — the session to inspect

Returns: the full OrchestrationSession, its OrchestrationSummary, and a SupervisorStatus snapshot with alerts and next-runnable tasks.

When to use: Call after completing one or more tasks to assess overall progress, surface newly unblocked tasks, and check for supervisor alerts before continuing.

Evaluates the session, merges all completed specialist outputs, and produces a unified response.

Parameters:

• sessionId — the session to finalize

Returns: an OrchestrationSummary with unifiedResponse, completion counts, pending work, and coordination notes.

When to use: Call when all tasks in the final execution wave are complete. Can also be called at any intermediate point to get a partial merged view.

Resumes a task that was interrupted by a context limit, failure, or checkpoint.

Parameters:

• sessionId — the session containing the task
• taskId — the task to resume
• agentId — the agent resuming the task

Returns: an AgentTaskPacket containing the resumed execution prompt, checkpointed artifacts, and memory reload items.

When to use: Call after a task has been checkpointed or reported as failed with ResumeRequired. The returned execution prompt includes the prior work summary so the agent can continue from the checkpoint without full context reload.

Evaluates and resumes an orchestration session that has stalled or been partially interrupted.

Parameters:

• sessionId — the session to resume

Returns: an OrchestrationResumeState with pending action IDs, recommended next steps, and incomplete action IDs.

When to use: Call when returning to a session after a connection drop or host restart to identify what needs to be resumed and in what order.

Updates the lifecycle state of a supervisor action.

Parameters:

• sessionId — the session containing the action
• actionId — the supervisor action ID to update
• state — the new state: Pending, Acknowledged, Completed, or Abandoned

When to use: Call when the client has received, acted on, or abandoned a supervisor action generated by multiagent_supervisor_plan or a maintenance sweep. Keeping action states current prevents duplicate alerts on subsequent supervisor evaluations.

Applies time-based escalation to all pending supervisor actions in a session.

Parameters:

• sessionId — the session to evaluate
• staleAfterMinutes (default: 30) — minutes after which a pending action becomes stale
• criticalAfterMinutes (default: 90) — minutes after which a stale action becomes critical

Returns: updated escalation counts per action.

When to use: Call on a periodic schedule (e.g. alongside maintenance sweeps) to surface actions that have been pending too long and require immediate attention.

Records a liveness heartbeat for a session, task, agent, or supervisor action.

Parameters:

• sessionId — the session to heartbeat
• taskId (optional) — specific task to heartbeat
• agentId (optional) — specific agent to heartbeat
• actionId (optional) — specific supervisor action to heartbeat
• source (default: "external") — the heartbeat source identifier

When to use: Call regularly while an agent is actively working a task to prevent the supervisor from raising SilentHeartbeat alerts. Also call after reconnecting to mark the session as live.

Runs a full maintenance sweep over a session: detects silent heartbeats, stale tasks, and stale supervisor actions, and applies automated recovery policies.

Parameters:

• sessionId — the session to sweep
• silentHeartbeatMinutes (default: 15) — threshold for silent heartbeat detection
• staleTaskMinutes (default: 30) — threshold for stale task detection
• staleActionMinutes (default: 30) — threshold for stale supervisor action detection
• criticalActionMinutes (default: 90) — threshold for critical supervisor action escalation

Returns: a MaintenanceReport listing findings, recommended actions, auto-applied actions, heartbeat issues, resume-required task IDs, and incomplete supervisor action IDs.

When to use: Call on a periodic schedule to keep the session healthy. Suitable for a background cron-style polling loop.

Generates a diagnostic maintenance report for a session, optionally auto-applying recovery policies.

Parameters:

• sessionId — the session to diagnose
• silentHeartbeatMinutes (default: 15) — threshold for silent heartbeat detection
• staleTaskMinutes (default: 30) — threshold for stale tasks
• staleActionMinutes (default: 30) — threshold for stale supervisor actions
• criticalActionMinutes (default: 90) — threshold for critical escalation
• autoApplyPolicies (default: false) — automatically apply recommended recovery policies
• networkRecovered (default: false) — signal that network connectivity has been restored (triggers network-loss recovery policies)

Returns: a MaintenanceReport with verdict, findings, recommended actions, auto-applied actions, heartbeat issues, trend classification (Stable / Improving / Worsening), trend summary, and recent maintenance history snapshots.

When to use: Use this in preference to multiagent_run_maintenance_sweep when you want to inspect the report before committing to automated actions. Set autoApplyPolicies: true for fully autonomous maintenance.

Returns the persisted maintenance report history for a session.

Parameters:

• sessionId — the session to query
• limit (default: 10) — maximum number of recent snapshots to return

Returns: a list of MaintenanceSnapshot records, each containing verdict, heartbeat issue count, alert count, resume-required count, incomplete supervisor action count, and the cron summary.

When to use: Use to review the maintenance health trend of a session over time, or to present a diagnostic timeline to the user.

Evaluates and applies the automatic recovery policy for a specific task and agent.

Parameters:

• sessionId — the session containing the task
• taskId — the task to evaluate
• agentId — the agent assigned to the task
• currentEstimatedTokens (optional) — current estimated token usage (for context-window budget evaluation)
• remainingSubscriptionTokens (optional) — remaining subscription tokens (for subscription budget evaluation)
• networkRecovered (default: false) — whether network connectivity has been restored

Returns: an AutomaticPolicyState indicating which automated actions were recommended or applied: AutoCheckpointRecommended, AutoResumeRecommended, AutoRetryRecommended, along with retry attempt counts and a PolicyReason.

When to use: Call when an agent encounters a potential failure condition (token pressure, network loss) and you want the server to compute the appropriate policy response before deciding how to proceed.

Searches persisted orchestration sessions by query text.

Parameters:

• query (optional) — free-form text to filter sessions by; omit to return all recent sessions
• limit (default: 20) — maximum results to return

Returns: a list of matching SessionHistoryEntry records with session IDs, request summaries, status, task counts, and timestamps.

When to use: Use to locate a previous session to resume, or to present a history list to the user.

Returns the current supervisor evaluation for a session: alerts, stalled tasks, next runnable tasks, and heartbeat issues.

Parameters:

• sessionId — the session to evaluate
• stalledAfterMinutes (default: 30) — threshold for stalled task detection

Returns: a SupervisorStatus with Alerts (each with a SupervisorAlertKind), StalledTaskIds, NextRunnableTasks, HeartbeatIssues, and Recommendations.

Alert kinds include: StalledTask, ResumeRequired, AutoCheckpointRecommended, AutoRetryRecommended, BlockedByDependency, StaleSupervisorAction, SilentHeartbeat.

When to use: Call between execution waves to check for problems before dispatching the next set of tasks.

Produces a prioritised action plan from the supervisor evaluation, optionally auto-applying recovery policies.

Parameters:

• sessionId — the session to plan for
• stalledAfterMinutes (default: 30) — stalled task threshold
• autoApplyPolicies (default: false) — automatically apply recommended policies
• networkRecovered (default: false) — signal network recovery

Returns: a SupervisorActionPlan with OrderedActions, AutoAppliedActions, NextRunnableTasks, and ActionIds.

When to use: Use instead of multiagent_supervisor_status when you want a prioritised to-do list rather than a raw status snapshot, especially when autoApplyPolicies: true is appropriate.

All specialist agent tools share the same parameter signature. Each tool activates or updates the task context for its domain. The agent executes its work, then calls the same tool again to submit results.

Common parameters (all agent tools):

• sessionId — the orchestration session ID
• taskId — the task ID assigned to this agent
• additionalContext (optional) — extra context to inject into the execution prompt
• workLog (optional) — running notes from the agent's work in progress
• workSummary (optional) — final work summary to record against the task
• artifacts (optional) — array of AgentArtifact objects produced by the agent
• handoffItems (optional) — array of HandoffItem objects for downstream agents
• risks (optional) — array of risk strings identified during the work
• markComplete (default: false) — mark the task as completed and submit all results
• createCheckpoint (default: false) — create a named checkpoint for later resumption
• checkpointSummary (optional) — description to attach to the checkpoint
• memoryReloadItems (optional) — key context strings to include in the resume prompt after a context reset
• failureKind (default: None) — report a failure: ContextWindowLimit, NetworkLoss, TokenBudgetLow, SubscriptionTokensExhausted, or Unknown
• failureReason (optional) — human-readable explanation for the failure
• currentEstimatedTokens (optional) — current estimated token count for budget tracking
• remainingSubscriptionTokens (optional) — remaining subscription tokens for budget tracking

First call (activate): Call with sessionId + taskId only (plus optional additionalContext / workLog) to receive the AgentTaskPacket with the executionPrompt.

Subsequent call (submit results): Call with workSummary, artifacts, handoffItems, risks, and markComplete: true to record the completed output.

Checkpoint call: Call with createCheckpoint: true and checkpointSummary to save progress. Follow with multiagent_resume_task after a context reset.

Failure call: Call with failureKind set to a non-None value to record the failure and trigger the automatic policy evaluator.

Activate or update the Architect Agent — owns decomposition, system design, boundaries, and cross-agent coordination framing.

Skills: system design, dependency mapping, planning, trade-off analysis.

Activate or update the C# Agent — owns general C# and .NET implementation work when no narrower UI or domain agent is a better fit.

Skills: C#, .NET 10, project scaffolding, implementation.

Activate or update the Reactive Agent — owns Rx and stream-oriented orchestration work.

Skills: Reactive Extensions, observable composition, IObservable, stream-oriented architecture.

Activate or update the ReactiveUI Agent — owns ReactiveUI-specific implementation work.

Skills: ReactiveUI, MVVM, ReactiveCommand, WhenAnyValue, activation, routing, DynamicData.

Activate or update the MCP Agent — owns MCP tool, resource, prompt, and protocol-specific work.

Skills: ModelContextProtocol, tool authoring, resource definitions, prompt templates.

Activate or update the CI Agent — owns pipeline, publishing, and automation work.

Skills: GitHub Actions, NuGet publishing, automated workflows, release pipelines.

Activate or update the Docs Agent — owns README, onboarding, and usage documentation.

Skills: Markdown, README authoring, API documentation, installation guides.

Activate or update the Migration Agent — owns modernization and upgrade planning.

Skills: .NET upgrade, framework migration, legacy modernization, migration plans.

Activate or update the WPF Agent — owns WPF and XAML-specific implementation work.

Skills: WPF, XAML, data binding, styles, control templates, WPF-specific ReactiveUI.

Activate or update the WinForms Agent — owns Windows Forms-specific implementation work.

Skills: WinForms, designer-generated code, data binding, control layout.

Activate or update the Avalonia Agent — owns Avalonia-specific implementation work.

Skills: Avalonia UI, AXAML, cross-platform desktop, Avalonia ReactiveUI integration.

Activate or update the MAUI Agent — owns MAUI-specific implementation work.

Skills: .NET MAUI, cross-platform mobile/desktop, XAML, Shell navigation, MAUI ReactiveUI.

Activate or update the Blazor Agent — owns Blazor and Razor-specific implementation work.

Skills: Blazor WebAssembly, Blazor Server, Razor components, interop, Blazor ReactiveUI.

Activate or update the Test Agent — owns verification, testing, and regression work.

Skills: TUnit, TUnit assertions, test design, coverage, regression verification.

Activate or update the Reviewer Agent — owns critique, security, and readiness checks.

Skills: code review, security analysis, SOLID, API readiness, performance concerns.

Returns all specialist agent profiles registered in the embedded catalog.

Returns: count and agents array of AgentProfile records, each with id, domain, category, displayName, summary, role, toolName, defaultSkills, defaultTools, routingKeywords, and completionContract.

When to use: Use at the start of a session to understand what agents are available, or to present an agent selection menu to the user.

Searches the agent catalog by domain, category, skills, keywords, or tool names.

Parameters:

• query (optional) — free-form search text such as "reactiveui", "ci pipeline", "avalonia", or "migration"; omit to return all

When to use: Use when you need to find the right agent for a specific technology or task domain before assigning work, or to let the user browse agents by topic.

Returns the full manifest for one specialist agent by ID.

Parameters:

• id — the agent ID: architect, csharp, reactive, reactiveui, mcp, ci, docs, migration, wpf, winforms, avalonia, maui, blazor, tester, or reviewer

When to use: Use before dispatching a task to a specific agent to verify its skills, tools, routing keywords, and completion contract.

Resources are read-only snapshots exposed at stable URIs. Use them to inspect session and catalog state without modifying anything.

The complete embedded agent catalog as JSON. Returns all agent profiles with IDs, domains, skills, tools, and routing keywords.

Full snapshot of one orchestration session: the OrchestrationSession, its OrchestrationSummary, SupervisorStatus, SupervisorActionPlan, ExecutionLedger, ResumeState, and SupervisorActions.

The 20 most recent orchestration sessions as a list of SessionHistoryEntry records. Useful for presenting a session history picker.

The architecture description for the hub-and-spoke orchestration model, including the control plane components: execution ledger, supervisor action lifecycle, orchestration-level resume state, and task-level checkpoint/retry/resume continuity.

An example schema for structured AgentArtifact and HandoffItem objects. Use to understand the expected structure before having agents emit artifacts.

Prompts provide guided shortcuts for the most common orchestration workflows.

Creates a prompt that tells the MCP client how to orchestrate a single top-level request through the orchestrator tool and dependency-aware specialist agents.

Parameters:

• userRequest — the user's top-level request
• constraints (optional) — comma-separated constraints
• desiredArtifacts (optional) — comma-separated desired artifacts
• preferredAgents (optional) — comma-separated preferred agent IDs

Returns a step-by-step execution guide listing which tasks belong to each phase and can run in parallel.

Creates the isolated execution prompt for a specific specialist agent task inside an orchestration session.

Parameters:

• sessionId — the orchestration session ID
• taskId — the task ID
• agentId — the assigned agent ID

Returns the executionPrompt from the agent's AgentTaskPacket — ready to use as the context for the agent's work turn.

Creates a synthesis prompt that merges all currently recorded specialist outputs into one coherent answer.

Parameters:

• sessionId — the orchestration session ID

Returns a formatted synthesis prompt showing the session status, completed/total task counts, ready task IDs, and the current unified response.

README.md                                # Package README and feature guide
.mcp/server.json                         # MCP package manifest for dnx-based clients
skills/Reactive-Multi-Agent/SKILL.md     # Codex skill shipped with the MCP server package
src/
├── Reactive.Multi.Agent.MCP.Core/        # Models, abstractions, services, persistence
├── Reactive.Multi.Agent.MCP.Knowledge/   # Embedded agent catalog (JSON profiles)
├── Reactive.Multi.Agent.MCP.Server/      # MCP host, tool/resource/prompt registration
├── Reactive.Multi.Agent.MCP.Tests/       # Unit and integration tests
└── Reactive.Multi.Agent.MCP.Server.slnx  # Solution file

The hosted MCP server stores all data under the .NET LocalApplicationData folder by default, in a ReactiveMultiAgentMcp child directory. On Windows this is typically %LocalAppData%\ReactiveMultiAgentMcp. No external database, API key, or connection string is required.

The executable reads these environment variables at startup:

Configuration can also be overridden by providing a ReactiveMultiAgentOptions instance when hosting the server programmatically:

The packaged .mcp/server.json manifest uses runtimeHint: "dnx" and sets DOTNET_SKIP_FIRST_TIME_EXPERIENCE=1 and DOTNET_NOLOGO=1 for quieter client startup.

The NuGet package includes skills/Reactive-Multi-Agent/SKILL.md alongside the MCP manifest. Use that skill when an agent needs operational instructions for this server: creating sessions, selecting specialists, spawning named sub-agents, recording heartbeats/checkpoints/results, applying recovery policies, finalizing sessions, and closing sub-agents once shutdownRequired is true.

dotnet build src/Reactive.Multi.Agent.MCP.Server.slnx

Build first, then run the TUnit test project:

dotnet test src/Reactive.Multi.Agent.MCP.Tests/Reactive.Multi.Agent.MCP.Tests.csproj

To collect coverage:

dotnet test src/Reactive.Multi.Agent.MCP.Tests/Reactive.Multi.Agent.MCP.Tests.csproj --coverage --coverage-output coverage.cobertura.xml --coverage-output-format cobertura

The test suite covers MCP host registration, tool/resource/prompt payload contracts, safe error handling, blank-parameter validation, orchestration decomposition, lifecycle and shutdown packets, supervisor actions, automatic policies, persistence, maintenance reports, session history, and package-facing metadata.

The latest verified local coverage for this suite is 98.08% line coverage and 90.64% branch coverage.

• .NET 10 SDK
• An MCP-capable client (VS Code, Visual Studio, Claude Desktop, or any MCP 1.x host)

Once the NuGet package is published:

dotnet tool install -g CP.Reactive.Multi.Agent.MCP.Server

Then configure your MCP client:

{
  "type": "stdio",
  "command": "reactive-multi-agent-mcp-server"
}

Use the badge links at the top of this file, or configure manually:

{
  "type": "stdio",
  "command": "dnx",
  "args": ["CP.Reactive.Multi.Agent.MCP.Server@1.*", "--yes"]
}

Clone the repository and configure your MCP client to launch the server from the built output:

{
  "name": "reactive-multi-agent-mcp-server",
  "type": "stdio",
  "command": "dotnet",
  "args": [
    "run",
    "--project",
    "/path/to/Reactive.Multi.Agent.MCP.Server/src/Reactive.Multi.Agent.MCP.Server/CP.Reactive.Multi.Agent.MCP.Server.csproj"
  ]
}

{
  "mcp": {
    "servers": {
      "reactive-multi-agent-mcp-server": {
        "type": "stdio",
        "command": "dotnet",
        "args": [
          "run",
          "--project",
          "/path/to/Reactive.Multi.Agent.MCP.Server/src/Reactive.Multi.Agent.MCP.Server/CP.Reactive.Multi.Agent.MCP.Server.csproj"
        ]
      }
    }
  }
}

Navigate to Tools → Options → GitHub → Copilot → MCP Servers and add:

{
  "name": "CP.Reactive.Multi.Agent.MCP.Server",
  "type": "stdio",
  "command": "dotnet",
  "args": [
    "run",
    "--project",
    "/path/to/Reactive.Multi.Agent.MCP.Server/src/Reactive.Multi.Agent.MCP.Server/CP.Reactive.Multi.Agent.MCP.Server.csproj"
  ]
}

{
  "mcpServers": {
    "reactive-multi-agent-mcp-server": {
      "command": "dotnet",
      "args": [
        "run",
        "--project",
        "/path/to/Reactive.Multi.Agent.MCP.Server/src/Reactive.Multi.Agent.MCP.Server/CP.Reactive.Multi.Agent.MCP.Server.csproj"
      ]
    }
  }
}

MIT