Available Tools

The ReadyAPI MCP Plugin exposes ~40 tools organized into six groups based on the job you are trying to do. This mirrors how you actually work with a ReadyAPI project: look around, build it out, manage details, generate coverage, react to change, and check results. Version 1.2.0 consolidates 27 individual list, describe, and delete tools into three parameterized tools, reducing the number of tool schemas your AI client holds in context.

Note

The MCP integration currently supports REST APIs, HTTP Requests, and Kafka Services. GraphQL, WSDL, AsyncAPI, gRPC, and other protocol types are not supported for AI test generation or impact analysis.

Conventions

Two conventions apply to all tools:

Project reference. Every tool that operates on a project accepts the project's display name as shown by list("project").
Required parameters. Parameters marked with an asterisk (*) are required. All others are optional.

Warning

Tools in Groups 2, 3, 4, and 5 write directly to your project. There is no in-app accept or decline gate in this release - changes land immediately and are captured in the MCP log for audit. Review proposed changes before applying them, especially when working on projects under version control.

Tool groups at a glance

Table 115. Tool groups

Group	Tools	Purpose
1. Discover and Inspect	2	Read-only lookups across the full resource hierarchy. None of these tools changes your project.
2. Build and Maintain Structure	24	Full Create/Update/Delete across projects, suites, cases, and steps. These tools write directly to your project.
3. Manage Assertions	5	Dedicated assertion CRUD for REST request steps, independent of the healing workflow.
4. Generate Coverage	1	Scaffold test cases from an API spec - the fastest path to initial coverage for a new or existing API.
5. Detect and Heal Change	4 tools + 4 prompts	Heal API Definitions and Test Cases in two phases: analyze and apply spec changes to keep your API definition in sync, then identify and fix impacted tests - all in one guided workflow.
6. Run and Verify	4	Execute tests at the project, suite, or case scope and retrieve per-step results.

Staged canned prompts

Four-stage prompts wrap the two tools above into a guided, checkpointed workflow. See Canned Prompts (Staged Workflow) for full details.

Table 116. Staged canned prompts

Prompt	Stage	Try asking your AI client
`discover_workspace`	1 of 4	"What projects and APIs do I have?"
`fetch_existing_spec`	2 of 4	"Fetch the current spec for the Payments API."
`analyze_api_impact`	3 of 4	"Analyze the impact of this new spec on my Payments API tests."
`heal_impacted_tests`	4 of 4	"Heal my tests for this spec change."

Typical tool-call sequence

A complete generate → run → heal flow chains the groups in this order:

[Group 1] list("project") → list("api", { projectName })
  → [Group 4] generate_test_cases_for_api
  → [Group 6] run_functional_tests → job_status_poll (poll until COMPLETED)
  → [Group 6] job_result_read
  → [Group 5] analyze_api_impact → rest_test_step_update (once per impacted step)
  → [Group 6] run_functional_tests (re-run to verify)

Use cases mapped to groups

Table 117. Use cases mapped to groups

Use case	Primary groups
Detect changes from a spec update	5 - Detect and Heal Change
Ad-hoc "what does this new spec break" analysis	5 - Detect and Heal Change
Review and iterate on tests until they pass	5 + 6 - Detect and Heal Change, Run and Verify
Generate test cases from an API spec	4 - Generate Coverage
Build out the project and test structure to organizational standards	2 - Build and Maintain Structure
Create a REST request step for a specific endpoint	2 - Build and Maintain Structure