Available Tools

The ReadyAPI MCP Plugin exposes 36 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.

Note

The MCP integration currently supports only REST APIs. GraphQL and other protocol types are not supported.

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 project_list.
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 91. Tool groups

Group	Tools	Purpose
1. Discover and Inspect	15	Read-only lookups across the full resource hierarchy. None of these tools changes your project.
2. Build and Maintain Structure	11	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	2 tools + 4 prompts	Diff a new spec, identify impacted tests, and apply LLM-recommended fixes in one batch.
6. Run and Verify	4	Execute tests at project, suite, or case scope and retrieve per-step results.

1. Discover and Inspect

Read-only lookups across the full resource hierarchy. These are almost always the first tools called in a session - they let the AI client and the user get oriented before doing anything else. None of these tools changes your project.

Table 92. Discover and Inspect tools

Tool	What it does	Key parameters	Try asking your AI client
`project_list`	Returns all projects in the current ReadyAPI workspace. Supports elicitation and presents a project picker if the client supports it.	None	"List all my ReadyAPI projects."
`project_find_one`	Looks up a named project and returns its path, type, description, and open or closed status.	`projectName`*	"Show me details for the Billing project."
`api_list`	Returns all REST API names within a given project.	`projectName`*	"What APIs are in the Billing project?"
`api_read`	Returns an API's name, type, description, and its full list of resources, methods, and requests.	`projectName`, `apiName`	"Describe the Payments API - what resources and methods does it have?"
`api_request_description`	Returns full details for a single request: parameters, method, content type, auth profile, and whether it has attachments.	`apiName`, `projectName`, `resourcePath`, `httpMethod`, `requestName`, `xmlbeansRequestId`	"Show me the details of the CreateInvoice request on the Payments API."
`suite_list`	Lists all test suites in a project, with test case counts.	`projectName`*	"List the test suites in the Billing project."
`suite_find_one`	Returns a summary of one named test suite, including its test case count.	`projectName`, `testSuiteName`	"How many test cases are in the Checkout Regression suite?"
`case_list`	Lists all test cases in a suite, with tags, step counts, and step names.	`projectName`, `suiteName`	"List the test cases in the Checkout Regression suite."
`case_find_one`	Returns full details on one test case, including every test step.	`projectName`, `testSuiteName`, `testCaseName`*	"Show me all the test steps in the Guest Checkout test case."
`step_list`	Lists all test steps in a test case, with type and custom properties.	`projectName`, `suiteName`, `caseName`*	"List the test steps in the Guest Checkout test case."
`step_find_one`	Returns full details for a single test step, including its custom properties.	`projectName`, `testSuiteName`, `testCaseName`, `testStepName`	"Show me the details of the Submit Order step."
`environment_list`	Returns all environment names defined in a project.	`projectName`*	"What environments are set up for the Billing project?"
`environment_find`	Finds environments by name (partial match) and returns custom properties and REST service endpoints.	`projectName`, `environmentName`	"Show me the config for the Staging environment."
`auth_profile_list`	Lists all auth profiles in a project, with name and type (for example, OAuth, NTLM).	`projectName`*	"What auth profiles exist in the Billing project?"
`auth_profile_find`	Finds an auth profile by exact name and returns its non-secret properties.	`projectName`, `authProfileName`	"Show me the OAuth profile details for Billing."

2. Build and Maintain Structure

Full Create/Update/Delete coverage across the project hierarchy, plus scaffolding a new REST request test step. These tools write directly to the project - review changes before committing to version control.

Table 93. Build and Maintain Structure tools

