json-rpc

4 posts

cloudflare

How Cloudflare detects MCP traffic and helps secure it (opens in new tab)

AI agents change the risk model for resource permissions because they make nondeterministic decisions and can repeat actions at machine speed. A mistaken judgment that a human might quickly catch can become thousands of harmful operations before anyone notices. Cloudflare’s new Cloudflare One capabilities aim to detect MCP traffic, identify its users and servers, and enforce approved routes through MCP Server Portals. ## Why AI Agents Require New Controls - Traditional permissions assumed users would apply judgment and act at a limited human pace. - AI agents can invoke tools repeatedly and indefinitely. - A single incorrect decision can rapidly propagate across databases, SaaS systems, or infrastructure. - MCP makes it easy to connect clients such as Claude Code, Codex, Cursor, OpenCode, and VS Code to approved or unapproved tools. - Direct MCP traffic can resemble ordinary HTTPS because MCP does not require a standard hostname or `/mcp` path. ## Anatomy of an MCP Tool Call An MCP request appears differently at three points: - **Client:** The agent decides to invoke a tool and supplies arguments. - **Network:** The request is transmitted as an HTTP transaction containing JSON-RPC. - **Server:** The server authenticates, validates, and dispatches the request to a tool handler. Useful protocol signals include: - Destination hostname and path - Authorization credentials - `MCP-Protocol-Version` - `Mcp-Method` - `Mcp-Name` - JSON-RPC request `id` - Tool arguments in `params` The tool name indicates the intended operation, while the arguments may contain sensitive data such as source code, customer information, search queries, or infrastructure-changing instructions. Responses can also contain sensitive results, making both request prevention and response inspection valuable. ## Controls Inside the MCP Client Client hooks can intervene after the model selects a tool but before the request is serialized. - Enforce server allowlists - Require confirmation for sensitive operations - Remove sensitive data from arguments - Support local `stdio` MCP servers that never generate network traffic The main limitation is operational: organizations must implement controls across every client employees use. Client telemetry also cannot provide a complete inventory unless the organization manages all relevant clients and devices. ## Controls at the Network Boundary A secure web gateway with TLS decryption can inspect remote MCP traffic independently of the client. - Associate requests with users and devices - Inspect destinations and MCP protocol headers - Detect direct connections outside approved MCP Portals - Block unauthorized traffic before it reaches the server - Use data loss prevention scanning to inspect JSON-RPC methods and arguments Network controls provide the broadest visibility into remote MCP usage, but they cannot see local `stdio` calls or traffic that bypasses managed network paths. ## Controls at the MCP Server The server has the deepest execution context because it knows the authenticated caller, parsed message, resolved tool, and validated arguments. Server-side middleware can: - Authorize users for specific tools - Apply rate limits - Inspect arguments - Log outcomes - Block requests before tool execution Cloudflare’s WriteGuard applies this approach to internal MCP servers by assigning tools risk tiers and enabled or disabled states. It can allow reads, attach attribution and audit events to approved writes, or block critical actions before their handlers run. Because enforcement occurs on the server, users cannot bypass it by changing clients or disabling local hooks. ## Layered MCP Security Each control point has a different strength: - **Client controls:** Earliest intervention and support for local MCP, but limited coverage. - **Network controls:** Broadest visibility into remote traffic and unmanaged MCP connections. - **Server controls:** Richest context and final prevention point before execution. A layered strategy can protect sensitive data before it leaves a device, identify shadow MCP usage, require trusted Portal-based access, and prevent unauthorized tools from executing.

cloudflare

The next generation of MCP (opens in new tab)

