Repository navigation
Add AI agent hosting integration - #2249
Conversation
|
🚀 Dogfood this PR with:
curl -fsSL https://raw.githubusercontent.com/CommunityToolkit/Aspire/main/eng/scripts/dogfood-pr.sh | bash -s -- 2249Or
iex "& { $(irm https://raw.githubusercontent.com/CommunityToolkit/Aspire/main/eng/scripts/dogfood-pr.ps1) } 2249" |
|
One or more custom setup steps configured for this repository failed during this Copilot code review run: Setup steps run before each review. If the review above is missing context, or no review was posted at all, the failing step above may be the cause. See the workflow run for failure details, fix your setup steps configuration, and re-request a review. Note You can configure setup steps for Copilot code review separately from Copilot cloud agent with a |
There was a problem hiding this comment.
🟡 Changes recommended
Unresolved protocol request, response-validation, and command-handling defects prevent reliable agent invocation.
5 open findings
What changed in this PR
Adds a preview AI-agent hosting integration to the Toolkit, bringing endpoint metadata and local dashboard invocation commands without changing core Aspire behavior.
Changes:
- Adds multi-protocol agent configuration and opt-in MCP tool commands.
- Ports protocol tests, test helpers, and publish-expression snapshots.
- Includes six examples, documentation, package metadata, and repository registration.
| File | Description |
|---|---|
| tests/CommunityToolkit.Aspire.Hosting.Agents.Tests/WithMcpToolCommandsTests.cs | Tests MCP invocation and session cleanup. |
| tests/CommunityToolkit.Aspire.Hosting.Agents.Tests/TestServices/TestServiceProvider.cs | Supplies test configuration services. |
| tests/CommunityToolkit.Aspire.Hosting.Agents.Tests/TestServices/TestInteractionService.cs | Simulates dashboard interactions. |
| tests/CommunityToolkit.Aspire.Hosting.Agents.Tests/TestServices/TestDistributedApplicationBuilder.cs | Creates run/publish test builders. |
| tests/CommunityToolkit.Aspire.Hosting.Agents.Tests/TestServices/McpTestResource.cs | Provides a simulated MCP resource. |
| tests/CommunityToolkit.Aspire.Hosting.Agents.Tests/TestServices/EnvironmentVariableEvaluator.cs | Evaluates resource environment configuration. |
| tests/CommunityToolkit.Aspire.Hosting.Agents.Tests/TestServices/AsyncTestHelpers.cs | Bounds asynchronous test waits. |
| tests/CommunityToolkit.Aspire.Hosting.Agents.Tests/Snapshots/AgentResourceBuilderExtensionsTests.AsAgent_PublishPreservesEndpointExpressionsWithoutCommands.verified.txt | Records deferred endpoint expressions. |
| tests/CommunityToolkit.Aspire.Hosting.Agents.Tests/Directory.Packages.props | Aligns local xUnit dependencies. |
| tests/CommunityToolkit.Aspire.Hosting.Agents.Tests/CommunityToolkit.Aspire.Hosting.Agents.Tests.csproj | Configures the integration test project. |
| src/CommunityToolkit.Aspire.Hosting.Agents/README.md | Documents APIs, scope, and authentication boundaries. |
| src/CommunityToolkit.Aspire.Hosting.Agents/McpToolCommandResourceBuilderExtensions.cs | Implements MCP invocation commands. |
| src/CommunityToolkit.Aspire.Hosting.Agents/CommunityToolkit.Aspire.Hosting.Agents.csproj | Defines the preview hosting package. |
| src/CommunityToolkit.Aspire.Hosting.Agents/AgentResourceBuilderExtensions.cs | Implements agent configuration and protocol commands. |
| src/CommunityToolkit.Aspire.Hosting.Agents/AgentResourceAnnotation.cs | Stores agent protocol metadata. |
| src/CommunityToolkit.Aspire.Hosting.Agents/AgentProtocol.cs | Defines supported agent protocols. |
| src/CommunityToolkit.Aspire.Hosting.Agents/A2AInvocationMode.cs | Defines A2A invocation modes. |
| README.md | Adds the package to the gallery. |
| examples/agents/weather-agent-python/weather_agent_python/main.py | Implements the Python A2A agent. |
| examples/agents/weather-agent-python/weather_agent_python/__init__.py | Declares the A2A sample package. |
| examples/agents/weather-agent-python/tests/test_executor.py | Tests executor cancellation and cleanup. |
| examples/agents/weather-agent-python/pyproject.toml | Defines A2A sample dependencies. |
| examples/agents/weather-agent-python/.python-version | Selects the Python runtime. |
| examples/agents/vercel-ai-responses-agent/tsconfig.json | Configures TypeScript checking. |
| examples/agents/vercel-ai-responses-agent/package.json | Defines Vercel sample dependencies and scripts. |
| examples/agents/vercel-ai-responses-agent/app.ts | Implements a Responses-compatible agent. |
| examples/agents/ResponsesAgent/ResponsesAgent.csproj | Configures the .NET Responses sample. |
| examples/agents/ResponsesAgent/Program.cs | Hosts Responses and MCP endpoints. |
| examples/agents/README.md | Documents sample setup and validation. |
| examples/agents/McpAgent/Program.cs | Exposes a model-backed MCP tool. |
| examples/agents/McpAgent/McpAgent.csproj | Configures the MCP sample project. |
| examples/agents/Directory.Packages.props | Scopes sample-specific .NET dependencies. |
| examples/agents/CommunityToolkit.Aspire.Hosting.Agents.AppHost/Properties/launchSettings.json | Configures local dashboard launch profiles. |
| examples/agents/CommunityToolkit.Aspire.Hosting.Agents.AppHost/CommunityToolkit.Aspire.Hosting.Agents.AppHost.csproj | References hosting integrations and samples. |
| examples/agents/CommunityToolkit.Aspire.Hosting.Agents.AppHost/AppHost.cs | Connects six samples to Foundry resources. |
| examples/agents/aspire.config.json | Identifies the example AppHost. |
| examples/agents/agui-acp-agent-python/pyproject.toml | Defines AG-UI/ACP sample dependencies. |
| examples/agents/agui-acp-agent-python/agui_acp_agent/main.py | Hosts AG-UI and ACP endpoints. |
| examples/agents/agui-acp-agent-python/agui_acp_agent/__init__.py | Declares the AG-UI/ACP package. |
| examples/agents/AgentEnvDump/Program.cs | Displays the injected agent-card URL. |
| examples/agents/AgentEnvDump/AgentEnvDump.csproj | Defines the diagnostic executable. |
| examples/agents/.gitignore | Excludes Python cache files. |
| CommunityToolkit.Aspire.slnx | Registers package, tests, and examples. |
| CODEOWNERS | Assigns integration ownership. |
Files not reviewed (1)
- examples/agents/vercel-ai-responses-agent/package-lock.json: Generated file
🧠 Review effort: Balanced
💡 Configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
e6b1911 to
e61e810
Compare
aaronpowell
left a comment
There was a problem hiding this comment.
Left a variety of comments throughout the files in the PR but probably the biggest thing I'm up against is that I'm not sure I really understand the workflow for this. If I'm understanding correctly, this makes it possible to expose via dashboard commands ways to interact with resources that are exposed as agents or MCP servers?
Would you be able to throw together a video in which it walks through the usage of this so I can get a better understanding of it?
|
@aaronpowell Yes, that is the intended workflow: these APIs add dashboard invocation commands to agent and MCP endpoints the application already exposes. They do not create an agent or host a model. Here is an 83-second walkthrough showing the AppHost configuration, a Responses invocation and its result, MCP tool discovery and generated arguments, the tool response, and cancellation. The recording uses a deterministic local Responses fixture and an official MCP SDK server, with no cloud resources or model calls. Requests execute in the AppHost process; authenticated endpoints still need a driver application that handles their authentication. The review fixes are in 168d097: standard .NET configuration, repository-root package versions, shared test helpers, exact publish assertions instead of the Verify snapshot/local xUnit overrides, Toolkit-scoped diagnostics, and clearer protocol dispatch and failure diagnostics. The MCP client implementation is unchanged in this pass; its limited scope is now explicit in the README. Validation: 301 agent tests and 29 MCP Inspector .NET tests passed; the examples build and the package packs for all three target frameworks. The additional MCP Inspector TypeScript check was blocked by a Yarn download timeout on this machine. agents-dashboard-walkthrough.mp4 |
aaronpowell
left a comment
There was a problem hiding this comment.
Thanks for the video, it helps me understand the flow that this would be useful for.
There is a merge conflict and an outstanding question regarding the user of a custom MCP client or using the official SDK - can you spike that and see what the diff looks like, does it reduce or increase complexity? would it be more maintainable long term? that sort of stuff. It doesn't have to be directly on this PR (it could be branched off)
Port microsoft/aspire#17757 via standalone source 8d93031b42666b353aee4a8370a8b5349703ad98. Preserve all protocols, MCP invocation, 277 tests and six examples, adapting Toolkit naming, packaging and test infrastructure. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Complete AG-UI inputs, preserve distinct protocol paths, correlate MCP tool responses, handle dialog cancellation and fall back to raw JSON for complex parameter schemas. Add regression coverage for all five review findings. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Reuse shared test helpers, centralize sample package versions, use application configuration, and document Toolkit diagnostics and the dashboard workflow. Preserve publish assertions without a local xUnit override and add safe agent-card failure diagnostics. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Use the shared test project's runtime setup, migrate sample .NET resources to AddDotnetProject, and retain explicit legacy ProjectResource regression coverage. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
168d097 to
4982971
Compare
I tried the SDK: it removes about 59% of our transport/execution code, keeps the dashboard UI unchanged, and adds no resolved dependencies on the current Aspire baseline. The tradeoff is weaker cleanup on malformed responses (some failure paths can leave a session or response undisposed) and less detailed errors. For user-triggered developer commands, I think that’s worth accepting in exchange for SDK-owned protocol maintenance. |
But won't we have those errors in the Aspire dashboard as traces anyway? |
Replace handwritten protocol handling with ModelContextProtocol.Core while preserving dashboard inputs, endpoint resolution, authentication boundaries, and bounded cleanup. Align MCP versions centrally and document accepted SDK failure-path limitations and actual dashboard diagnostics. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
|
yeah you r right @aaronpowell. i've pushed it. |
|