Tool	What it does	Key parameters	Try asking your AI client
`project_create`	Creates a new ReadyAPI project and registers it in the workspace. Creates the destination folder if it does not already exist.	`projectName`, `folderPath`*	"Create a new ReadyAPI project called Payments-V2 in /projects/payments."
`project_delete`	Removes a project from the ReadyAPI workspace. Does not delete the project file from disk.	`projectName`*	"Remove the Legacy-Payments project from my workspace."
`suite_create`	Creates a new, empty test suite. The suite name must be unique within the project.	`projectName`, `testSuiteName`	"Create a new test suite called Payments Smoke Tests in the Billing project."
`suite_update`	Renames an existing test suite.	`projectName`, `testSuiteName`, `newTestSuiteName`*	"Rename the Smoke Tests suite to Payments Smoke v2."
`suite_delete`	Deletes a test suite and all of its test cases.	`projectName`, `testSuiteName`	"Delete the deprecated Legacy Login suite."
`case_create`	Creates a new test case. Creates the parent suite automatically if it does not already exist.	`projectName`, `testSuiteName`, `testCaseName`*	"Add a new test case called Refund Flow to the Payments Smoke Tests suite."
`case_update`	Renames a test case and optionally enables or disables it.	`projectName`, `testSuiteName`, `testCaseName`*, `newTestCaseName`, `enabled`	"Rename Refund Flow to Partial Refund Flow and disable it for now."
`case_delete`	Deletes a test case and all of its test steps.	`projectName`, `testSuiteName`, `testCaseName`*	"Delete the Old Refund Flow test case."
`step_update`	Renames a test step and optionally enables or disables it.	`projectName`, `testSuiteName`, `testCaseName`, `testStepName`, `newTestStepName`, `enabled`	"Rename the Submit Order step to Submit Order v2."
`step_delete`	Deletes a test step. Data-driven steps must be removed manually from ReadyAPI.	`projectName`, `testSuiteName`, `testCaseName`, `testStepName`	"Remove the deprecated Legacy Auth step."
`step_create_rest`	Creates a REST request test step against an existing API, request, method, and resource path. Supports optional parameters, headers, body, file attachments, auth, environment, and initial assertions. The test suite and test case are created automatically if they do not already exist.	`targetApiName`, `targetRequestName`, `targetHttpMethod`, `targetResourcePath`, `projectName`, `suiteName`, `caseName`, `stepName`; optional: `parameters`, `headers`, `body`, `attachmentUrls`, `authorization`, `environmentName`, `assertions`	"Add a REST request step that calls GET /invoices/{id} to the Refund Flow test case."

3. Manage Assertions

A dedicated assertion CRUD surface for REST request steps, independent of the healing workflow in Group 5. Use this group when you want direct, manual control over what a step checks. For assertion changes driven by a spec update, use Group 5.

Supported assertion types across all tools in this group: VALID_HTTP_STATUS_CODES, CONTAINS, NOT_CONTAINS, GROOVY_SCRIPT, RESPONSE_SLA, SCHEMA_COMPLIANCE.

Table 94. Manage Assertions tools

Tool	What it does	Key parameters	Try asking your AI client
`assertion_list_all`	Lists every assertion on a step, with type and enabled state.	`projectName`, `suiteName`, `caseName`, `stepName`	"What assertions are on the Submit Order step?"
`assertion_find_one`	Finds a single named assertion of a given type and returns its full configuration.	`projectName`, `suiteName`, `caseName`, `stepName`, `assertionType`, `assertionName`	"Show me the response SLA assertion on Submit Order."
`assertion_add`	Adds a new assertion to a REST request step. Supply type-specific parameters: `codes` for `VALID_HTTP_STATUS_CODES`; `slaValue` (ms) for `RESPONSE_SLA`; `scriptText` for `GROOVY_SCRIPT`; `searchString`, `ignoreCase`, `useRegex` for `CONTAINS` and `NOT_CONTAINS`; `schemaUrl` and `strictMode` for `SCHEMA_COMPLIANCE`.	`projectName`, `suiteName`, `caseName`, `stepName`, `assertionType`*, optional: `assertionName`, type-specific parameters	"Add an assertion to Submit Order that the response status is 200 or 201."
`assertion_modify`	Updates one or more properties of an existing assertion. Supply only the parameters you want to change.	`projectName`, `suiteName`, `caseName`, `stepName`, `assertionType`, `assertionName`; type-specific parameters	"Update the SLA assertion on Submit Order to 800ms."
`assertion_delete`	Deletes a named assertion from a step.	`projectName`, `suiteName`, `caseName`, `stepName`, `assertionType`, `assertionName`	"Remove the schema compliance assertion from Submit Order."