MCP’s latest specification makes the protocol fully stateless, removing the session management and persistent connections that complicated remote deployments. Requests now carry the information they need, enabling MCP servers to run on simpler request-scoped infrastructure such as serverless Workers. The update also redesigns elicitation, improves HTTP observability, and strengthens authorization practices. ## MCP Becomes Stateless - Earlier MCP implementations required an `initialize`/`initialized` handshake and an `Mcp-Session-Id` for subsequent requests. - Stateful sessions created operational challenges: - Sticky-session routing - Open-stream management - Session migration during deployments - Reconnection problems when instances disappeared - The new protocol removes: - The mandatory handshake - `Mcp-Session-Id` - Protocol sessions from the core request path - Each request includes its protocol version, client identity, and capabilities. - `server/discover` is available for optional server inspection. - MCP servers can now execute a request and return its result without storing protocol state. - Cloudflare’s `McpAgent` is no longer required for MCP itself; developers can use `createMcpHandler` and deploy on Workers. - Durable Objects remain useful when the application—not MCP—requires state, persistence, or real-time coordination. ## Elicitation Uses Multi Round-Trip Requests - Elicitation allows servers to request additional information or approval, such as confirming a deployment or refund. - Previously, `elicitation/create` depended on an open stream, adding timeout, scaling, and infrastructure complexity. - The new Multi Round-Trip Request model works as follows: - The server returns an `input_required` result. - The client gathers the user’s response. - The client retries the operation with the requested input. - This is a breaking change from the previous approach but removes the need to preserve a transport session. ## HTTP Infrastructure Can Inspect MCP Requests - Streamable HTTP requests now include `Mcp-Method` and `Mcp-Name` headers. - Gateways, rate limiters, and web application firewalls can identify operations such as `tools/call` without parsing JSON-RPC bodies. - Operators can apply method-specific policies and collect tool-level metrics using standard HTTP infrastructure. - Results from `tools/list`, `prompts/list`, `resources/list`, and `resources/read` can include: - `ttlMs` hints - `cacheScope` hints - Deterministically ordered tool catalogs help clients reuse results and maintain stable prompt caches. ## Authorization Continues to Evolve - The specification prioritizes authorization approaches in this order: - Pre-registered clients when an established relationship exists - Client ID Metadata Documents (CIMD) for dynamic registration - Dynamic Client Registration (DCR) as a fallback - DCR is deprecated for new implementations, although the provided text ends before describing the full authorization changes. The new MCP specification significantly reduces deployment complexity by making the protocol request-oriented rather than session-oriented. Developers should migrate from `McpAgent` to `createMcpHandler` where application state is unnecessary, adopt MRTR for elicitation, and update HTTP and authorization integrations to use the new headers and registration guidance.

github

Building AI-powered GitHub issue triage with the Copilot SDK (opens in new tab)

The post demonstrates how to build IssueCrush, an AI-powered GitHub issue triage app using the GitHub Copilot SDK. The app presents issues as swipeable cards and uses Copilot to generate concise summaries and recommended actions. Because the SDK depends on Node.js and the Copilot CLI, the integration runs on a server rather than directly inside the React Native client. ## IssueCrush: Faster Issue Triage - IssueCrush displays GitHub issues as swipeable cards: - Swipe left to close an issue. - Swipe right to keep it. - Use “Get AI Summary” to receive actionable context. - Copilot summarizes lengthy issue descriptions and suggests actions such as: - Investigate the problem. - Implement the request. - Assign it to a relevant team. - Close it as a duplicate. - The goal is to reduce the cognitive load of reviewing many issues across active repositories. ## Server-Side Architecture - React Native cannot directly use the Node.js-based Copilot SDK. - The SDK launches a local Copilot CLI process and communicates with it through JSON-RPC. - The recommended architecture is: - React Native or web client communicates with a Node.js server over HTTPS. - The server runs the Copilot SDK and manages the Copilot CLI. - Clients separately use GitHub OAuth and the GitHub REST API for issue data. - Server-side integration provides: - A shared SDK instance for multiple clients. - Secure storage of Copilot credentials and API tokens. - Graceful fallback summaries when AI services are unavailable. - Centralized logging for latency, failures, prompts, and responses. ## Required Setup - Install the Copilot CLI on the server and ensure it is on the system `PATH`. - Use either: - A GitHub Copilot subscription, or - A BYOK configuration with personal API keys. - Authenticate the CLI with `copilot auth` or the `COPILOT_GITHUB_TOKEN` environment variable. ## Copilot SDK Lifecycle The SDK uses a session-based workflow: - Import `CopilotClient` and `approveAll`. - Create and start a `CopilotClient`, which launches the CLI. - Create a session with a selected model such as `gpt-4.1`. - Send a prompt using `session.sendAndWait()`. - Read the response from `response.data.content`. - Disconnect the session and stop the client. The required lifecycle is: `start() → createSession() → sendAndWait() → disconnect() → stop()` Sessions should always be cleaned up in a `finally` block. Missing `disconnect()` calls can leak resources and cause memory issues, while suppressed cleanup errors prevent them from hiding the original failure. ## Prompt Design for Triage - The prompt provides structured issue information instead of only passing raw text. - Context includes: - Title and issue number. - Repository name. - State and labels. - Creation date. - Author. - Full issue body. - The model is instructed to produce a concise two- or three-sentence summary that: - Explains the issue. - Identifies the key problem or request. - Recommends a practical next step. - The response should be clear, actionable, and free of Markdown formatting. A server-side Copilot integration offers a practical way to add AI-assisted triage while keeping credentials secure, maintaining fallback behavior, and preserving reliable resource management.

