From REST to MCP (1/2): Different Dimensions

Intro An MCP server can look like another API layer: expose existing REST endpoints as tools and call it a day. Both 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 ). We can see those differences more clearly by comparing the two across several dimensions. Dimensions The consumer With 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. With 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 The context A REST application can draw from application state, cookies, memory, and user input. Code written by a developer determines which parts become request parameters. An 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. The difference is who selects what reaches the backend: predetermined code or a model reasoning over a changing conversation. The action model REST 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. With MCP, the agent often