4. Generate Coverage

The fastest path from a spec to running tests. This tool is destructive and open-world - it writes directly to the target project. Review generated test cases before running or committing them to version control.

Table 95. Test Case management

Tool	What it does	Key parameters	Try asking your AI client
`generate_test_cases_for_api`	Generates test cases from an API specification provided as inline content, a file path, or a URL. Produces one test case per resource, with a REST request step for each method. Each generated step asserts HTTP response code, Swagger compliance, and response SLA. Can create the target project automatically if it does not already exist.	`api_source`*, `api_type`, `project.path`, `create_if_missing`	"Generate test cases for this OpenAPI spec and add them to the Billing project."

5. Detect and Heal Change

The change-response workflow: diff a new spec against what is currently in ReadyAPI, identify exactly which tests it breaks, and apply LLM-recommended fixes in one batch. Four-staged canned prompts wrap the two underlying tools into a guided, checkpointed flow - see Staged canned prompts below.

`analyze_api_impact`

Diffs a new spec against the existing one stored in ReadyAPI using openapi-diff-core. Matches changed endpoints to test suites and returns the full spec diff, a list of impacted test steps, and per-step healing advice.

Key parameters: projectName*, apiName*, newSpec*, newSpecSourceType* — see Supported newSpecSourceType values below.

Try asking your AI client: "Compare this new spec to what's in ReadyAPI and tell me which tests it breaks."

Supported `newSpecSourceType` values

newSpecSourceType accepts the following values for analyze_api_impact:

Table 96. Supported values

Value	Description
`URL`	Remote URL pointing to a Swagger or OpenAPI definition.
`FILE_PATH`	Absolute path to a local OpenAPI/Swagger file (JSON or YAML).
`RAW_STRING`	Inline JSON or YAML spec content provided directly in the prompt.

`rest_test_step_update`

Applies LLM-recommended parameter, request body, response, and assertion changes to a single named test step. Call once per impacted step. Returns applied and skipped changes with reasons, and whether the project was saved.

Key parameters: project*, testSuite*, testCase*, testStep*; optional: parameterChanges[], requestBodyChanges[], responseChanges[], assertionChanges[]

Try asking your AI client: "Apply the recommended fixes to the impacted tests."

Input Schema

Defines the changes to apply to a single test step. Pass the values returned by analyze_api_impact directly - do not construct them manually.

Table 97. Input schema

Parameter	Type	Required	Description
`project`	string	Yes	Project name
`testSuite`	string	Yes	Exact suite name from `analyze_api_impact` output
`testCase`	string	Yes	Exact case name
`testStep`	string	Yes	Exact step name
`parameterChanges[].changeType`	`ADDED` \| `REMOVED` \| `MODIFIED`	No	Type of parameter change
`parameterChanges[].name`	string	No	Parameter name
`parameterChanges[].location`	`query` \| `header` \| `path` \| `matrix` \| `plain`	No	Parameter location
`parameterChanges[].oldType`	string	No	Previous parameter type
`parameterChanges[].newType`	string	No	Updated parameter type
`parameterChanges[].newRequired`	boolean	No	Updated required flag
`requestBodyChanges[].changeType`	`ADDED` \| `REMOVED` \| `MODIFIED`	No	`ADDED` inserts a typed placeholder; `REMOVED` deletes the field; `MODIFIED` resets it
`requestBodyChanges[].fieldPath`	string	No	Slash-separated field path, for example, `/address/city`
`requestBodyChanges[].newType`	string	No	Updated field type
`responseChanges[]`	-	No	Acknowledged and listed as skipped - response bodies are re-validated by the step's schema-compliance assertion after the spec update
`assertionChanges[].assertionType`	string	No	Assertion type, for example, `ValidHttpStatusCodes`
`assertionChanges[].healingAction`	`ADD_STATUS_CODE` \| `REMOVE_STATUS_CODE` \| `ADD_JSONPATH_EXISTENCE` \| `REMOVE_JSONPATH_EXISTENCE` \| `REMOVE_JSONPATH_CONTENT` \| `MANUAL_REVIEW`	No	Action to apply. `MANUAL_REVIEW` is always skipped and returned for human attention.
`assertionChanges[].statusCode`	string	No	Required for `ADD_STATUS_CODE` and `REMOVE_STATUS_CODE`
`assertionChanges[].fieldPath`	string	No	Required for JSONPath actions
`assertionChanges[].assertionName`	string	No	Required for `REMOVE_JSONPATH_CONTENT` and `MANUAL_REVIEW`

