{"slug": "from-rest-to-mcp-1-2-different-dimensions", "title": "From REST to MCP (1/2): Different Dimensions", "summary": "An engineer explains why directly wrapping REST APIs as MCP tools is a bad default, highlighting key differences in runtime environments. REST encodes control in application logic, while MCP moves control to AI agents, affecting how tools are selected, arguments constructed, and errors handled. The article compares dimensions such as control flow, context, granularity, error handling, and statefulness between REST and MCP.", "body_md": "An MCP server can look like another API layer: expose existing REST endpoints as tools and call it a day.\n\nBoth receive input, execute backend logic, and return a result. But they operate under different assumptions. This two-part series explains why directly wrapping REST APIs is a bad default. This first article covers the differences in their runtime environments. The second will discuss how those differences should affect MCP design (you already know how to design a [good REST API](https://learn.microsoft.com/en-us/azure/architecture/best-practices/api-design)). We can see those differences more clearly by comparing the two across several dimensions.\n\nWith REST, developers encode control in application logic. The application knows when to call an endpoint, what arguments to send, and how to handle the response. Those decisions are made during development.\n\nWith MCP tools, much of that control moves to the AI agent. The model interprets the request, chooses a tool, constructs its arguments, evaluates the result, and decides what to do next. The harness can restrict it, but the model is still part of the control flow. A REST client already knows why it is making a call. An agent must first decide whether a tool is relevant at all. [MCP tools](https://modelcontextprotocol.io/specification/2025-11-25/server/tools)\n\nA REST application can draw from application state, cookies, memory, and user input. Code written by a developer determines which parts become request parameters.\n\nAn agent can draw from the current request, conversation history, and previous tool results. The MCP server does not see this context automatically, but the model may turn parts of it into tool arguments at runtime.\n\nThe difference is who selects what reaches the backend: predetermined code or a model reasoning over a changing conversation.\n\nREST APIs tend to expose focused, fine-grained operations that application code can compose. Keeping endpoints simple and stable limits regressions because a developer has already written and tested the workflow that connects them.\n\nWith MCP, the agent often constructs that workflow at runtime. Smaller operations give code more composability, but give an agent more choices, more intermediate results to interpret, and more opportunities to take a wrong turn. Copying a REST interface also copies assumptions about where the workflow lives and who composes it.\n\nA REST client can handle known status codes through explicit branches. Much of an error's meaning may exist only in the client code: the backend returns a code, and the application already knows the next step. Human-readable messages can become secondary output from the API. The backend and frontend developers agreed on this private language during their lunch break; the agent was not invited.\n\nAn agent must interpret the failure at runtime. It may need to change an argument, ask the user, choose another tool, or stop. If a wrapped API returns only a status code or internal identifier, the agent loses the knowledge that used to live in the REST client. Machine-readable codes still matter, but the model also needs detailed and actionable feedback. [MCP tool error handling](https://modelcontextprotocol.io/specification/2025-11-25/server/tools#error-handling)\n\nREST is stateless, so each request contains the information needed to process it. The backend does not have to retain client session context, and requests remain independent from one another.\n\nMCP has a connection lifecycle that starts with initialization and may include a server-side session. FastMCP(famous MCP server implementation) uses stateful sessions by default, retaining a context for each client between requests. It also supports a stateless mode that creates a fresh context for every request. [MCP lifecycle](https://modelcontextprotocol.io/specification/2025-11-25/basic/lifecycle), [FastMCP session modes](https://gofastmcp.com/deployment/http#understanding-sessions)\n\nIn REST, a request and its response are normally processed once. They do not become persistent input that must be sent again with every later request. A REST response does its job and leaves; a retained tool result can move into the context window and keep charging rent. In common agent harnesses (like claude code), MCP tool inputs and outputs become part of conversation history. Every retained tool call takes space from the client's context window and is sent again on later model calls, so its cost compounds across the conversation. [MCP client best practices](https://modelcontextprotocol.io/docs/develop/clients/client-best-practices)\n\nA malicious REST API can return hostile data, but a conventional client normally processes it through predetermined code, in addition to another layer of security usually imposed by the user facing client like browsers.\n\nAn MCP tool interacts with a client whose control flow depends mostly on an LLM. Tool descriptions and results may influence what the model does next, opening the door to prompt injection, tool poisoning, context disclosure, or attempts to steer the agent toward another privileged tool.\n\nThe outcome also depends on the underlying model and the harness around it. This gives third-party MCP servers a larger client-side attack surface than ordinary API integrations. The MCP specification tells clients to treat descriptions of tool behavior as untrusted and validate results before passing them to the model. Security research has also found familiar implementation vulnerabilities in tested MCP servers. [MCP tool security considerations](https://modelcontextprotocol.io/specification/2025-11-25/server/tools#security-considerations), [Equixly's MCP server research](https://equixly.com/blog/2025/03/29/mcp-server-new-security-nightmare/)\n\nThe backend capability may be the same, but the consumer is not. A REST API client follows a workflow that is predetermined and coded by a developer. An agent has more work to do, it plans on the fly, and puts a novel effort on each turn to determine what to do, including choosing a tool, calling it correctly, and combining it with other tools to satisfy user needs.\n\nDirectly wrapping every REST endpoint preserves an interface designed for a different environment. If the consumer, context, action model, failure model, trust boundary, state model, and cost model are different, the interface design should probably be different too. That is the subject of part two.", "url": "https://wpnews.pro/news/from-rest-to-mcp-1-2-different-dimensions", "canonical_source": "https://dev.to/ibrahim_mohammed_47/from-rest-to-mcp-12-different-dimensions-277j", "published_at": "2026-07-12 12:07:57+00:00", "updated_at": "2026-07-12 12:44:07.126676+00:00", "lang": "en", "topics": ["developer-tools", "artificial-intelligence", "ai-agents", "large-language-models"], "entities": ["MCP", "REST", "FastMCP", "Microsoft"], "alternates": {"html": "https://wpnews.pro/news/from-rest-to-mcp-1-2-different-dimensions", "markdown": "https://wpnews.pro/news/from-rest-to-mcp-1-2-different-dimensions.md", "text": "https://wpnews.pro/news/from-rest-to-mcp-1-2-different-dimensions.txt", "jsonld": "https://wpnews.pro/news/from-rest-to-mcp-1-2-different-dimensions.jsonld"}}