MCP (Model Context Protocol) — Architecture, Transports, Endpoints/Ports, and RAG

MCP does not “live” on a fixed port. It is used as a message protocol (often JSON-RPC) carried over a transport. That’s why stdio has no port, and HTTP/HTTPS uses a server URL endpoint (the port is simply your web service port: typically 443 in production, or something else in development).

Download as PDF

1 — Overview

Overview

MCP is a message protocol (often JSON-RPC) carried over a transport. stdio has no port; HTTP/HTTPS uses a URL endpoint (typically port 443 in production). Use the tabs above to jump to each section.

2 — How does it connect?

How does it connect?

Transport & target

stdio (local)

The client launches the server and communicates via stdin/stdout. No port.

HTTP/HTTPS (remote)

The client connects to a URL. The port is your service port (443 typical).

In production, the most common setup is to put your MCP server behind a reverse proxy / API gateway and expose an endpoint like: https://api.yourcompany.com/mcp/v1

Target = URL (HTTP/HTTPS)

Port = your web service port

443 recommended in production

# MCP over HTTP/HTTPS (remote) MCP_SERVER_URL="https://api.yourcompany.com/mcp/v1" # MCP over stdio (local) MCP_SERVER_CMD="node ./servers/filesystem-mcp"

Practical note: “pointing to the endpoint” also implies you must handle authentication, CORS (if a browser is involved), rate limits, and logging/observability.

3 — Layer analogy

Layer analogy

Mental model

Think of an MCP server like a well-run building, where each role has a clear responsibility.

Executive office / Policy

Central config + security: “what is allowed”.

Front desk / Transport

Inbound/outbound channel: stdio vs HTTP. “how requests arrive”.

Security gate

Validation, auth, rate limiting, logging: “who gets in and what is recorded”.

Below that is the “operations floor”: method routing, the tool catalog, resource access, and prompt templates. This separation helps you scale, audit, and control risk with less friction.

Policy/config

Transport

Security gate

Routing/orchestration

4 — Server layers (your blueprint)

Server layers (your blueprint)

Blueprint

This is a strong “enterprise-ready” breakdown because it separates: config → transport → guardrails → orchestration → capabilities.

Less coupling

More governance

Layer / Component	Pattern	Responsibility	Practical notes
`MCPConfig`	Singleton	Central configuration; tool/resource definitions; security settings; database credentials	This is where you define the “surface area” (what exists) and the connectivity (DB/API endpoints).
`MCPTransportFactory`	Factory	Detects CLI vs HTTP; creates appropriate transport; returns `MCPTransportInterface`	Lets the same server run locally (stdio) or remotely (HTTP) with minimal changes.
`MCPTransportHandler`	Validation / Gateway	JSON-RPC validation; rate limiting; authentication; logging	Your “security gate”: validate inputs, protect endpoints, and provide auditability.
`MCPServer`	Orchestrator	Event loop; method routing; error handling; initialization tracking	Control center: receives requests, routes to tools/resources/prompts, and normalizes errors.
`MCPTools`	Tool Catalog	Hardcoded tool list; switch-based routing; delegates to agent_tools.php; MCP format wrapping	Recommendation: evolve from a hardcoded switch to a declarative registry as the catalog grows.
`MCPResources`	Data Access	Hardcoded URI list; direct SQL queries; read-only access; filtering & pagination	Ideal for a safe “context surface”: curated resources, pagination, strict limits, and access control.
`MCPPrompts`	Templates	Loads in constructor; template substitution; argument validation; in-memory storage	Great for standardizing tasks (triage, QA, PRDs). Add versioning and template tests over time.

Simple analogy: MCPTools are “buttons” (actions), MCPResources are “documents” (context), and MCPPrompts are “procedures” (how to do the work). The other layers make this safe, scalable, and auditable.

Rate this article

—

Share your feedback

Optional: send a comment about this article.