Loose JSON-RPC payloads weaken trust boundaries because the server must interpret commands before it can validate them. That creates exposure to type confusion, malformed tool calls, and context injection, especially when the agent can act at runtime. Schema-first transport reduces that ambiguity by making invalid input fail early instead of becoming a downstream security event.
Why Loose JSON-RPC Breaks MCP Trust Boundaries
When AI agents consume MCP over loosely structured JSON-RPC, the protocol stops acting like a gate and starts acting like a negotiation. The server must infer intent from partially trusted input before it can enforce meaning, which weakens the boundary between transport validation and tool authorization. That is where type confusion, malformed tool invocation, and context injection become practical failure modes rather than edge cases.
This matters most in agentic workflows because the model can generate tool calls at runtime, not just replay fixed requests. A payload that is syntactically valid JSON can still carry the wrong shape, the wrong semantic type, or extra fields that alter downstream behaviour. In practice, that creates a security gap between “received” and “safe to execute.” Schema-first handling reduces that gap by forcing invalid input to fail before it reaches execution logic. For an overview of MCP-related exposure patterns, see The State of MCP Server Security 2025.
Current guidance suggests the risk is not just malformed input, but ambiguous trust: once a server tries to interpret a loose payload, it may already have accepted an attacker-shaped command path. In practice, many teams discover this only after a tool call has been parsed, normalised, and partially acted on, rather than at the point where the payload first arrived.
How It Works in Practice
JSON-RPC can be a useful transport for MCP, but only when the contract is strict enough that the server can validate structure before it evaluates intent. Loose payloads typically fail in three ways. First, they allow type confusion, where a field that should be an enum, object, or bounded string arrives as something else and gets coerced too late. Second, they permit malformed tool calls, where optional fields, nested parameters, or unexpected arguments slip through parser logic and reach business code. Third, they allow context injection, where the agent or upstream caller sneaks in extra instructions that are treated as operational metadata.
That becomes especially dangerous when tool selection and argument validation are separated. If the server resolves a tool name first and validates the payload later, the agent may already have influenced a sensitive execution path. If the server relies on permissive deserialisation, it can accidentally accept defaults, unknown keys, or mixed formats that differ from what the operator intended. The safer pattern is to validate against an explicit schema, reject unknown or ill-typed fields early, and keep the execution path narrow enough that parsing cannot silently upgrade a request.
- Use strict schemas for every tool call, including required fields, allowed values, and field-level type checks.
- Reject unknown fields rather than ignoring them, especially when they can carry hidden instructions.
- Separate transport parsing from tool authorisation so a syntactically valid payload is not treated as safe by default.
- Log validation failures as security-relevant events, not as routine application errors.
For agent-specific context on why this failure pattern is rising, OWASP Agentic Applications Top 10 is directly relevant, and the OWASP guidance on agentic systems reinforces the same core issue: runtime behaviour must be bounded before execution, not after it. These controls tend to break down when the MCP server accepts flexible payload shapes to support multiple tools or when downstream code performs permissive coercion because interoperability was prioritised over safety.
Common Variations and Edge Cases
Tighter schemas often increase integration friction, so organisations need to balance interoperability against the risk of ambiguous execution. That tradeoff becomes visible when teams try to support multiple agents, multiple tool versions, or mixed clients that do not all emit the same structure.
One common edge case is “helpful” normalisation. A server may trim strings, default missing values, or merge nested objects in ways that make debugging easier but also make malicious input harder to distinguish from legitimate variability. Another is version drift: an agent fine-tuned for one tool schema may continue sending old field names or deprecated structures that are tolerated by the server instead of rejected. Best practice is evolving toward explicit versioning and hard failure on unsupported shapes, because silent coercion creates a larger attack surface than a clean validation error.
Another practical limitation appears in multi-agent pipelines. When one agent prepares the payload and another agent or service executes it, the boundary can become blurry unless each hop revalidates the request. That is where loose JSON-RPC is most brittle: trust becomes distributed across layers that each assume the other already checked the input. The result is not just brittle engineering, but an execution model where a malformed or adversarial payload can survive long enough to influence a privileged action.
Practitioner takeaway: the less deterministic the agent, the more deterministic the tool contract must be; if the payload format can be bent, the trust boundary can be bent with it.
Risk and Threat Considerations
Loose JSON-RPC payloads create an input-validation and trust-abuse risk class rather than a simple interoperability issue. The main exposure is that malformed or adversarially shaped tool calls can move from parse-time ambiguity into runtime execution, where they are harder to distinguish from legitimate agent output.
Failure mechanism: permissive parsing, type coercion, and late validation let an attacker or faulty agent smuggle unexpected structure, hidden arguments, or context-bearing fields into a tool path that was supposed to be bounded by schema.
Impact: the likely consequence is incorrect tool execution, unsafe parameter interpretation, or context injection that expands the agent’s effective authority and can trigger unintended actions or data exposure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while CIS Controls v8 and MITRE-ATTACK set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A1 | Loose MCP payloads enable malformed agent tool calls and context injection. |
| Recommendation: Agent inputs must be strictly validated before tool execution. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 | Malformed MCP calls can expose or misuse credentials carried in tool context. |
| Recommendation: Machine-facing inputs should never be able to smuggle or expand credential use. | ||
| CSA MAESTRO | GOVERN | MCP ambiguity weakens execution boundaries between agent intent and tool action. |
| Recommendation: Agent actions need explicit governance boundaries before runtime execution. | ||
| CIS Controls v8 | 16 | Strict request validation is a core safeguard for tool interfaces and parsers. |
| Recommendation: Application interfaces should reject unsafe or unexpected request shapes. | ||
| MITRE-ATTACK | T1204 | Context injection and malformed calls can induce unintended agent-triggered actions. |
| Recommendation: Adversarial input can steer execution into unsafe actions through trust abuse. | ||
Practitioner Guidance
What to prioritise: treat tool-contract strictness as a control objective, not a developer preference. If a payload can reach a privileged tool, the first question is whether invalid structure fails closed before any action or context resolution occurs.
Decision rule: if a field can change tool choice, target scope, or downstream side effects, it should be schema-bound and rejection-worthy on mismatch. If the server is still “making sense” of the payload after parsing, the control is too loose for agentic use.
What to verify: verify that unknown keys, deprecated fields, and coerced types are rejected consistently across all clients and versions. Also verify that validation happens at every hop in a multi-agent chain, not only at the first ingress point.
Common mistake: allowing flexible payloads during early rollout and never tightening them after agents become operational. That shortcut usually survives until the first unexpected tool call reveals that compatibility was being purchased with trust.
Practitioner takeaway: for MCP, schema discipline is not overhead added after security review; it is the mechanism that keeps agent-generated commands from being mistaken for authorised intent.
