Why do MCP servers built from REST APIs often feel brittle for agents?

Why REST feels brittle once you hand it to an agent

REST can be perfectly serviceable for a person, yet feel awkward for an agent because the burden shifts from a human’s memory and judgement to the model’s active context window. The agent has to rediscover the shape of the API, choose the right call, preserve state across steps, and recover from ambiguous results while it is also reasoning about the task itself.

That means brittleness often shows up not as one fatal flaw, but as accumulated friction: too many endpoints, too many parameters, too much back-and-forth, and too much output for the agent to keep reliable state. A design that is elegant for a human operator can become noisy and error-prone when every call must be re-justified in real time.

Where the brittleness comes from in practice

REST assumes a caller can learn the interface once, then reuse that knowledge cheaply. Agents do not get that advantage in the same way. They must infer intent from descriptions, translate intent into calls, and integrate each response into a bounded context budget. If the API requires several dependent calls, the probability of drift rises with each step.

One source of fragility is state fragmentation. When the agent has to assemble a task from multiple resources, it can lose track of prior identifiers, partial results, or implicit assumptions. Another source is result verbosity. Long JSON payloads may be fine for a developer reading logs, but they consume context quickly and crowd out the task instructions that still need to survive.

REST also tends to reward fine-grained tool design, but agents often perform better when tool boundaries match the job they are trying to complete. In the MCP world, that is why well-structured server design matters: the difference between a usable tool and a brittle one is often whether the agent can discover, call, and interpret it without an excessive number of recovery steps. NHIMG’s MCP Security Guide is useful here because it shows how authorization, token handling, and server design affect whether an MCP-backed tool stays workable under agent pressure.

Why the protocol shape matters to agent reliability

For agents, the protocol is not just transport, it is part of the reasoning environment. A tool that is easy for a human to invoke can still be hard for an agent to use if it exposes too many optional fields, returns too much unstructured detail, or forces the caller to perform several interpretive steps after each response. The agent is effectively paying a cognitive tax on every round trip.

This is where tighter protocol contracts help. Resource scoping, audience-bound tokens, and clearer authorization boundaries reduce ambiguity around what the server expects and what the agent is allowed to do. In practical terms, the most brittle REST-based mcp server are usually the ones that try to behave like generic APIs rather than purpose-built agent tools. The MCP authorization specification, along with the related OAuth resource indicator and protected resource metadata standards, shows why explicit resource context is important for keeping tool use deterministic.

That same principle applies to agent identity and delegation. If the server cannot distinguish who is acting, on whose behalf, and under what scope, the tool path becomes harder to reason about and more likely to fail in edge cases. NHIMG’s NHI Authentication Guide is relevant because it covers the authentication patterns that make machine and agent access more stable, including OAuth client credentials, mTLS, workload federation, and other machine-to-machine approaches.

What practitioners should optimize instead

Practitioners generally get better results when they optimise for task completion, not API completeness. That means fewer tool calls per outcome, narrower response shapes, and less reliance on the agent to preserve hidden state across multiple hops. If a workflow can be collapsed into one semantically rich action without losing control, it usually becomes more reliable for an agent.

It also means designing for discoverability and boundedness. A good agent-facing service should make the minimum necessary options obvious, keep outputs compact, and avoid requiring the model to stitch together too many intermediate identifiers. Where the workflow is inherently multi-step, each step should have a clear success signal and a small, predictable response surface. For a broader agentic design perspective, AI Agent Authorisation Guide helps show how per-action authorization and least privilege reduce the blast radius when the tool path is messy.

When the API itself is the bottleneck, the fix is usually not “give the agent more context”, it is “make the tool easier to complete safely.” That often means reworking endpoints around agent tasks, not human browsing patterns, and treating response verbosity, step count, and authorization scope as usability variables. For agent-heavy environments, AI Agent Observability, Audit and Incident Response Guide is a good complement because it clarifies what to log when tool interactions go wrong and how to tell whether the agent is struggling with the interface or the task itself.

Risk and Threat Considerations

Brittle MCP server design is not just an efficiency issue. When agents need many calls, carry too much intermediate state, or rely on ambiguous tool outputs, the chance of wrong-action selection, context drift, and accidental overreach increases. In an adversarial setting, those same weaknesses make it easier for a malicious instruction, poisoned response, or misleading tool result to steer the agent off course.

Failure mechanism: Excessive round trips and verbose responses enlarge the number of decision points where the agent can lose state, mis-handle a result, or repeat an unsafe action, especially when authorization and task context are implicit rather than explicit.

Impact: The result can be failed task completion, privilege misuse, unintended side effects, or a larger blast radius when the agent is tricked into chaining calls it should not have made.

Practitioner Guidance

What to prioritise: Reduce the number of agent decisions required to complete a task. If a workflow can be expressed as one bounded action with a compact response, prefer that over a chain of generic REST calls that forces the model to reconstruct intent at every step.

What to verify: Check whether each tool call can be understood without scanning large payloads or preserving hidden state across multiple turns. If the agent must repeatedly rediscover identifiers, scopes, or prior results, the interface is probably too brittle for reliable use.

Common mistake: Treating “API completeness” as the goal. For agents, the better metric is whether the tool can be used repeatedly, safely, and predictably inside a limited context window.

Practitioner takeaway: The best agent-facing REST design is usually the one that does less per call, returns less per response, and leaves less for the model to infer.

Related resources from NHI Mgmt Group

• How should security teams govern MCP servers that wrap REST APIs?
• How should organisations govern AI traffic when they expose APIs, events, and MCP servers to autonomous agents?
• What is the difference between MCP servers and REST APIs for AI agent integration?
• How should organizations prioritize security in their MCP implementations?