microsoft

How we built the Microsoft Learn MCP Server (opens in new tab)

Microsoft Learn MCP Server gives AI agents direct, standardized access to current Microsoft documentation through the Model Context Protocol (MCP). Rather than requiring custom APIs, scraping, or embeddings, agents can dynamically discover and use tools for searching documentation, fetching full articles, and finding code samples. Microsoft’s experience shows that successful MCP systems depend not only on retrieval quality, but also on agent-oriented tool design, operational resilience, clear descriptions, and defensive compatibility practices. ## Purpose of Learn MCP Server - Provides trusted, up-to-date Microsoft Learn content to GitHub Copilot and other AI agents. - Uses Streamable HTTP Transport so MCP-compatible clients can connect to a remote server. - Supports three tools: - `microsoft_docs_search` for titles, relevant content sections, and source URLs. - `microsoft_docs_fetch` for retrieving complete article content. - `microsoft_code_sample_search` for locating language-specific code examples. - Grounds agent responses in official Microsoft documentation rather than relying solely on model memory. ## Why MCP Instead of a Traditional API - Conventional APIs require each client to implement: - Authentication and request formatting. - Documentation and integration logic. - Error handling and compatibility maintenance. - MCP allows clients to discover available tools and schemas at runtime. - The same server can support many agents without custom integrations. - Runtime discovery helps clients adapt to evolving tool contracts and reduces hardcoded assumptions. ## Architecture - The remote MCP server sits in front of the Microsoft Learn knowledge service. - It uses the official C# MCP SDK and runs on Azure App Service. - Clients communicate through Streamable HTTP Transport. - The server uses the same content vector store as Ask Learn, providing shared: - Freshness guarantees. - Relevance ranking. - Index coverage. - Ask Learn delivers retrieval directly to users, while Learn MCP Server exposes that capability through a protocol usable by external agents. ## Designing Tools Around Agent Workflows - Internal retrieval APIs expose many low-level options, such as `topK`, index selection, thresholds, filters, and search modes. - Learn MCP Server hides that complexity behind intuitive search-and-fetch operations. - Tool contracts should reflect how agents work rather than mirror backend APIs. - Keeping retrieval details internal prevents implementation choices from leaking into the agent-facing interface. ## Operating a Remote MCP Service - A public MCP server has distributed-systems concerns despite using JSON-RPC: - Cross-region deployment. - Dynamic scaling. - CORS. - Session affinity. - Statelessness. - Data protection. - Operational design and SDK collaboration are as important as implementing the tools themselves. ## Tool Descriptions Shape Agent Behavior - Tool and parameter descriptions act as instructions for language models. - Small wording changes can significantly affect whether agents select a tool and how successfully they use it. - Microsoft created automated evaluation tooling to test descriptions against observed agent behavior and success metrics. - Updated descriptions can be delivered when clients refresh their MCP sessions. ## Combining Search and Fetch - Search and fetch are more effective together than independently. - A typical workflow is: - Search for the most relevant Learn article or section. - Fetch the full Markdown page for additional context. - Use that content to produce a better-grounded answer with stronger citations. - Explicitly describing this follow-up pattern improved downstream results. ## Handling Hardcoded Clients - Some MCP clients treat discovered tools like fixed APIs and hardcode schemas. - Renaming the `question` parameter to `query` caused 2–5% of requests to fail. - Supporting both names during a deprecation period reduced disruption. - Public MCP services must evolve defensively, even though the protocol supports dynamic discovery. - Tools such as MCP Interviewer can help identify schema and behavioral problems before deployment. ## Using Data to Guide Improvements - Usage data showed that most requests involve: - Coding tasks. - Explanations. - Troubleshooting. - The team prioritized retrieval and description changes around these intents. - Documentation-level agent instructions also encourage use of Learn tools when Microsoft technologies are involved. Microsoft Learn MCP Server replaces the manual process of searching, opening, and copying documentation into a development environment. The practical recommendation is to connect compatible agents to the server so they can retrieve official Learn content directly, while MCP tool authors should design simple contracts, measure real agent behavior, and preserve compatibility as their services evolve.