Build MCP on Aspire: Part 2

Quick overview of the project

1. ApsMcp.AppHost
This is the main entry point for the application. It handles the configuration and startup of all services, managing how they work together. Think of it as the “control center” that coordinates everything else.

2. ApsMcp.ServiceDefaults
Contains common configurations and settings shared across all services. This includes things like standard error handling, logging formats, and security settings – essentially the “rule book” that all services follow.

3. ApsMcp.SseServer
Implements a Server-Sent Events (SSE) version of the Model Context Protocol server. This allows for real-time, one-way communication from the server to clients, enabling continuous data streams. This already uses the new HTTP streamable transport connection.

4. ApsMcp.StdioServer
Provides a standard input/output implementation of the MCP server, allowing for command-line based interactions and integration with other tools through standard streams.

5. ApsMcp.Tools
This is where the core functionality lives – it contains the actual tools and integrations with Autodesk Platform Services (APS). These tools are the “workers” that perform various operations with the Autodesk Construction Cloud.

6. ApsMcp.ChatWebapp.Web
A web interface for interacting with the MCP server, likely providing a user-friendly way to access the functionality.

7. ApsMcp.TestConsole
A testing utility for developers to verify functionality and perform debugging operations without using the whole application.

Why Aspire? Simplicity meets scale

We chose Aspire because it embodies two non‑negotiables for enterprise AI:

• URL-first connectivity. Spin up a cloud‑hosted MCP server accessible via a simple HTTPS endpoint. No local installs, no plugin juggling, just point your agents at a URL.
• Distributed by design. Aspire treats each MCP server as an independent microservice within a distributed application architecture. This enables isolated scaling, independent versioning, and seamless upgrades, key principles of building resilient, cloud-native systems.
• Local container support via Docker. For development, testing, or edge deployments, Aspire enables local container execution using Docker. This ensures parity between environments and supports use cases where cloud access is limited or where local control is essential.
• Built-in telemetry & tracking. Integrate with Application Insights or your preferred monitoring solution out of the box, capturing request metrics, error rates, and performance traces across your MCP endpoints to ensure reliability and observability.

.NET Aspire enhances the app-building experience by providing a range of projects and resources. With dev-time productivity enhancements that emulate deployed scenarios, you can quickly develop interconnected apps. Designed for flexibility, .NET Aspire allows you to replace or extend parts with your preferred tools and workflows. Key features include:

• Dev-Time Orchestration: .NET Aspire provides features for running and connecting multi-project applications, container resources, and other dependencies for local development environments.
• Integrations: .NET Aspire integrations are NuGet packages for commonly used services, such as Redis or Postgres, with standardised interfaces ensuring they connect consistently and seamlessly with your app.
  References: .NET Aspire Community Toolkit and .NET Aspire Community Toolkit Ollama integration

Deploy .NET Aspire projects to Azure Container Apps or any Kubernetes cluster takes minutes, not weeks. By decoupling MCP from desktop tools, you empower any engineer, PM, or analyst to call your services from anywhere.

Extract from the current APS MPC implementation.

var clientId = Env.GetString("APS_CLIENT_ID", "");
var clientSecret = Env.GetString("APS_CLIENT_SECRET", "");
var callbackUrl = Env.GetString("APS_CALLBACK_URL", "");
var serverType = Env.GetString("SERVER_TYPE");

var ollama = builder.AddOllama("ollama")
    .WithDataVolume()
    .WithOpenWebUI(config =>
    {
        config.WithImageTag("latest");
    });

var chat = ollama.AddModel("chat", "deepseek-r1:1.5b");
var embeddings = ollama.AddModel("embeddings", "nomic-embed-text");

var stdioServer = builder.AddProject("stdio-server")
    .WithEnvironment("APS_CLIENT_ID", clientId)
    .WithEnvironment("APS_CLIENT_SECRET", clientSecret)
    .WithEnvironment("APS_CALLBACK_URL", callbackUrl);

var sseServer = builder.AddProject("sse-server")
    .WithExternalHttpEndpoints()
    .WithEnvironment("APS_CLIENT_ID", clientId)
    .WithEnvironment("APS_CLIENT_SECRET", clientSecret)
    .WithEnvironment("APS_CALLBACK_URL", callbackUrl);

var webApp = builder.AddProject("ai-chatapp")
    .WithReference(chat)
    .WithReference(embeddings)
    .WithReference(qdrant)
    .WithReference(sseServer)
    .WithReference(stdioServer)
    .WaitFor(chat)
    .WaitFor(embeddings)
    .WaitFor(qdrant)
    .WaitFor(sseServer)
    .WaitFor(stdioServer)
    .WithEnvironment("SERVER_TYPE", serverType);

A dedicated client

You’ll hear about MCP demos in Anthropic Desktop, VS Code extensions, Windsurf, or Cursor, but none of those reach the broader enterprise. Product managers and engineers won’t launch a desktop client to trigger an API. They need:

