Available Tools

The ReadyAPI MCP Plugin exposes 54 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 92. 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	25	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 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 93. 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 a version control system.

Table 94. 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_update`	Updates elements of an existing project. Supports updating both built-in and custom project properties. Returns an error if a built-in property does not exist. Note For composite projects, encrypted properties, or script language changes, modifications should be made through the ReadyAPI UI.	`projectName`*; optional: `projectProperties`, `customProperties`	"Update the custom properties of the Billing project."
`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."
`step_create_http`	Creates an HTTP Request test step inside a named test case. Unlike REST Request steps, it is not tied to an imported API definition and is used for standalone HTTP/HTTPS calls to any URL - such as auth token endpoints, webhooks, or third-party services. Supports method, endpoint, parameters, headers, request body, auth, timeout, follow redirects, and assertions.	`projectName`, `testSuiteName`, `testCaseName`, `stepName`, `endpoint`*; optional: `method`, `parameters`, `headers`, `body`, `authorization`, `encoding`, `timeout`, `followRedirects`, `multiValueDelimiter`, `sendEmptyParameters`, `environment`, `assertions`	"Add an HTTP request step that calls the auth token endpoint in the Refund Flow test case."
`api_request_create`	Creates a new request under a given API resource. Supports method, request name, endpoint, and a parameter table with type and default values.	`projectName`, `apiName`, `resourcePath`, `httpMethod`, `requestName`, `endpoint`; optional: `requestParams`	"Create a POST request called CreateOrder under /orders in the Payments API."
`api_request_delete`	Deletes a specific request or all requests from an API resource.	`projectName`, `apiName`, `resourcePath`, `httpMethod`, `requestName`*	"Delete the CreateInvoice request from the Payments API."
`api_request_update`	Modifies a REST request's basic identity and configuration - endpoint, HTTP method, and request name. Supports partial updates; returns the updated API info on success or the reason for failure.	`projectName`, `apiName`, `resourcePath`, `httpMethod`, `xmlbeansRequestId`*; optional: `requestName` , `endpoint`, `newHttpMethod`, `requestParams`	"Update the endpoint and method of the CreateInvoice request in the Payments API."
`api_method_create`	Creates a new HTTP method on an existing API resource.	`projectName`, `apiName`, `resourcePath`, `httpMethod`	"Add a DELETE method to the /orders resource in the Payments API."
`api_method_delete`	Deletes an HTTP method from an existing API resource.	`projectName`, `apiName`, `resourcePath`, `httpMethod`	"Remove the PUT method from /invoices in the Billing API."
`api_method_update`	Modifies an existing API method - updates the HTTP method on a given resource path. Supports partial updates; returns the updated API info on success or the reason for failure.	`projectName`, `apiName`, `resourcePath`, `httpMethod`	"Change the HTTP method of /pets GET to POST in the Petstore API."
`api_resource_create`	Creates a new resource with a given name and path under an existing API.	`projectName`, `apiName`, `resourcePath`, `resourceName`	"Add a /refunds resource to the Payments API."
`api_resource_delete`	Deletes an existing resource and all its methods from an API	`projectName`, `apiName`, `resourcePath`*	"Delete the /legacy resource from the Billing API."
`api_resource_update`	Renames an existing API resource and updates its path. Supports partial updates; returns the updated API info on success or the reason for failure.	`projectName`, `apiName`, `resourcePath`*; optional: `newResourcePath`, `resourceName`	"Rename the /pets resource to /animals in the Petstore API."
`auth_profile_create`	Creates an Auth Profile under a given project. Supported types: Basic, Digest, NTLM, and AWS Signature. Secret values are write-only and never returned in responses.	`projectName`, `authProfileName`, `authProfileType`*; optional: `properties`, `credentials`	"Create a Basic auth profile called Payments-Auth in the Billing project."
`auth_profile_update`	Modifies an existing Auth Profile's custom properties or type-specific credential fields. Returns updated non-secret profile object on success.	`projectName`, `authProfileName`, `authProfileType`*; optional: `properties`, `credentials`	"Update the API key on the AWS Signature profile in the Payments project."
`auth_profile_delete`	Deletes an Auth Profile from a project.	`projectName`, `authProfileName`	"Delete the Legacy-Auth profile from the Billing project."

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 95. 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 96. 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 has two complementary phases:

Phase 1 - Heal API Definition: When a new spec version arrives, use api_refactor_analyze to identify operation mappings, additions, deletions, and parameter changes, then use api_operation_apply to apply agent-confirmed mutations to the API definition and update the definition URL.
Phase 2 - Heal Test Cases: Once the definition is synced, use analyze_api_impact to identify which existing tests are broken by the changes, then use rest_test_step_update to fix impacted steps.

Run both phases together for a complete healing cycle - API definition synced, tests fixed, and project saved. Four-staged canned prompts wrap the underlying tools into a guided, checkpointed flow - see Staged canned prompts below.

Heal API Definition

API refactor analysis

api_refactor_analyze - Analyzes API definition changes between the current spec stored in ReadyAPI and a new spec version. Wraps ReadyAPI refactoring logic to identify operation mappings with confidence scores, parameter additions, removals, and modifications, unmatched old operations with recommendations, and net-new operations.

Key parameters: project*, apiName*, newSpec*, newSpecSourceType* (URL | FILE | CONTENT)

Try asking your AI client: "Analyze spec changes, propose operation mappings and changes."

API operation application

api_operation_apply - Applies agent-confirmed changes to an API definition. Mutates operations (create, update, or delete) based on agent decisions and updates the project's definition URL to point to the new spec. Supports rollback through an optional backup copy. Returns a full summary of applied and failed changes, warnings, and definition URL update status.

Key parameters: project*, apiName*, newSpecSourceType*, newSpec*, agentConfirmations*; optional: createDefaultRequests (default: true), createBackupCopy (default: true)

Try asking your AI client: "Apply the confirmed changes to the Order Service API and update the definition URL."

Heal Test Cases

Analyze API impact

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.

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 97. 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

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 98. 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 99. 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 100. 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 101. 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 102. 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

Note

3. Manage Assertions

4. Generate Coverage

5. Detect and Heal Change

Heal API Definition

API refactor analysis

API operation application

Heal Test Cases

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

Note

3. Manage Assertions

4. Generate Coverage

5. Detect and Heal Change

Heal API Definition

API refactor analysis

API operation application

Heal Test Cases

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

Supported `newSpecSourceType` values