November 18, 2025 · Anthony Lonergan
How MCP’s contract-based design promotes automated tool discovery and secure execution
Since its introduction, the Model Context Protocol (MCP) has enjoyed widespread adoption, with new servers and registries appearing at a relentless pace. Now organizations are racing to evolve their technology strategies to keep up with the latest innovation, meet customer expectations, and stay competitive. And let’s be honest, that fear of being left behind is probably fueling a lot of the rush into AI enablement.
Automating discovery is at the heart of the MCP protocol and is essential to the broader AI ecosystem. Instead of developers manually wiring up every possible tool or resource an AI might need, MCP provides a standardized way to ask an MCP server what it can do. Think of it as giving AI agents a dynamic directory of tools, along with precise, schema-based descriptions of how to use them. This is akin to the contract-based approach pioneered by 42Crunch for REST APIs but now applied to AI applications. The contract is a core component of MCP architecture and automated discovery.
Example from MCP Documentation: how AI agents interact with available tools and resources
A contract-based approach is what makes AI enablement work in practice. How well teams manage these contracts will ultimately determine the success or failure of their AI initiatives. The MCP contract must always accurately describe how to connect to each underlying tool or resource, often mapping directly to backend APIs or sequences of API calls. As underlying APIs evolve over time as part of their development, the MCP contract must remain consistent and accurate in how it defines access to those tools and resources.
If an MCP server exposes vague, incomplete, or outdated context, the result is confusing AI behavior, unreliable outputs, and a frustrating experience for users. Maintaining accurate MCP contracts is therefore essential to ensure AI initiatives deliver real value and work reliably with existing systems and APIs.
Every piece of data or context an AI agent receives from an MCP server shapes its understanding of how to use a tool or resource. If that context includes unauthorized or leaked information in API response messages, for example, it can rapidly become a roadmap for misuse.
Security researchers illustrated this risk in a case recently covered in APISecurity.io. They discovered a critical flaw in a Formula 1 driver registration portal where a routine API call to update a user profile returned far more data than necessary. Hidden among the response properties was a “roles” field, seemingly harmless, but enough to prompt the researchers to attempt privilege escalation. When they tried to update their role to administrator, it worked, granting full access to private information for other registered drivers.
“The HTTP request to update our profile didn’t really have many interesting attributes, but the JSON returned in the response had a lot of extra values” ref
What made this possible wasn’t an exposed password or secret that would stand out as a vulnerability; it was excessive context. The API revealed more than it should, and that extra detail provided just enough insight for the researchers to learn ways to compromise the system.
To explore how this same vulnerability might play out in an AI-enabled environment, we ran an experiment using a similarly flawed API. We connected it to an AI agent through an MCP server to see how the agent would interpret the leaked context. The results were eye-opening: the AI immediately recognized the “roles” and “status” properties exposed by the API, incorporated them into its prompt responses to the user, and even reasoned its way to changing the user’s role to administrator.
Our experiment demonstrated how leaked data properties in an API response allowed the connected AI agent to infer and act on privileged information. Without any malicious intent, the agent effectively learned about the user’s role and status from the leaked context and then used that knowledge to change the user’s permissions.
This example really highlights that MCPs do not replace APIs; in fact, both components must work together. Before exposing APIs to an MCP server and probabilistic AI agents, teams will need to review their APIs and set the right constraints on the information returned. Doing so ensures the MCP server only delivers necessary and authorized context to the AI agent, protecting the integrity of the system and ensuring a safe, reliable, and secure AI experience.
Since 2019, 42Crunch has helped API teams implement tools and practices to define and enforce precise constraints on their APIs, ensuring that each API does exactly what it is intended to do, and nothing else.
One of the immediate benefits of this approach is information constraint: by explicitly documenting expected inputs and outputs, teams make it clear: this is what our API does, this is how to use it, and this is what you should expect in the response, and nothing more. The same principle applies to AI enablement through MCP: accurate contracts prevent AI agents from seeing unnecessary or unauthorized context.
Because API contracts are continuously managed as a development artefact, they stay up to date as APIs evolve. This provides many practical benefits: maintaining a current inventory of APIs, automating functional and security testing at pace for each API, and establishing a reliable foundation for runtime monitoring and anomaly detection before new or updated services are published.
With 42Crunch, teams are well-positioned to securely adopt the MCP protocol and safely expose their services and APIs to AI agents. By deriving MCP servers from rigorously maintained API contracts, organizations ensure that the context shared with AI agents is always accurate, current, and constrained, enabling AI innovation without increasing risk.
Point the 42Crunch MCP scan at any MCP server and receive a scored report against the OWASP MCP Top 10 and your regulatory frameworks in under 60 seconds. No agent, no deployment, no commitment required.