• Zero‑install access: chatbots, web UIs, or lightweight CLI tools that call your MCP endpoint.
• Consistent UX: tool discovery, schema introspection, and request routing baked into a single experience.

While Microsoft’s recent announcement to embed MCP in Windows devices hints at native accessibility, that wave is still forming. For now, delivering an in‑browser or cloud function client ensures everyone can harness your MCP‐powered toolkit today.

Building a dedicated chat client using .NET Aspire offers an ideal middle ground between rapid development and enterprise-grade scalability. Aspire’s modular, microservice-first architecture enables clean separation of concerns, native support for observability, and seamless cloud-to-edge deployment. It’s tailored for teams working in distributed environments and aligns well with modern DevOps practices, making it a future-proof investment for organisations integrating Model Context Protocols at scale.

Because the client is a Blazor web app, it can be easily embedded into traditional desktop applications via WPF or integrated into multi-platform apps through .NET MAUI. This flexibility eliminates the friction of deploying yet another tool, allowing organisations to meet users where they already are—be it in design tools, dashboards, or custom engineering software—without duplicating efforts across platforms.

MCP OAuth: current decision and future development

Securing an MCP workflow requires more than simply distributing tokens; it involves a well-defined, multi-phase OAuth strategy that connects agents, servers, and downstream APIs. In the following sections, we will outline our practical development approach using APS today, followed by an overview of where the MCP specification is evolving.

Today’s development decision: APS as our OAuth orchestrator

MCP’s official authorisation spec is still under development, see Den Delimarsky’s draft on new MCP auth models (Den’s OAuth proposal). Rather than waiting, we built upon Autodesk Platform Services’ authentication infrastructure:

• APS auth server as gatekeeper. When an AI agent invokes a tool requiring APS credentials, such as reading BIM model data, it first calls the acc-3la-authentication MCP tool, which automates the three-legged PKCE flow, ensuring credentials are entered directly on Autodesk’s trusted domain. Once the user authorises access to their BIM 360 projects, APS redirects back to our MCP server’s local listener with an authorisation code. The server then exchanges this code for APS access and refresh tokens and produces a signed MCP token bound to those credentials.
• Seamless token handling. Agents never see raw tokens; they simply call tools by name and arguments. Aspire’s middleware handles token fetching, in-memory caching, automatic refreshes, and secure injection into each API call. This design adheres to best practices—PKCE protects against code interception, user credentials never touch our servers, and all token management remains transparent to the calling agent.

The steps up through Generate Bound MCP Token leverage the APS PKCE auth flow (see APS OAuth 3-legged PKCE tutorial).

Tomorrow’s development: spec alignment and multi-hop flows

On the horizon, the MCP spec itself is evolving. Indeed, a new update was made a couple of days ago regarding security best practices, as well as a recent technical panel on MCP authorisation featuring Aaron Parecki (Okta & IETF OAuth WG), Den Delimarsky (Microsoft), and William Dawson (Arcade.dev) described the two hops in of MCP OAuth.

First hop describes how an AI agent (the MCP Client) obtains permission to invoke tools on the MCP Server. The MCP spec now aligns with OAuth 2.1 by clearly distinguishing three roles: the client requesting capabilities, the resource server hosting them, and the authorisation server issuing tokens for that access. This separation prevents the confusion that arose when resource and auth servers were merged in earlier drafts.

For more on enterprise-grade MCP design patterns, see Aaron Parecki’s write-up on building enterprise-ready MCP deployments, Microsoft’s outlook on how AI agents and OAuth must evolve for business scenarios, and Den Delimarsky’s guide on remote MCP server best practices.

The second hop addresses how the MCP Server securely accesses downstream services, such as APS, Dropbox, and Gmail, on behalf of the user. Token handoffs from client to server are inherently risky. A promising solution is the Identity Assertion Authorisation Grant (in progress at the OAuth Working Group), championed by Aaron Parecki. In this model, the authorisation server can:

1. Validate the agent’s identity assertion (from corporate SSO, for instance).
2. Exchange that assertion for service-specific tokens, each scoped and proof-of-possession bound to its downstream API.

This approach offers cleaner separation of concerns, enhanced security, and enterprise visibility over every downstream connection.

This is just a draft based on the current conversations in the community.

Next step

In the following article, we will briefly examine the tools and we’ll dive into critical deployment considerations: the trade‑offs between StdIO and Server‑Sent Events (SSE/HTTP) transports and the various hosting models from cloud‑native services to containerised edge deployments; and even a fully local proof‑of‑concept using Ollama with a self‑hosted LLM that offers function‑calling. This will show how, with the right setup, complete end‑to‑end MCP workflows can run entirely on‑premise without external dependencies.

Since MCP is constantly evolving, we will incorporate any changes, discoveries, new implementations, or reviews of our previous work.

Serie
Model Context Protocol for AEC: Part 1