# Testing an API With an AI Agent Over MCP — Routebase > What an agent can reliably derive from a specification, what it must not decide on its own, and why the permission model matters more than the model does. Canonical page: https://routebase.dev/guides/api-testing/testing-with-an-agent-over-mcp/ Chapter 11 of 12 · API Testing · Last reviewed 2026-09-12 · The Routebase Team Most of the work in building a test suite is transformation rather than judgement. Take an endpoint, read its documented status code, its response schema and its required fields, and produce a case that asserts exactly those things. Repeat for every endpoint. That is precisely the shape of work to hand to an agent, and it is also where the useful boundary sits. ## What an agent derives reliably Given a specification, an agent produces the mechanical layer of a suite without inventing anything. | Task | Why it works | |---|---| | A case per endpoint with the documented success status | The status is in the specification | | A schema check on each response | The schema is in the specification | | Assertions on the required fields | Required is a property of the schema | | A request body from the documented example or schema | Both are in the specification | | A scenario that chains create, read, update and delete | The path structure implies the order | | Sensible names and folder structure | Derived from paths and tags | None of that requires the agent to know what your business does. It requires the specification to be accurate. That is a different problem, and one you want solved anyway. ## What it must not decide alone Three categories need a person, and naming them explicitly matters because an agent will produce plausible output for all three. **What counts as correct behaviour.** The specification says the response has a `total` of type number. It does not say the total should be the sum of the line items minus the discount, and an agent that invents that rule has written a test that encodes a guess. **What to relax when a test goes red.** A failing assertion has two possible fixes. You change the service, or you change the test. Only one of those is usually right, and choosing wrongly turns a test suite into a record of what the service happens to do. **Where a write-heavy suite may point.** An agent asked to "run the tests" has no way to know that one environment in the list is production. The pattern that works is that the agent produces cases and diffs, and a person approves anything that changes what the suite promises. ## The permission model matters more than the model The interesting safety question about an agent is not how clever it is. It is what it is allowed to do when it is wrong. An agent operating through a credential that can only read specifications and execute tests in one project cannot delete a specification, however confidently it decides that would help. The blast radius is set by the credential and not by the prompt. That is the property you want. Three practices follow. **Scope the credential to one project.** Nothing else in the organisation is then reachable. **Grant only the operations the task needs.** Writing tests needs write access to testing, and it does not need publish rights on specifications. **Point it at an environment you can afford to have written to.** An agent that creates test data in staging is doing its job, and the same agent pointed at production is an incident. ## Where an agent is genuinely better than a person Two situations, and they have a common shape. **Bulk transformation.** Two hundred endpoints, each needing the same four assertions, is work a person does worse over time as attention degrades. An agent does the two hundredth exactly as it did the first. **Reconciliation.** Comparing a suite against a specification and reporting which endpoints have no coverage, which cases assert nothing beyond a status code, and which have drifted from the contract is tedious and mechanical. It is also the kind of review that never gets scheduled. Both are cases where the boring, consistent option beats the careful one, because the task rewards consistency rather than insight. ## In Routebase Every Routebase workspace includes an MCP server, and it covers the product's feature set, not a read-only slice. The product page for [agent-ready APIs](/agent-ready-apis/) covers the API side of the same story, from descriptions to error bodies. An agent connected to it works the same specifications, suites, cases and runs your team works, so nothing is transcribed between two systems. _Screenshot: A key for an agent grants named permissions instead of everything, and each permission can be held to a single project._ In practice an agent can read a specification, create a suite and add a case per endpoint with its assertions. It links each case to its endpoint so schema validation applies, runs the suite against an environment, and reads the structured results back. When something fails it can fetch the case detail, the resolved request and the assertion comparison. That is enough to propose a fix instead of guessing at one. The permission model is the part to understand before you connect anything. An agent authenticates with an API key carrying explicit scopes, or through an OAuth sign-in that follows your organization role. The enforcement happens in two places. Tool discovery advertises only what the credential allows, and the server checks again when a tool is called. A key can additionally be restricted to a single project, and a key restricted that way cannot reach the rest of the organisation regardless of what the agent is asked to do. Some limits are structural rather than a matter of permissions. There is no tool that changes a plan, buys seats or touches a payment method, and no tool that grants a role, invites a member or changes SSO configuration. Secret variables are write-only, because every read masks the value. Those are not settings you can loosen, and their being fixed is the point. The [MCP Quickstart](https://docs.routebase.dev/mcp-quickstart/) covers connecting a client, and [MCP Authentication](https://docs.routebase.dev/mcp-authentication/) covers scopes and what an agent can never do. ## Frequently asked questions ### What is MCP in the context of API testing? The Model Context Protocol is an open standard that lets an AI agent call tools exposed by a server, rather than guessing at an interface from documentation. For API testing that means an agent can read your specification, create test cases, run a suite and read the results back as structured data. The agent works the same objects your team works, so nothing has to be transcribed between the two. ### Can an AI agent write API tests? It can write the mechanical majority of them well, which is a case per endpoint with the documented status code, a schema check and assertions on the required fields. That work is a transformation of the specification rather than a judgement call, so it is exactly the kind of task to hand over. The cases that encode a business rule still need a person, because the specification does not say what the answer should be. ### Is it safe to let an AI agent run tests against my API? It is as safe as the credential you give it, which is why the permission model matters more than the model does. Give the agent a scoped credential limited to one project and to the operations it needs, and point it at an environment you can afford to have written to. An agent working under a narrow credential cannot exceed it, whatever it is asked to do. ### What should an AI agent not decide when writing tests? It should not decide what counts as correct business behaviour, what may be relaxed when a test goes red, or which environment a write-heavy suite may target. Those are judgement calls with consequences outside the test suite. A useful division is that the agent produces the cases and the diffs, and a person approves anything that changes what the suite promises. --- [Routebase](https://routebase.dev/) — [Sign up](https://app.routebase.dev/): Every account starts with a 14-day Pro trial — no credit card required.