AI and infrastructure ยท first published on Medium, 16 January 2026
MCP Your Infrastructure: Intent-Driven Access to Testing Systems
Why we did this
We operate a large and complex system. As part of it, we built a similarly complex testing infrastructure.
This infrastructure supports manual testing, automation, and operational workflows. It is used by QA, developers, product, and management.
It already exposes powerful capabilities.
Perform actions in the system. Retrieve system information. Retrieve and generate test data.
All of this is available via REST and GraphQL endpoints. Even when designed carefully, using this infrastructure still requires knowledge of multiple endpoints, parameters, and internal concepts.
The problem
The problem was not missing functionality. The problem was access to it.
Technical and business knowledge acted as a barrier. Many stakeholders did not know how to perform certain actions, or did not even know those actions existed.
Even simple tasks required knowing which service to call, knowing which endpoints to use and in which order, knowing which parameters were required, and switching between multiple tools and dashboards.
As a result, only a small group of people could safely operate the infrastructure. That group became an operational choke point. As the system grew, delivery speed and test coverage degraded because access did not scale.
The cost showed up repeatedly in data preparation and test analysis. Hours were spent creating users, accounts, and states just to validate small changes, and testers manually reviewed multiple reports daily to understand regressions.
Everyone else had to ask for help, wait, or avoid the task entirely.
What changed with MCP
We exposed large parts of our testing infrastructure as MCP tools. This did not replace our APIs. It added a semantic layer on top of them.
Instead of interacting with endpoints, people interact through intent. This shifts scalability from human knowledge and documentation to the system itself.
The agent resolves which underlying services to call, in which order, with which parameters.
The user no longer needs to understand the communication between systems.
Example: generating a test user
Before MCP, generating a usable test user was a multi step task. A developer had to locate the correct service, call the right endpoint, supply a valid combination of parameters, and understand internal user and account models. If the parameters were wrong or incomplete, the result was an unusable user and another iteration.
With MCP, the same intent is expressed in one sentence.
Find me a user that has a savings account and a positive balance.
The agent translates this intent into the required calls, validates the outcome, and returns a user that can log in and perform real actions. No knowledge of internal structure is required.
Crucially, the workflow does not stop there. The same conversation can continue with actions on that user, inspections, or further setup, without switching tools or losing context.
Example: analysing test results
Allure is our reporting system for automated tests.
Previously, analysis was fragmented. A tester had to open multiple reports, correlate runs manually, and track regressions across services by hand. This work was repetitive and easy to get wrong.
With MCP, the analysis becomes intent driven (a very simplified version of the prompt).
Given this list of services, find regression status and generate an HTML report.
The agent gathers results across runs, identifies regressions, finds trends, analyses logs and produces a single consolidated report. What previously required daily manual effort is reduced to a single interaction, with consistent and repeatable output.
What changed operationally
Before MCP, critical knowledge lived with a small group of people. Testers prepared environments and data, and developers depended on them even for small checks.
After MCP, this changed. Work no longer depended on specific people or tribal knowledge. Developers and other stakeholders could act independently without slowing delivery.
Developers can now generate test data, simulate flows, and validate changes themselves using a few prompts, without waiting on testers.
Non technical stakeholders can interact with parts of the system they previously could not. They do not need to understand internal flows or system structure. They only need to express what they want.
What we gained
The biggest gain is not automation. It is removal of handoffs.
Tasks that previously required coordination between people and tools now happen end to end in a single interaction. This reduced waiting time, interruptions, and hidden dependencies.
Security and access control
Exposing infrastructure through MCP requires explicit guardrails.
For integrations that require specific users or elevated access, we use tools that rely on local secrets. This limits sensitive capabilities to the people or environments that need them.
The MCP layer remains free of embedded secrets. Permissions and access are enforced at the tool level, not in the agent logic.
What this is and what it is not
This is not about replacing existing systems. It is not about letting agents run uncontrolled operations.
It is about providing a controlled, intent driven interface over existing infrastructure.
MCP does not remove complexity. It relocates it to a place where it can be managed, audited, and evolved.
Where this goes next
This is not an optional optimization. As systems and teams grow, intent based access becomes the only way to preserve velocity and safety.
At that point, infrastructure stops being something people learn. It becomes something they operate through language, with explicit guardrails.
Want a guardrailed assistant like this on your site, or AI automation with the same rigour?