How does Microsoft configure Local MCP servers in MCP Center (Azure API Center)

by

Summary

Microsoft’s “Local” MCP servers in MCP Center are internally modeled using custom metadata and are not currently configurable or publishable by customers. Public tenants can only register remote MCP servers; there is no supported API, ARM/Bicep, or Terraform schema for registering local (stdio‑based) MCP servers.

Root Cause

Local MCP servers shown in MCP Center are not customer‑managed resources.
They are Microsoft‑owned entries created using custom metadata inside Azure API Center, as demonstrated in the MCP Registry reference implementation.

Key points:

  • Microsoft uses custom metadata to model “Local” MCP servers.
  • The feature is not exposed in the Azure Portal or API Center UI for customers.
  • Only remote MCP servers are supported for customer registration.

Why This Happens in Real Systems

  • Internal features often appear in shared UI surfaces before they are publicly supported.
  • Metadata-driven registries (like API Center) allow Microsoft to model internal or experimental resources without exposing configuration paths to customers.
  • Stdio-based MCP servers require local runtime integration, which Azure API Center does not currently orchestrate for tenants.

Real-World Impact

  • Customers cannot replicate Microsoft’s “Local” MCP entries.
  • Attempts to find UI or API endpoints for local MCP registration lead to dead ends.
  • Automation (ARM/Bicep/Terraform) cannot manage these entries because no schema exists.
  • Organizations may incorrectly assume the feature is available and waste time searching for hidden configuration options.

Example or Code (if necessary and relevant)

Below is an example of how Microsoft models local MCP servers using custom metadata in the public reference implementation (this is not supported for customers in API Center):

{
  "name": "MongoDB MCP Server",
  "type": "mcp",
  "metadata": {
    "mcp.serverType": "local",
    "mcp.transport": "stdio"
  }
}

This demonstrates the internal modeling approach, not a supported customer workflow.

How Senior Engineers Fix It

Senior engineers typically:

  • Confirm feature availability by checking public docs and reference repos.

  • Identify unsupported paths early to avoid wasted engineering cycles.

  • Use only remote MCP registration, which is supported in API Center.

  • Track roadmap updates and engage Microsoft product teams when internal-only features appear in shared UI surfaces.

Why Juniors Miss It

  • They assume UI parity between Microsoft’s internal environment and customer environments.
  • They expect stdio/local MCP to be configurable because it appears in the portal.
  • They search for hidden settings instead of verifying feature support.
  • They may not check reference implementations, where Microsoft explicitly states that local MCP servers were modeled using custom metadata.

Leave a Comment