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

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.

5 — 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.

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

Overview

Overview

How does it connect?

How does it connect?

Layer analogy

Layer analogy

Server layers (your blueprint)

Server layers (your blueprint)

Server layers (your blueprint)

Server layers (your blueprint)

Rate this article

Share your feedback