May 30, 2026 · Architecture

Remote vs. local MCP servers

MCP servers come in two forms — local and remote — and the difference decides how an AI tool gets installed, secured, and maintained across a firm. AECdesign.ai is remote, on purpose. (For the basics of what an MCP server is, see the FAQ.)

Local servers (stdio)

A local MCP server runs on your own machine. The client launches it as a process and talks to it over standard input/output (stdio), and it picks up credentials from local environment variables. This is excellent for developers and personal use — but it has to be installed, updated, and secured on every workstation that needs it. For a 30-person firm, that is 30 installs to keep in sync.

Remote servers (HTTP / streamable)

A remote MCP server runs over the internet and is reached over an HTTP transport (originally HTTP + Server-Sent Events, now consolidated into a streamable HTTP endpoint). You connect the client once; the tools are then available without shipping an installer to each machine, and they can be improved centrally. The tradeoff is that a server reachable over the network needs real authentication — which is the subject of the next post.

Why AECdesign.ai is remote

• One connection, not many installs. Your licensed users connect Claude Desktop once.
• Central maintenance. Review tools are updated server-side; nobody chases versions per workstation.
• Authenticated access. The server is reached through a verified connection, not an open port.
• Logic stays server-side. The review work runs on the server; the client receives the result.

Sources

• Understanding Authorization in MCP (HTTP transports vs. local stdio).
• Understanding MCP Authorization, Step by Step — Christian Posta (HTTP/SSE transport).
• An Introduction to MCP and Authorization — Auth0.

Draft, not determination. Every substantive AECdesign.ai result is a draft. A licensed engineer of record must review, revise, accept, or reject each finding before it is issued. AECdesign.ai never provides a sealed determination.