Loading…
Topic
167 posts about MCP. Every summary links to the original.
See the idea
An agentic ad stack wires governed customer signals to campaign execution through a shared tool interface and server-side guardrails. The diagram shows each layer, the direction of a tool call, and where control stays human.
A four-stage flow showing how a coding agent moves from a task to a reviewed change by grounding on verified skills, live system state, and code-first config before it acts.
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
Newest first
The post presents Fly.io’s approach to simplifying remote deployment of Model Context Protocol (MCP) servers, which otherwise require client-specific JSON configuration, local processes or HTTP hosting, and potentially cumbersome OAuth 2.1 setup. It uses the Slack MCP Server as a demonstration, converting its npx command into a fly mcp launch invocation with --claude, --server, and secret flags for the bot token and team ID. Running this requires flyctl v0.3.125 or later, and the command supports Fly.io options including auto-stop, file contents, flycast, regions, volumes, secrets, and VM sizes. Built-in configuration support covers Claude, Cursor, Neovim, VS Code, Windsurf, and Zed, with bearer-token authentication enabled by default on both server and client. The broader beta support includes multiple transports, Machines API deployment, separate Machines or containers, in-application deployment, and HTTP Authorization, WireGuard tunnels, flycast, or reverse proxies.
Fly.io’s flyctl MCP server lets LLMs such as Claude or Cursor use tools to inspect and modify application resources, demonstrated by creating a volume and adding support for all volume commands. The author describes asking Claude to identify unattached volumes and delete the oldest, while noting that flyctl’s mounted-volume safeguards provided an error if destruction was unsafe. Compared with writing against the Machines API, using flyctl directly, or navigating the dashboard, the conversational workflow surfaced an observation and turned it into an action with less manual effort. The post outlines a future in which an LLM proposes deployment plans, examines build errors and logs, and acts through MCP servers on Fly.io’s private network. Users can try the current open-source server with fly version upgrade to v0.3.117, configure an LLM, or run the MCP Inspector; apps, logs, machines, orgs, platform status, and volumes are roughed in.
Cursor is presented as the author’s primary AI coding companion, with inline suggestions, quick edits, and agentic features supporting coding, testing, design, and deployment from one editor. Connecting it to Heroku through the Model Context Protocol (MCP) enables an assistant to deploy apps, scale dynos, fetch logs, and update configuration without opening the Heroku dashboard or terminal. The article explains MCP’s host–client–server model and gives Cursor setup configurations for the Heroku MCP Server, LangChain MCPDoc, and Figma MCP Server, including required Heroku authorization and tool commands. It reports that this workflow reduced context-switching, saved minutes on tasks, reduced errors from recalling commands, and helped the author stay focused while building and deploying demos.
Kurt Mackey describes building a minimal MCP server for flyctl in 30 minutes, motivated by testing how an LLM could inspect deployed applications. MCP connects an LLM client to server-exported tools through JSON exchanges; this implementation uses stdio mode, a Go MCP library, and exposes only fly logs and fly status, producing roughly 90 lines of code. Existing JSON modes in flyctl commands made the tools easier to drive from automation. When pointed at unpkg through Claude, the server surfaced a globally distributed deployment, identified two critical machines, and connected repeated restarts and oom_killed events to Bun using about 3.7 GB of a machine’s 4 GB allocation. The post calls the result surprisingly useful while warning that local MCP servers give cloud-hosted Claude access to native programs and would be safer in isolation.
Fly.io reports that users driving the platform’s most recent growth are robots rather than people, prompting a reconsideration of developer experience (DX) as the primary product lens. The post describes how vibe-coding workflows use Fly Machines—Docker containers running as hardware-isolated virtual machines—to create, modify, stop, and rapidly restart environments without paying during stopped periods. These workflows favor incremental filesystem state, object storage, and controllable routing for MCP connections, including potentially long-lived SSE connections that should reach the same stateful instance. Fly.io also proposes exposing its API through MCP and using sealed, tokenized secrets so isolated machines can substitute real OAuth credentials only when needed. It concludes that a useful robot experience (RX) will require more than an MCP interface, while managed Postgres remains the company’s most important engineering priority and the platform is still primarily designed for humans.
Ramp built an open-source MCP server that exposes its developer API to LLMs through tools and a SQL interface, enabling natural-language access to business spend data. Using FastMCP in Python and Claude Desktop, the prototype could run analyses, generate visualizations, and issue cards on demand, but pagination struggled beyond a few hundred transactions because of miscalculations, context limits, input sizes, and token use. The team replaced bulk responses with an in-memory ETL that flattens API JSON into SQLite, then exposes load, transformation, and query tools; an OLAP-powered API was added for reporting workloads that caused timeouts. This let Claude analyze tens of thousands of spend events with aggregate and window functions while reducing token usage, although API latency, occasional reliability problems, tool-selection errors, and security risks remain; audit logs, OAuth scopes, and constrained tools provide mitigations, while write actions await a safety framework.
Effective agentic systems need not begin with complex frameworks: the post reports that successful implementations commonly use simple, composable patterns and recommends choosing the least complex solution that meets the task's needs. It distinguishes workflows, which follow predefined code paths, from agents, where LLMs dynamically direct their processes and tool use. The proposed foundation is an augmented LLM with retrieval, tools, and memory, potentially integrated through the Model Context Protocol; larger designs include prompt chaining, routing, parallelization, and orchestrator-workers patterns. Frameworks can simplify implementation but may obscure prompts and responses, so direct API use and understanding underlying code are recommended. Tool definitions are treated as an interface requiring testing, clear examples, low formatting overhead, and mistake-resistant parameters; absolute filepaths eliminated observed errors in a coding agent.
The best engineering reads, once a week.
