Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions src/pages/learn/mcp-tunnels-vs-vpn.astro
Original file line number Diff line number Diff line change
Expand Up @@ -33,6 +33,8 @@ const bodyContent = `

<p>The <a href="https://modelcontextprotocol.io">Model Context Protocol (MCP)</a> defines a client-server protocol for AI agents to access tools and data. An MCP client (the agent) connects to an MCP server (a process that wraps a tool or data source) and invokes tools through a JSON-RPC interface. The transport between client and server can be stdio (same process) or HTTP+SSE (network).</p>

<p>For a closer look at how webhooks and SSE streaming deliver results for long-running research jobs — and where the reachable-endpoint requirement gets fragile — see <a href="/learn/webhooks-sse-streaming-long-running-jobs">how webhooks and SSE streaming work for long-running jobs</a>.</p>

<p>When people refer to "MCP tunnels," they are usually talking about the transport layer between an MCP client and server over a network — a persistent or long-lived HTTP connection (often using Server-Sent Events) through which tool calls and results flow. Some implementations wrap this in WebSocket connections for bidirectional streaming. The key property is that MCP tunnels connect an agent to its tools — databases, APIs, file systems, search engines — not to other agents.</p>

<p>MCP tunnels give you:</p>
Expand Down
2 changes: 2 additions & 0 deletions src/pages/learn/nats-vs-grpc-agent-messaging.astro
Original file line number Diff line number Diff line change
Expand Up @@ -39,6 +39,8 @@ const bodyContent = `<p>You are building agents that need to talk to each other.

<p>gRPC organizes communication around service definitions in Protocol Buffers. You define a service with methods — some unary (one request, one response), some server-streaming (one request, stream of responses), some bidirectional.</p>

<p>Server-streaming is how gRPC handles long-running work: the client opens one call and receives a stream of responses. The same shape appears over plain HTTP as Server-Sent Events, with webhooks covering the completion case — see <a href="/learn/webhooks-sse-streaming-long-running-jobs">how webhooks and SSE streaming work for long-running research jobs</a> for how those patterns behave under parallel task fan-out.</p>

<p>The contract-first approach is a practical advantage for teams: the .proto file is a single source of truth for the API surface. Code generation produces client and server stubs in twelve-plus languages, so you cannot accidentally send the wrong type. For structured agent interactions — submit a task, get a result — gRPC is ergonomic.</p>

<p>The limit is that gRPC assumes you know who you are calling. Service discovery, load balancing, and failover are not part of the framework — they come from infrastructure (DNS SRV, Consul, Kubernetes Services). If you have 200 agents and any one of them can call any other, you need a way for them to discover each other's addresses and health status.</p>
Expand Down
Loading
Loading