Output schema

Returned after processing the Input Schema above. Use applied[] and skipped[] to verify what changed. For any entry in skipped[] with healingAction: MANUAL_REVIEW, intervention in ReadyAPI is required before re-running.

Table 98. Output schema

Field	Type	Description
`project`	string	Project name
`testSuite`	string	Suite name
`testCase`	string	Case name
`testStep`	string	Step name
`applied[]`	array	Changes applied, each with `changeType`, `name`, and `detail`
`skipped[]`	array	Changes skipped, each with `changeType`, `name`, and `reason`
`saved`	boolean	Whether the project was saved after applying the changes

6. Run and Verify

Execute tests and retrieve results. Pairs naturally with Group 5 - heal, then re-run to confirm - and with Group 3 - adjust an assertion, then re-run to verify.

Table 99. Run and Verify tools

Tool	What it does	Key parameters	Try asking your AI client
`run_functional_tests`	Starts a background test run scoped to a project, suite, or case. Returns a `runId`.	`project`, `testSuite`; optional: `testCase`	"Run the Payments Smoke Tests suite."
`job_status_poll`	Polls the status of a running job. Returns status (`RUNNING`, `COMPLETED`, FAILED, CANCELED), percent complete, pass/fail/pending summary, and `nextPollAfterMs`. Supports long-polling by using `waitSeconds` (0–20) - the server holds the request and returns early when the job finishes, reducing round-trip. Call again after `nextPollAfterMs` until status is no longer `RUNNING`.	`runId`*; optional: `waitSeconds`	-
`job_result_read`	Fetches full per-case and per-step results for a completed job. Only available once `job_status_poll` reports `COMPLETED` or `FAILED`. For targeted failure logs only, use `job_failures_read` instead.	`runId`*	"Show me the results of that last test run - what failed and why?"
`job_failures_read`	Fetches targeted log lines for failed test items within a completed job. Use this for focused root-cause analysis without retrieving the full result set.	`runId`*	"Show me only the failures from that last run."

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 100. 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] project_list → api_list
  → [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 101. 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

Available Tools

Note

Conventions

Warning

Tool groups at a glance

1. Discover and Inspect

2. Build and Maintain Structure

3. Manage Assertions

4. Generate Coverage

5. Detect and Heal Change

`analyze_api_impact`

Supported `newSpecSourceType` values

`rest_test_step_update`

Input Schema

Output schema

6. Run and Verify

Staged canned prompts

Typical tool-call sequence

Use cases mapped to groups

See also

Search results

Available Tools

Note

Conventions

Warning

Tool groups at a glance

1. Discover and Inspect

2. Build and Maintain Structure

3. Manage Assertions

4. Generate Coverage

5. Detect and Heal Change

analyze_api_impact

Supported newSpecSourceType values

rest_test_step_update

Input Schema

Output schema

6. Run and Verify

Staged canned prompts

Typical tool-call sequence

Use cases mapped to groups

See also

Search results

`analyze_api_impact`

Supported `newSpecSourceType` values

`rest_test_step_update`