Fixes #2248
Ports microsoft/aspire#17757 into
CommunityToolkit.Aspire.Hosting.Agents, using the standalone extraction at 8d93031b42666b353aee4a8370a8b5349703ad98. Original .NET Foundation MIT notices and provenance are retained.The preview package models existing endpoint resources using
AsAgentand provides run-only developer invocation commands for A2A v0.3/v1 (JSON-RPC and HTTP+JSON; streaming opt-in), OpenAI Responses, AG-UI, ACP, and explicit.WithMcpServer(...).WithMcpToolCommands(). Extension methods and metadata types use Toolkit-standard namespaces. No coreAspire.Hostingchanges, genericWithReferencedispatcher, or generic HTTP-command changes are needed.The original test coverage and six examples are retained, with review-driven regression coverage and shared Toolkit test infrastructure. The former publish snapshot is covered by exact dictionary assertions. Packaging, framework targets, dependencies, and examples follow the repository's current Aspire 17 / net10.0 baseline. Dependency versions are centrally managed.
MCP SDK adoption
Following the maintainer review and an isolated comparison spike, MCP commands now use
ModelContextProtocol.Core1.4.1 instead of handwritten initialization, JSON/SSE parsing, response correlation, and session management. The MCP implementation is 268 lines smaller; public APIs, dashboard input controls, and endpoint resolution are unchanged. MCP package versions are aligned centrally at 1.4.1. Core was already present transitively through Aspire on this baseline.A small HTTP adapter preserves the configured AppHost HTTP client, independent five-second session-cleanup timeout, and safe cleanup warnings. Guarded pagination and raw tool-result presentation remain integration responsibilities.
Accepted, documented SDK limitations: malformed initialization may leave an assigned server session unclosed; parse/correlation failures may leave an HTTP response undisposed; malformed raw bodies and arbitrary JSON-RPC error data are not preserved. Tests tagged
SdkGapcharacterize these limitations rather than claim parity. These are experimental developer commands, not a durable client.PR Checklist
Other information
Latest validation completed without paid services or provisioning:
ASPIRE012remains.Earlier port validation covered manifest-only output, deterministic Python cancellation/cleanup, AG-UI/ACP routes, Vercel type-checking, generated ATS exports and TypeScript signatures, gallery wiring, and test discovery. No public API shape changed during SDK adoption.
Commands execute in the AppHost process. They do not implement sign-in, token acquisition/refresh, or forwarding of dashboard-user identity. Authenticated endpoints should use a driver application; endpoint authentication must not be disabled. Examples default to existing Foundry connections, with provisioning behind explicit
UseExistingFoundry=falseopt-in. No live model calls, Azure provisioning, role changes, or package publication were performed.Checked-in generated API/ATS compatibility baselines are left to the repository's review/release regeneration workflow; the ATS surface was generated separately for initial validation. The original upstream PR has not been modified or closed by this port.