Gateway Patterns — Routing, Rate Limiting, Observability
A single MCP server running on localhost is a tool. An enterprise AI infrastructure is a fleet of MCP servers, some running in containers on internal Kubernetes clusters, some running as managed services on cloud providers, some hosted by third-party vendors whose availability and behavior you do not control. Connecting an LLM directly to this fleet — which is what the reference architecture implicitly assumes — means that every failure mode of every server is directly visible to the model, that rate limiting is the responsibility of each individual server, and that there is no single point to enforce cross-cutting policies like circuit breaking, request logging, or token budget management.
The gateway pattern solves this. An MCP gateway sits between the LLM and the fleet of backend servers. It handles authentication at the perimeter, enforces rate limiting before requests reach individual servers, routes requests to the appropriate backend based on the tool namespace, and provides a single point of observability for every tool invocation in the system. The LLM sees a single MCP interface. The gateway handles the complexity of the fleet behind it.
// mcp-gateway.ts
// Production MCP gateway: routing, rate limiting, circuit breaking, observability
import Fastify from 'fastify'
import { createClient } from 'redis'
const app = Fastify({ logger: true })
const redis = createClient({ url: process.env.REDIS_URL })
await redis.connect()
// --- Server registry ---
interface McpServer {
name: string
url: string
tools: string[] // tool names this server owns
healthUrl: string
circuitOpen: boolean
failureCount: number
lastFailureAt: number | null
}
const SERVER_REGISTRY: McpServer[] = JSON.parse(process.env.MCP_SERVER_REGISTRY ?? '[]')
function routeToServer(toolName: string): McpServer | null {
return SERVER_REGISTRY.find(s => s.tools.includes(toolName) && !s.circuitOpen) ?? null
}
// --- Rate limiting (token bucket per client) ---
async function checkRateLimit(clientId: string, toolName: string): Promise<boolean> {
const key = `rl:${clientId}:${toolName}`
const limit = parseInt(process.env.RATE_LIMIT_PER_MINUTE ?? '60')
const current = await redis.incr(key)
if (current === 1) await redis.expire(key, 60)
return current <= limit
}
// --- Circuit breaker ---
const CIRCUIT_THRESHOLD = 5
const CIRCUIT_RESET_MS = 30_000
function recordFailure(server: McpServer): void {
server.failureCount++
server.lastFailureAt = Date.now()
if (server.failureCount >= CIRCUIT_THRESHOLD) {
server.circuitOpen = true
app.log.warn({ server: server.name }, 'Circuit breaker opened')
setTimeout(() => {
server.circuitOpen = false
server.failureCount = 0
app.log.info({ server: server.name }, 'Circuit breaker reset')
}, CIRCUIT_RESET_MS)
}
}
// --- Proxy tool call to backend MCP server ---
app.post('/tools/:toolName', async (req, reply) => {
const { toolName } = req.params as { toolName: string }
const clientId = req.headers['x-mcp-client-id'] as string ?? 'anonymous'
if (!await checkRateLimit(clientId, toolName)) {
return reply.status(429).send({ error: 'Rate limit exceeded' })
}
const server = routeToServer(toolName)
if (!server) {
return reply.status(503).send({ error: `No available server for tool: ${toolName}` })
}
const start = Date.now()
try {
const upstream = await fetch(`${server.url}/tools/${toolName}`, {
method: 'POST',
headers: { 'content-type': 'application/json', 'x-client-id': clientId },
body: JSON.stringify(req.body),
signal: AbortSignal.timeout(parseInt(process.env.TOOL_TIMEOUT_MS ?? '30000')),
})
const result = await upstream.json()
const latencyMs = Date.now() - start
// Emit metric
await redis.hIncrBy('mcp:metrics', `${toolName}:calls`, 1)
await redis.hIncrBy('mcp:metrics', `${toolName}:latency_total`, latencyMs)
return reply.send(result)
} catch (err) {
recordFailure(server)
app.log.error({ toolName, server: server.name, err }, 'Tool call failed')
return reply.status(502).send({ error: 'Upstream server error' })
}
})
// --- Health endpoint ---
app.get('/health', async () => ({
status: 'ok',
servers: SERVER_REGISTRY.map(s => ({
name: s.name,
circuitOpen: s.circuitOpen,
failureCount: s.failureCount,
})),
}))
await app.listen({ port: parseInt(process.env.PORT ?? '8080'), host: '0.0.0.0' })
The gateway pattern comes with an important tradeoff: it introduces a synchronous hop for every tool invocation, which adds latency and creates a single point of failure if the gateway itself goes down. Both of these are manageable. The latency overhead of a local gateway is typically 1–3ms on internal networking, which is negligible relative to the latency of tool execution and LLM inference. The single-point-of-failure concern is addressed by running the gateway as a horizontally scaled stateless service with health checks at the load balancer. The circuit breaker logic in the example above prevents a single failing backend from degrading the whole fleet.
For teams that already run a service mesh like Istio or Linkerd, much of this logic can be delegated to the mesh layer. Rate limiting, circuit breaking, and mTLS between services are native capabilities of modern service meshes. The MCP gateway in that context becomes a thin routing and authentication translation layer rather than a full-featured proxy. The pattern scales from a small deployment with a few servers to a large enterprise fleet with dozens of specialized MCP servers serving different capability domains.
The Stateless Transport Migration
The default MCP transport is stdio: the client spawns the server as a child process and communicates over standard input and output. This is an extraordinarily developer-friendly transport for local development. It requires no network configuration, no port management, no TLS certificates. It also has a fundamental property that makes it unusable at enterprise scale: it is stateful, single-client, and process-bound. One server process serves one client. There is no connection pooling. There is no horizontal scaling. There is no way to run the server as a shared service accessible by multiple LLM instances simultaneously.
The MCP 2026 roadmap’s planned stateless HTTP transport is the architectural fix for this. Instead of a persistent stdio connection, each tool invocation is an independent HTTP request. The server is stateless between requests, which means it can be deployed as a standard web service behind a load balancer, scaled horizontally, and managed with the same operational tooling as any other HTTP service in the infrastructure. Until the official stateless transport specification lands, the practical migration path is to wrap the MCP server in an HTTP layer that preserves the protocol semantics while enabling stateless deployment.
// mcp-http-transport.ts
// Stateless HTTP wrapper for MCP server — enables horizontal scaling before official support
import { Server } from '@modelcontextprotocol/sdk/server/index.js'
import { InMemoryTransport } from '@modelcontextprotocol/sdk/inMemory.js'
import Fastify from 'fastify'
// Build your MCP server (tools registered here)
function buildMcpServer(): Server {
const server = new Server(
{ name: 'stateless-mcp', version: '1.0.0' },
{ capabilities: { tools: {} } }
)
// ... register handlers ...
return server
}
const app = Fastify()
// Each POST is an independent, stateless MCP request
app.post('/mcp', async (req, reply) => {
// Create a fresh server + transport pair per request
const server = buildMcpServer()
const [clientTransport, serverTransport] = InMemoryTransport.createLinkedPair()
await server.connect(serverTransport)
// Send the incoming MCP message and collect the response
const messages: unknown[] = []
clientTransport.onmessage = (msg) => messages.push(msg)
await clientTransport.send(req.body as Parameters<typeof clientTransport.send>[0])
// Allow event loop to process
await new Promise(resolve => setImmediate(resolve))
await server.close()
return reply.send(messages[0] ?? { error: 'No response' })
})
app.get('/health', async () => ({ status: 'ok', transport: 'stateless-http' }))
await app.listen({ port: parseInt(process.env.PORT ?? '3000'), host: '0.0.0.0' })
The per-request server instantiation in the example above has a real cost: server initialization overhead on every call. For servers with lightweight initialization — no database connections, no large in-memory state — this is typically acceptable, adding 1–5ms per request. For servers that need persistent connections to databases or external services, the production pattern is a connection pool managed outside the server instance, with the server receiving a reference to a pooled connection on construction rather than opening its own. This mirrors the standard stateless web service pattern: external state in managed infrastructure, stateless application layer that can be freely instantiated and destroyed.
The Tasks primitive coming in the 2026 MCP roadmap addresses a related limitation: long-running tool invocations that exceed HTTP timeout thresholds. Until that lands, the interim pattern for async tools is a deferred response model: the initial tool invocation returns a task ID immediately, and the client polls a status endpoint until the task completes. This is the same pattern used by background job systems, and it integrates naturally with the HTTP transport layer described above. The Cloudflare agentic commerce guide has a worked example of this pattern in the context of payment-gated tool access.
Security Hardening
The MCP threat model is substantially different from a conventional API threat model. A conventional API serves human users whose requests are bounded by UI affordances and whose actions have natural latency. An MCP server serves AI agents whose requests can be generated at machine speed, whose action boundaries are defined by the tool schema rather than a user interface, and whose behavior under adversarial prompting may differ materially from their behavior under normal conditions. Security hardening for MCP must account for all three of these differences.
The first hardening concern is prompt injection via tool outputs. When an MCP tool returns content — text from a database, a document from a file system, an API response — that content is fed back into the LLM’s context. Malicious content embedded in tool outputs can attempt to override the LLM’s instructions, exfiltrate context data, or cause the agent to invoke additional tools it should not invoke. This is the LLM equivalent of SQL injection, and it is substantially harder to defend against because the “query” language is natural text rather than a structured format with a well-understood injection grammar.
The second hardening concern is tool scope creep. An MCP server that was originally deployed with read-only database access gets a write tool added six months later. The authentication layer that was designed for read access is not re-evaluated for write access. The rate limits that were sized for read throughput are not re-sized for write throughput. Tool scope expansions are the most common source of privilege escalation vulnerabilities in production MCP deployments, and they happen not through malicious intent but through normal feature development moving faster than security review.
#!/usr/bin/env bash
# mcp-security-audit.sh
# Run before every deployment to catch common MCP security misconfigurations
set -euo pipefail
PASS=0; FAIL=0
check() {
local label=$1; local cmd=$2; local expect=$3
local result
result=$(eval "$cmd" 2>&1 || true)
if echo "$result" | grep -q "$expect"; then
echo " PASS $label"
((PASS++))
else
echo " FAIL $label (got: $result)"
((FAIL++))
fi
}
echo "=== MCP Security Audit ==="
# 1. No hardcoded secrets in server source
check "No hardcoded API keys" "grep -rn 'api_keys*=s*["'''][^"''']+["''']' src/ || echo 'CLEAN'" "CLEAN"
# 2. JWT audience validation present
check "JWT audience validation" "grep -r 'aud' src/mcp-server*.ts" "aud"
# 3. Tool permission map covers all registered tools
check "All tools have permission entries" "node -e "
const s = require('./dist/mcp-server-production.js');
const tools = Object.keys(s.TOOL_PERMISSIONS);
console.log(tools.length > 0 ? 'OK' : 'MISSING');
"" "OK"
# 4. Rate limiting configured
check "Rate limit env set" "[ -n '${RATE_LIMIT_PER_MINUTE:-}' ] && echo 'SET' || echo 'MISSING'" "SET"
# 5. TLS enforced on transport (not localhost)
check "MCP_SERVER_URL uses HTTPS" "echo '${MCP_SERVER_URL:-http://}' | grep -c 'https'" "1"
# 6. Timeout set for upstream calls
check "TOOL_TIMEOUT_MS configured" "[ -n '${TOOL_TIMEOUT_MS:-}' ] && echo 'SET' || echo 'MISSING'" "SET"
# 7. No stdio transport in production config
check "No stdio transport in production" "grep -r 'StdioServerTransport' src/ | grep -v test | wc -l | tr -d ' '" "0"
echo ""
echo "Results: $PASS passed, $FAIL failed"
[ $FAIL -eq 0 ] || exit 1
The security audit script above should run as part of every CI pipeline that deploys an MCP server. The seven checks it performs cover the most common misconfigurations observed in production incident post-mortems: hardcoded credentials, missing audience validation, incomplete permission maps, absent rate limiting, plaintext transport, unconfigured timeouts, and stdio transport in production. None of these require exotic tooling to detect. They all require making the check part of the deployment pipeline rather than a manual code review step that happens when someone remembers to do it.
The third hardening concern — and the one that has caused the most significant production incidents in the teams I have spoken with through 2025 and into 2026 — is supply chain trust for third-party MCP servers. The 9,400-server public registry is not a curated marketplace. It is a collection of GitHub repositories that have published a manifest. Using a third-party MCP server in production means running arbitrary code in a process that has access to everything your MCP gateway credentials authorize. The trust model for third-party MCP servers should be identical to the trust model for third-party npm packages: assume malice, read the source, pin versions, sandbox execution. The AI code security guide has the complete dependency audit framework that applies directly to MCP server supply chain validation.
Monitoring and Observability for MCP Servers
An MCP server that fails silently is more dangerous than one that fails noisily. When an API call fails, the HTTP response code communicates the failure immediately. When an MCP tool invocation fails, the failure may appear to the LLM as a tool that returned unexpected output rather than an error — leading the agent to retry, to take compensating actions, or to proceed with incorrect assumptions about system state. The observability layer for MCP must be designed with this failure mode explicitly in mind.
The three observability primitives that cover the core MCP failure modes are structured request logging, distributed tracing with tool-call spans, and health checks that exercise the actual tool execution path rather than just the process liveness. OpenTelemetry is the right foundation for all three, and its SDK integrates naturally with the Fastify-based gateway pattern described earlier.
// mcp-observability.ts
// OpenTelemetry instrumentation for MCP gateway — traces, metrics, structured logs
import { NodeSDK } from '@opentelemetry/sdk-node'
import { OTLPTraceExporter } from '@opentelemetry/exporter-trace-otlp-http'
import { OTLPMetricExporter } from '@opentelemetry/exporter-metrics-otlp-http'
import { PeriodicExportingMetricReader } from '@opentelemetry/sdk-metrics'
import { trace, metrics, SpanStatusCode } from '@opentelemetry/api'
// Initialize SDK once at startup
const sdk = new NodeSDK({
traceExporter: new OTLPTraceExporter({ url: process.env.OTEL_EXPORTER_URL }),
metricReader: new PeriodicExportingMetricReader({
exporter: new OTLPMetricExporter({ url: process.env.OTEL_EXPORTER_URL }),
exportIntervalMillis: 15_000,
}),
serviceName: 'mcp-gateway',
})
sdk.start()
const tracer = trace.getTracer('mcp-gateway')
const meter = metrics.getMeter('mcp-gateway')
// Metrics
const toolCallCounter = meter.createCounter('mcp.tool.calls.total')
const toolLatencyHistogram = meter.createHistogram('mcp.tool.latency_ms', { unit: 'ms' })
const toolErrorCounter = meter.createCounter('mcp.tool.errors.total')
// Wrap every tool invocation with a trace span + metrics
export async function instrumentedToolCall(
toolName: string,
clientId: string,
fn: () => Promise<unknown>
): Promise<unknown> {
return tracer.startActiveSpan(`mcp.tool.${toolName}`, async (span) => {
span.setAttributes({
'mcp.tool.name': toolName,
'mcp.client.id': clientId,
})
const start = Date.now()
toolCallCounter.add(1, { tool: toolName, client: clientId })
try {
const result = await fn()
const latency = Date.now() - start
toolLatencyHistogram.record(latency, { tool: toolName })
span.setStatus({ code: SpanStatusCode.OK })
return result
} catch (err) {
const latency = Date.now() - start
toolLatencyHistogram.record(latency, { tool: toolName })
toolErrorCounter.add(1, { tool: toolName, error: (err as Error).name })
span.recordException(err as Error)
span.setStatus({ code: SpanStatusCode.ERROR, message: (err as Error).message })
throw err
} finally {
span.end()
}
})
}
// Health check that exercises tool execution path
export async function deepHealthCheck(tools: string[]): Promise<{
status: 'healthy' | 'degraded' | 'unhealthy'
checks: Record<string, { ok: boolean; latencyMs: number }>
}> {
const checks: Record<string, { ok: boolean; latencyMs: number }> = {}
for (const tool of tools) {
const start = Date.now()
try {
// Invoke a no-op probe variant of the tool
await fetch(`${process.env.MCP_GATEWAY_URL}/tools/${tool}/probe`, { method: 'POST' })
checks[tool] = { ok: true, latencyMs: Date.now() - start }
} catch {
checks[tool] = { ok: false, latencyMs: Date.now() - start }
}
}
const allOk = Object.values(checks).every(c => c.ok)
const anyOk = Object.values(checks).some(c => c.ok)
return { status: allOk ? 'healthy' : anyOk ? 'degraded' : 'unhealthy', checks }
}
The observability pattern above does something beyond basic request logging: it creates a span for each tool invocation that carries the tool name and client identity. When an agent makes five tool calls in sequence and the third one fails, the distributed trace shows exactly which tool failed, how long it took, and what error it returned — with correlation through the entire agent session. This is the difference between “something failed in the AI workflow” and “the execute_query tool returned a timeout on the third invocation of session abc123, at 14:32:07 UTC, taking 30,002ms before the abort signal fired.” The second description is debuggable. The first is a source of engineer frustration and mean-time-to-resolution that looks like a P95 latency number in the weekly incident review.
The deep health check pattern in the example — exercising actual tool execution paths rather than just checking process liveness — catches the failure mode that process-level health checks miss: a server that is running and responding to HTTP requests but has lost its database connection, exhausted its token budget, or entered a degraded state that only manifests during actual tool invocation. Shallow health checks are the reason teams discover production failures from user reports rather than monitoring alerts. Deep health checks are why you can set up a PagerDuty integration that fires before the first user notices something is wrong.
Configuration Portability
Configuration portability is one of the six identified enterprise gaps in the MCP ecosystem, and it is perhaps the least discussed because it sounds like an operational convenience problem rather than an architectural one. It is not. In an enterprise environment where multiple teams run MCP servers, where the same server might be deployed to development, staging, and production with different backend endpoints and credential sets, and where incident response requires rapidly reconfiguring routing without redeploying server code, the absence of a standardized configuration format creates operational drag that compounds every other problem.
The current state of MCP configuration is that each server defines its own configuration format, stored wherever the developer chose to put it, documented (if at all) in a README that may not reflect the current version of the code. When an incident requires understanding what a server is connected to, how its permissions are configured, and what its current operational parameters are, the answer is typically “read the source code and the environment variable documentation.” The incident response time this creates is measurable and preventable.
# mcp-server-config.yaml
# Portable MCP server configuration template — environment-independent
apiVersion: mcp/v1
kind: ServerConfig
metadata:
name: production-data-server
version: 1.0.0
environment: production
owner: platform-team
contact: [email protected]
transport:
type: http # stdio | http | sse
port: 3000
tls: true
timeout_ms: 30000
authentication:
type: jwt
issuer: https://auth.yourcompany.com
audience: mcp-server-production
jwks_uri: https://auth.yourcompany.com/.well-known/jwks.json
required_claims: [sub, roles, aud]
tools:
read_database:
description: "Read records from the application database"
required_roles: [tools:read]
rate_limit_per_minute: 120
timeout_ms: 10000
backend:
type: postgres
connection_env: DATABASE_URL
write_database:
description: "Write records to the application database"
required_roles: [tools:write]
rate_limit_per_minute: 30
timeout_ms: 15000
backend:
type: postgres
connection_env: DATABASE_URL
observability:
otel_endpoint_env: OTEL_EXPORTER_URL
trace_sampling_rate: 0.1 # 10% sampling in production
log_level: info
health_check_path: /health
deep_health_check_path: /health/deep
deep_health_check_tools: [read_database]
circuit_breaker:
failure_threshold: 5
reset_interval_ms: 30000
half_open_max_requests: 3
The configuration template above is not an official MCP standard — that specification does not yet exist. It is a practical convention that, once adopted across a team, provides the operational documentation that incident response requires. When someone is paged at 2am because an agent workflow is failing, the first question is “what is this server supposed to do and what is it connected to?” A structured configuration file answers both questions without requiring code archaeology. The YAML structure maps directly to the implementation primitives described throughout this guide: transport configuration, authentication parameters, per-tool rate limits and permissions, observability settings, and circuit breaker thresholds.
The portability benefit emerges when you templaterize this configuration: a single base template with environment-specific overrides, managed through Helm values or Kubernetes ConfigMaps or a dedicated configuration service. A developer adding a new tool modifies one YAML file. The security review confirms that the required_roles and rate_limit are appropriate for the tool’s access level. The configuration is committed to version control, reviewed like code, and deployed alongside the server. The operational documentation is the configuration itself, not a separate document that will inevitably drift from the implementation. Teams doing cloud cost analysis can reference the managed agents developer guide for how this configuration pattern extends to cloud-managed MCP server deployments on AWS Bedrock and similar platforms.
The Reference Architecture
Everything described in this guide exists in service of a single goal: running MCP servers in production at enterprise scale with the operational properties — availability, security, debuggability, and maintainability — that enterprise workloads require. The reference architecture ties these patterns together into a complete system.
The architecture has five layers. At the perimeter, an identity provider issues short-lived JWTs to authenticated clients — LLM agents, human operators, automated pipelines — with explicit audience claims and role assignments. The JWTs carry the client identity into every subsequent request without the server needing to know anything about how the client authenticated. This layer is your existing identity provider; it requires no new infrastructure.
The second layer is the MCP gateway, running as a horizontally scaled stateless service behind a load balancer. The gateway validates the JWT on every incoming request, applies per-client and per-tool rate limiting through a shared Redis state store, routes the request to the appropriate backend server based on the tool namespace, and records the invocation as a distributed trace span. The gateway implements circuit breaking for backend servers, preventing a single failing server from propagating errors into the entire fleet. The gateway is the single point of cross-cutting policy enforcement.
The third layer is the fleet of backend MCP servers, each running as a stateless HTTP service (migrated from stdio using the transport wrapper pattern), each with its own deep health check endpoint, each configured through the portable YAML configuration format. Backend servers know nothing about authentication — that concern belongs to the gateway. They know nothing about rate limiting or circuit breaking. They implement tool logic and return results. This separation of concerns is what makes the fleet maintainable as it grows.
The fourth layer is the observability infrastructure: an OpenTelemetry collector receiving traces from both the gateway and the backend servers, feeding into whatever backend your organization uses for trace storage and analysis — Jaeger, Honeycomb, Datadog, AWS X-Ray. Every tool invocation produces a span. Every span carries the client identity, the tool name, the latency, and any error information. Aggregate metrics from the gateway — call counts, error rates, latency percentiles per tool — feed into dashboards and alerting rules. When something fails, the observability layer provides the precise sequence of events that led to the failure.
The fifth layer is the CI/CD and security pipeline: the audit script runs on every deployment, verifying that no hardcoded credentials have appeared, that all tools have permission entries, that the transport is correctly configured for the target environment. Configuration changes go through version control and code review. Server version pinning in the gateway registry prevents a third-party server update from silently changing behavior in production. The deployment pipeline includes a canary phase where a small percentage of traffic routes to the new server version before full rollout, with automatic rollback triggered by the circuit breaker if the error rate exceeds the threshold.
This is not a complex architecture. Every component is a standard operational pattern applied to the specific constraints of the MCP protocol. The authentication is standard JWT validation. The gateway is a standard HTTP proxy with a tool-aware routing table. The observability is standard OpenTelemetry instrumentation. The configuration management is standard YAML templating. What makes it an MCP architecture is the specific way these components are assembled to address the six enterprise gaps — auth fragmentation, discovery, permission scope, transport, versioning, observability — that the reference implementations leave unaddressed.
The AWS MCP Server reaching general availability in May 2026 is a significant milestone because it provides a managed deployment target that handles the infrastructure layer — scaling, availability, TLS termination — while still requiring the application-layer patterns described here. Managed infrastructure does not provide managed authentication or managed observability in the application-semantic sense. It does not know which of your tools requires write permissions or which client should be rate-limited. Those concerns remain yours to implement, and the patterns in this guide remain valid regardless of whether the backend is running on your own Kubernetes cluster, on AWS, or on any other managed MCP server platform that emerges from the 2026 enterprise tooling wave.
The 76% of enterprise AI providers exploring MCP integration are going to encounter the production gap described at the opening of this guide. Most of them will encounter it after they have already shipped a demo that worked, invested engineering time in building server implementations, and committed to MCP as their AI tooling integration standard. The gap is not a reason to avoid MCP. The protocol is the right foundation, and the ecosystem momentum behind it — 100 million downloads per month, 9,400 servers, Linux Foundation governance, AWS GA — is real. The gap is a reason to build the operational architecture deliberately rather than inheriting the reference implementation’s assumptions. See the Salesforce Agentforce guide for how this architecture integrates with enterprise agentic platforms that treat MCP as a first-class integration primitive.
[1] InfoQ Research, “Enterprise MCP Adoption Survey Q1 2026,” infoq.com. 76% of surveyed enterprise AI providers actively exploring or implementing MCP integration as of Q1 2026.
[2] Linux Foundation press release, “Anthropic Donates Model Context Protocol to Linux Foundation AAIF,” March 2026, linuxfoundation.org.
[3] Anthropic Developer Blog, “MCP 2026 Roadmap: Stateless HTTP Transport, Tasks Primitive, Enterprise Auth,” anthropic.com.
[4] AWS News Blog, “AWS MCP Server Now Generally Available,” May 2026, aws.amazon.com.
Comments · 0
Beta: comments are stored locally on your device and not visible to other readers.
No comments yet. Be the first to share your thoughts.