SmartBear MCP

Sends an open-ended instruction to BearQ's QA lead agent. Use this when no other BearQ tool fits — the QA lead can list, create, and update test cases, manage functional areas, and read the application model, and acts as a general-purpose escape hatch. **Toolset:** Tasks **Parameters:** - instruction (string) *required*: Natural language instruction to send to the BearQ QA lead agent.

Deletes specific BearQ test cases by ID. Deletion is reversible — tests are archived and can be restored. Works on any unprotected test; protected tests are rejected. **Toolset:** Tasks **Parameters:** - testCaseIds (array) *required*: IDs of BearQ test cases to delete.

Explores the live application to discover or update its pages and elements in BearQ's application model. Optionally scope to a single functional area. **Toolset:** Tasks **Parameters:** - functionalArea (union): Functional area to scope the exploration to, by ID or name. Omit to explore the entire application.

Retrieves a task's current state, metadata, and activity log. Returns immediately with whatever's available — does not block on the task completing. **Toolset:** Tasks **Parameters:** - taskId (number) *required*: BearQ task ID.

Retrieves the status of a task (running / complete / error / cancelled). Cheaper than fetching full task details. **Toolset:** Tasks **Parameters:** - taskId (number) *required*: BearQ task ID.

Retrieves a workflow run's current status, per-step progress, and stats (tasks, tests, discovery, ACUs). Returns immediately with whatever's available — does not block on the run completing. **Toolset:** Workflows **Parameters:** - runId (number) *required*: BearQ workflow run ID.

Lists the environments configured in the workspace. Use this to discover valid environment names to pass to the test-running tools, and to identify the workspace default. **Toolset:** Environments **Parameters:** None

无需输入参数。

Lists the workflows in the workspace — each with its id, name, description, steps, and last run. Workspaces with more than 100 workflows are truncated; the response's totalCount says how many exist. **Toolset:** Workflows **Parameters:** None

无需输入参数。

Runs the full BearQ regression suite — every regression-ready test case in the workspace. Use for CI/CD or pre-release smoke. **Toolset:** Tasks **Parameters:** - environment (string): Target environment name to run tests against. Omit to use the workspace default.

Runs specific BearQ regression test cases by ID. Targets only regression-ready cases — drafts will be rejected. **Toolset:** Tasks **Parameters:** - testCaseIds (array) *required*: IDs of BearQ regression test cases to run. - environment (string): Target environment name to run tests against. Omit to use the workspace default.

Runs every regression test case tagged with one or more functional areas. Functional areas can be given by ID or name. **Toolset:** Tasks **Parameters:** - functionalAreas (array) *required*: Functional areas to target, by ID or name. - environment (string): Target environment name to run tests against. Omit to use the workspace default.

Starts a run of a BearQ workflow now and returns the run (id, status, timestamps). If a run of that workflow is already in flight, no new run is started and the in-flight run is returned with started: false. Poll the run's progress with bearq_get_workflow_run. **Toolset:** Workflows **Parameters:** - workflow (string) *required*: Workflow to run: its name (case-insensitive) or its numeric workflow ID.

Cancels a pending or running task, returning { taskId, stopped: true }. The public API accepts a stop of an already-finished task as a success no-op, so this does not guarantee the task was running — check the task's status separately if that matters. **Toolset:** Tasks **Parameters:** - taskId (number) *required*: BearQ task ID to cancel.

Cancels a workflow run that is in flight, returning { runId, cancelled: true }. Fails with an error when the run has already finished or does not exist. **Toolset:** Workflows **Parameters:** - runId (number) *required*: BearQ workflow run ID to cancel.

Blocks until a BearQ task reaches a terminal state (completed / failed / cancelled) or the stream times out, then returns the full ordered sequence of SSE events from the public API (metadata, activityLogEntries, and a terminal done or timeout event) verbatim. Blocks for the lifetime of the task — for a quick check use bearq_get_task_status instead. **Toolset:** Tasks **Parameters:** - taskId (number) *required*: BearQ task ID.

Get more details for a specific build by its ID **Toolset:** Releases **Parameters:** - projectId (string): Unique identifier of the project. This is optional if a current project is set and is used to set the current project for BugSnag tools. - buildId (string) *required*: Unique identifier of the app build **Output Description:** JSON object containing build details along with stability metrics such as user and session stability, and whether it meets project targets **Use Cases:** 1. View build metadata such as version, source control info, and error counts 2. Analyze a specific build to correlate with error spikes or deployments 3. See the stability targets for a project and if the build meets them **Examples:** 1. Get details for a specific build ```json { "buildId": "5f8d0d55c9e77c0017a1b2c3" } ``` Expected Output: JSON object with build details including version, source control info, error counts and stability data. **Hints:** 1. Build IDs can be found using the List builds tool

Retrieve the 'current' project on which tools should operate by default. This allows BugSnag tools to be called with no projectId parameter. **Toolset:** Projects **Parameters:** None **Use Cases:** 1. Understand if a current project has been set **Hints:** 1. If a project is returned, it can be assumed that the user expects interactions with BugSnag tools to refer to this project 2. If this tool returns no current project then other BugSnag tools will require an explicit project ID parameter 3. Call the List Projects tool to see all projects that the user has access to. Get the project ID from this list either by asking the user for the project name or slug 4. You might find a BugSnag API key in the user's code where they configure the BugSnag SDK that can be matched to a project 'apiKey' field from the project list

无需输入参数。

Get full details on an error, including aggregated and summarized data across all events (occurrences) and details of the latest event (occurrence), such as breadcrumbs, metadata and the stacktrace. Use the filters parameter to narrow down the summaries further. **Toolset:** Errors **Parameters:** - projectId (string): Unique identifier of the project. This is optional if a current project is set and is used to set the current project for BugSnag tools. - errorId (string) *required*: Unique identifier of the error to retrieve - filters (record<string, array>): Apply filters to narrow down the error list. Use the List Project Event Filters tool to discover available filter fields. Time filters support extended ISO 8601 format (e.g. 2018-05-20T00:00:00Z) or relative format (e.g. 7d, 24h). (default: {"event.since":[{"type":"eq","value":"30d"}],"error.status":[{"type":"eq","value":"open"}]}) **Output Description:** JSON object containing: - error_details: Aggregated data about the error, including first and last seen occurrence - latest_event: Detailed information about the most recent occurrence of the error, including stacktrace, breadcrumbs, user and context - pivots: List of pivots (summaries) for the error, which can be used to analyze patterns in occurrences - url: A link to the error in the dashboard - this should be shown to the user for them to perform further analysis **Use Cases:** 1. Investigate a specific error found through the List Project Errors tool 2. Understand which types of user are affected by the error using summarized event data 3. Get error details for debugging and root cause analysis 4. Retrieve error metadata for incident reports and documentation **Examples:** 1. Get details for a specific error ```json { "errorId": "6863e2af8c857c0a5023b411" } ``` Expected Output: JSON object with error details including message, stack trace, occurrence count, and metadata **Hints:** 1. Error IDs can be found using the List Project Errors tool 2. U

Get detailed information about a specific event **Toolset:** Events **Parameters:** - projectId (string): Unique identifier of the project. This is optional if a current project is set and is used to set the current project for BugSnag tools. - eventId (string) *required*: Unique identifier of the event **Use Cases:** 1. Get the full details of an event, including any thread stack traces **Examples:** 1. Get event details of an event ```json { "eventId": "6863e2af012caf1d5c320000" } ``` Expected Output: JSON object with complete event details including stack trace (error trace and other threads, if present), metadata, and context

Get detailed information about a specific event using its dashboard URL **Toolset:** Events **Parameters:** - link (string) *required*: Full URL to the event details page in the BugSnag dashboard (web interface), containing project slug and event_id parameter. **Use Cases:** 1. Get event details when given a dashboard URL from a user or notification 2. Extract event information from shared links or browser URLs 3. Quick lookup of event details without needing separate project and event IDs **Examples:** 1. Get event details from a dashboard URL ```json { "link": "https://app.bugsnag.com/my-org/my-project/errors/6863e2af8c857c0a5023b411?event_id=6863e2af012caf1d5c320000" } ``` Expected Output: JSON object with complete event details including stack trace, metadata, and context **Hints:** 1. The URL must contain both project slug in the path and event_id in query parameters 2. This is useful when users share BugSnag dashboard URLs and you need to extract the event data

Gets a list of events that have grouped into the specified error **Toolset:** Events **Parameters:** - projectId (string): Unique identifier of the project. This is optional if a current project is set and is used to set the current project for BugSnag tools. - errorId (string) *required*: Unique identifier of the error - filters (record<string, array>): Apply filters to narrow down the event list. Use the List Project Event Filters tool to discover available filter fields. Time filters support extended ISO 8601 format (e.g. 2018-05-20T00:00:00Z) or relative format (e.g. 7d, 24h). (default: {"event.since":[{"type":"eq","value":"30d"}],"error.status":[{"type":"eq","value":"open"}]}) - direction (enum): Sort direction for ordering results (default: "desc") - perPage (number): How many results to return per page. (default: 30) - nextUrl (string): URL for retrieving the next page of results. Use the value in the previous response to get the next page when more results are available. Only values provided in the output from this tool can be used. Do not attempt to construct it manually. **Use Cases:** 1. Retrieving all the events for comparison to find commonalities or differences in stack traces, breadcrumbs and metadata **Examples:** 1. Get events of an error ```json { "projectId": "1234567890abcdef12345678", "errorId": "6863e2af012caf1d5c320000" } ``` Expected Output: A list of events, ordered by timestamp, with complete details including stack trace, breadcrumbs, metadata, and context

Get the network endpoint grouping rules for a project **Toolset:** Performance **Parameters:** - projectId (string): Unique identifier of the project. This is optional if a current project is set and is used to set the current project for BugSnag tools. **Use Cases:** 1. View current network endpoint grouping configuration 2. Understand how network requests are being grouped in performance monitoring 3. Check grouping patterns before making updates **Examples:** 1. Get network grouping rules for a project ```json {} ``` Expected Output: Array of endpoint URL patterns **Hints:** 1. Network grouping patterns help consolidate similar requests into single span groups 2. Patterns use OpenAPI path templating syntax with curly braces for path parameters (e.g., /users/{userId}) 3. Wildcards (*) can be used in domains to match multiple subdomains (e.g., https://*.example.com)

Get more details for a specific release by its ID, including source control information and associated builds **Toolset:** Releases **Parameters:** - projectId (string): Unique identifier of the project. This is optional if a current project is set and is used to set the current project for BugSnag tools. - releaseId (string) *required*: Unique identifier of the app release **Output Description:** JSON object containing release details along with stability metrics such as user and session stability, and whether it meets project targets **Use Cases:** 1. View release metadata such as version, source control info, and error counts 2. Analyze the stability data and targets for a release 3. See the builds that make up the release **Examples:** 1. Get details for a specific release ```json { "releaseId": "5f8d0d55c9e77c0017a1b2c3" } ``` Expected Output: JSON object with release details including version, source control info, error counts and stability data. **Hints:** 1. Release IDs can be found using the List releases tool

Get detailed performance metrics for a specific span group **Toolset:** Performance **Parameters:** - projectId (string): Unique identifier of the project. This is optional if a current project is set and is used to set the current project for BugSnag tools. - spanGroupId (string) *required*: ID of the span group - filters (record<string, array>): Apply filters to narrow down the span group list. Use the List Trace Fields tool to discover available filter fields. Time filters support extended ISO 8601 format (e.g. 2018-05-20T00:00:00Z) or relative format (e.g. 7d, 24h). (default: {"span.since":[{"type":"eq","value":"7d"}]}) **Use Cases:** 1. View detailed statistics (p50, p75, p90, p95, p99) for an operation 2. Check if performance targets are configured 3. Monitor span count to understand operation volume **Examples:** 1. Get details for an API endpoint span group ```json { "spanGroupId": "[HttpClient]GET-api.example.com" } ``` Expected Output: Statistics, category, and performance target info 2. Get span group details with device filtering ```json { "spanGroupId": "[HttpClient]GET-api.example.com", "filters": { "device.browser_name": [ { "type": "eq", "value": "Chrome" } ] } } ``` Expected Output: Statistics filtered for Chrome browser only **Hints:** 1. Use List Span Groups first to discover available span group IDs 2. IDs are automatically URL-encoded - provide the raw ID 3. Statistics include p50, p75, p90, p95, p99 percentiles

Get all spans within a specific trace **Toolset:** Performance **Parameters:** - projectId (string): Unique identifier of the project. This is optional if a current project is set and is used to set the current project for BugSnag tools. - traceId (string) *required*: Trace ID - from (string) *required*: Start time (ISO 8601 format) - to (string) *required*: End time (ISO 8601 format) - targetSpanId (string): Optional target span ID to focus on - perPage (number): How many results to return per page. (default: 30) - nextUrl (string): URL for retrieving the next page of results. Use the value in the previous response to get the next page when more results are available. Only values provided in the output from this tool can be used. Do not attempt to construct it manually. **Use Cases:** 1. Debug slow requests by viewing all operations in the trace 2. Understand the flow of a request through the system 3. Identify bottlenecks in distributed systems **Examples:** 1. Get all spans for a trace ```json { "traceId": "abc123", "from": "2024-01-01T00:00:00Z", "to": "2024-01-01T23:59:59Z" } ``` Expected Output: Array of all spans in the trace with timing and hierarchy 2. Get spans for a trace with pagination and target span ```json { "traceId": "def456", "from": "2024-01-01T00:00:00Z", "to": "2024-01-01T23:59:59Z", "targetSpanId": "span-789", "perPage": 50 } ``` Expected Output: Array of up to 50 spans focused around the target span **Hints:** 1. Traces show the complete execution path of a request 2. Use from/to parameters to narrow the time window 3. targetSpanId can be used to focus on a specific span in the trace

List and search errors in a project using customizable filters and pagination **Toolset:** Errors **Parameters:** - projectId (string): Unique identifier of the project. This is optional if a current project is set and is used to set the current project for BugSnag tools. - filters (record<string, array>): Apply filters to narrow down the error list. Use the List Project Event Filters tool to discover available filter fields. Time filters support extended ISO 8601 format (e.g. 2018-05-20T00:00:00Z) or relative format (e.g. 7d, 24h). (default: {"event.since":[{"type":"eq","value":"30d"}],"error.status":[{"type":"eq","value":"open"}]}) - sort (enum): Field to sort the errors by (default: "last_seen") - direction (enum): Sort direction for ordering results (default: "desc") - perPage (number): How many results to return per page. (default: 30) - nextUrl (string): URL for retrieving the next page of results. Use the value in the previous response to get the next page when more results are available. Only values provided in the output from this tool can be used. Do not attempt to construct it manually. **Use Cases:** 1. Debug recent application errors by filtering for open errors in the last 7 days 2. Generate error reports for stakeholders by filtering specific error types or severity levels 3. Monitor error trends over time using date range filters 4. Find errors affecting specific users or environments using metadata filters **Examples:** 1. Find errors affecting a specific user in the last 24 hours ```json { "filters": { "user.email": [ { "type": "eq", "value": "[email protected]" } ], "event.since": [ { "type": "eq", "value": "24h" } ] } } ``` Expected Output: JSON object with a list of errors in the 'data' field, a count of the current page of results in the 'count' field, and a total count of all results in the 'total' field 2. Get the 10 open errors with the most users affected in the

Get available event filter fields for a project **Toolset:** Projects **Parameters:** - projectId (string): Unique identifier of the project. This is optional if a current project is set and is used to set the current project for BugSnag tools. **Use Cases:** 1. Discover what filter fields are available before searching for errors 2. Find the correct field names for filtering by user, environment, or custom metadata 3. Understand filter options and data types for building complex queries **Examples:** 1. Get all available filter fields ```json {} ``` Expected Output: JSON array of EventField objects containing display_id, custom flag, and filter/pivot options **Hints:** 1. Use this tool before the List Errors or Get Error tools to understand available filters 2. Look for display_id field in the response - these are the field names to use in filters

List all projects in the organization that the current user has access to, or find a project matching an API key. **Toolset:** Projects **Parameters:** - apiKey (string): The API key of the BugSnag project, if known. **Use Cases:** 1. Get an overview of all projects in the organization 2. Locate a project by its API key if known from the user's code **Hints:** 1. Project IDs from this list can be used with other tools when no project API key is configured

List releases for a project **Toolset:** Releases **Parameters:** - projectId (string): Unique identifier of the project. This is optional if a current project is set and is used to set the current project for BugSnag tools. - releaseStage (string): Filter releases by this stage (e.g. production, staging), defaults to 'production' (default: "production") - visibleOnly (boolean): Whether to only include releases that are marked as visible in the dashboard (default: false) - perPage (number): How many results to return per page. (default: 30) - nextUrl (string): URL for retrieving the next page of results. Use the value in the previous response to get the next page when more results are available. Only values provided in the output from this tool can be used. Do not attempt to construct it manually. **Output Description:** JSON array of release summary objects with metadata, with a URL to the next page if more results are available **Use Cases:** 1. View recent releases to correlate with error spikes 2. Filter releases by stage (e.g. production, staging) for targeted analysis **Examples:** 1. List production releases for a project ```json {} ``` Expected Output: JSON array of release objects in the production stage 2. List staging releases for a project ```json { "releaseStage": "staging" } ``` Expected Output: JSON array of release objects in the staging stage 3. Get the next page of results ```json { "nextUrl": "/projects/515fb9337c1074f6fd000003/releases?offset=30&per_page=30" } ``` Expected Output: JSON array of release objects with metadata from the next page **Hints:** 1. Use the Get Release tool to get more details on a specific release, including the builds it contains 2. The release stage defaults to 'production' if not specified 3. Use visibleOnly to filter out releases that have been marked as hidden in the dashboard

List span groups (operations) tracked for performance monitoring **Toolset:** Performance **Parameters:** - projectId (string): Unique identifier of the project. This is optional if a current project is set and is used to set the current project for BugSnag tools. - sort (enum): Field to sort by - direction (enum): Sort direction for ordering results (default: "desc") - perPage (number): How many results to return per page. (default: 30) - starredOnly (boolean): Show only starred span groups - nextUrl (string): URL for retrieving the next page of results. Use the value in the previous response to get the next page when more results are available. Only values provided in the output from this tool can be used. Do not attempt to construct it manually. - filters (record<string, array>): Apply filters to narrow down the span group list. Use the List Trace Fields tool to discover available filter fields. Time filters support extended ISO 8601 format (e.g. 2018-05-20T00:00:00Z) or relative format (e.g. 7d, 24h). (default: {"span.since":[{"type":"eq","value":"7d"}]}) **Use Cases:** 1. View all operations being tracked for performance 2. Find slow operations by sorting by duration metrics 3. Filter to starred/important span groups **Examples:** 1. List slowest operations ```json { "sort": "duration_p95", "direction": "desc", "perPage": 10 } ``` Expected Output: Array of span groups sorted by 95th percentile duration 2. List starred span groups with filtering ```json { "starredOnly": true, "filters": { "span_group.category": [ { "type": "eq", "value": "full_page_load" } ] } } ``` Expected Output: Array of starred span groups filtered by category **Hints:** 1. Span groups represent different operation types (page loads, API calls, etc.) 2. Use sort by duration_p95 or duration_p99 to find the slowest operations 3. Star important span groups for quick access 4. Use nextUrl for pagination

Get individual spans belonging to a span group **Toolset:** Performance **Parameters:** - projectId (string): Unique identifier of the project. This is optional if a current project is set and is used to set the current project for BugSnag tools. - spanGroupId (string) *required*: ID of the span group - sort (enum): Field to sort by - direction (enum): Sort direction for ordering results (default: "desc") - perPage (number): How many results to return per page. (default: 30) - nextUrl (string): URL for retrieving the next page of results. Use the value in the previous response to get the next page when more results are available. Only values provided in the output from this tool can be used. Do not attempt to construct it manually. - filters (record<string, array>): Apply filters to narrow down the span group list. Use the List Trace Fields tool to discover available filter fields. Time filters support extended ISO 8601 format (e.g. 2018-05-20T00:00:00Z) or relative format (e.g. 7d, 24h). (default: {"span.since":[{"type":"eq","value":"7d"}]}) **Use Cases:** 1. Analyze individual slow operations 2. Debug performance issues by examining specific traces 3. Find patterns in operation attributes **Examples:** 1. Get slowest spans for an operation ```json { "spanGroupId": "[HttpClient]GET-api.example.com", "sort": "duration", "direction": "desc", "perPage": 10 } ``` Expected Output: Array of the 10 slowest span instances 2. Get spans filtered by OS with pagination ```json { "spanGroupId": "[HttpClient]GET-api.example.com", "sort": "timestamp", "filters": { "os.name": [ { "type": "eq", "value": "iOS" } ] }, "nextUrl": "/projects/123/spans?offset=30&per_page=30" } ``` Expected Output: Array of spans from iOS devices with next page navigation **Hints:** 1. Sort by duration descending to find the slowest instances 2. Each span includes trace ID for further investigation

Get available trace fields/attributes for filtering **Toolset:** Performance **Parameters:** - projectId (string): Unique identifier of the project. This is optional if a current project is set and is used to set the current project for BugSnag tools. **Use Cases:** 1. Find available custom attributes for performance filtering 2. Understand what metadata is attached to traces 3. Build dynamic filters based on available fields **Examples:** 1. Get all trace fields ```json {} ``` Expected Output: Array of field names and types available for filtering **Hints:** 1. Trace fields are custom attributes added to spans 2. Use these fields for filtering other performance queries

Set the network endpoint grouping rules for a project **Toolset:** Performance **Parameters:** - projectId (string): Unique identifier of the project. This is optional if a current project is set and is used to set the current project for BugSnag tools. - endpoints (array) *required*: Array of URL patterns by which network spans are grouped. Endpoints follow OpenAPI path templating syntax (https://swagger.io/specification/#path-templating) where path parameters use curly braces (e.g., /users/{id}). If you encounter colon-prefixed parameters (e.g., :userId from Express/React Router), convert them to curly braces (e.g., {userId}). Wildcards (*) can be used in domains (e.g., https://*.example.com) to match multiple subdomains. **Use Cases:** 1. Consolidate similar API endpoints into single span groups 2. Group dynamic URLs using path parameters (e.g., /api/users/{userId} groups /api/users/123, /api/users/456) 3. Match multiple subdomains using wildcards (e.g., https://*.example.com groups api.example.com, cdn.example.com) 4. Simplify performance monitoring by reducing span group clutter **Examples:** 1. Group API endpoints with path parameters ```json { "endpoints": [ "/api/users/{userId}", "/api/products/{productId}", "/api/orders/{orderId}/items/{itemId}" ] } ``` Expected Output: Success response confirming the update 2. Group endpoints with domain wildcards and path parameters ```json { "endpoints": [ "https://*.example.com/api/v1/{resourceId}", "https://api.example.com/v2/users/{userId}", "/graphql" ] } ``` Expected Output: Success response confirming the update 3. Convert colon-prefixed parameters to curly braces (e.g., from Express/React Router) ```json { "endpoints": [ "/{organizationSlug}/{projectSlug}/performance/view-load", "/api/{version}/items/{itemId}" ] } ``` Expected Output: Success response confirming the update **Hints:** 1. Use Get Network Grouping first to see current patterns 2. Use OpenAPI path tem

Update the status of an error **Toolset:** Errors **Parameters:** - projectId (string): Unique identifier of the project. This is optional if a current project is set and is used to set the current project for BugSnag tools. - errorId (string) *required*: Unique identifier of the error - operation (enum) *required*: The operation to apply to the error - issue_url (string): The URL of the issue to link to the error - required when operation is 'link_issue' - reopenRules (object): Reopen rules for snooze operation - required when operation is 'snooze' **Use Cases:** 1. Mark an error as open, fixed or ignored 2. Discard or un-discard an error 3. Update the severity of an error 4. Snooze an error with defined conditions for when it should be reopened **Examples:** 1. Mark an error as fixed ```json { "errorId": "6863e2af8c857c0a5023b411", "operation": "fix" } ``` Expected Output: Success response indicating the error was marked as fixed 2. Snooze an error for 1 hour ```json { "errorId": "6863e2af8c857c0a5023b411", "operation": "snooze", "reopenRules": { "reopenIf": "occurs_after", "seconds": 3600 } } ``` Expected Output: Success response indicating the error was snoozed for 1 hour 3. Snooze an error until 5 additional users are affected ```json { "errorId": "6863e2af8c857c0a5023b411", "operation": "snooze", "reopenRules": { "reopenIf": "n_additional_users", "additionalUsers": 5 } } ``` Expected Output: Success response indicating the error was snoozed until 5 additional users are affected 4. Snooze an error until 10 occurrences in 24 hours ```json { "errorId": "6863e2af8c857c0a5023b411", "operation": "snooze", "reopenRules": { "reopenIf": "n_occurrences_in_m_hours", "occurrences": 10, "hours": 24 } } ``` Expected Output: Success response indicating the error was snoozed until 10 occurrences in 24 hours 5. Link a Jira issue to an error ```json { "errorId": "6863e2af8c857c0a5023b411", "operation": "link_is

Creates a remote system configuration in Collaborator (e.g., Bitbucket, GitHub, etc). **Toolset:** Remote System Configuration Management **Parameters:** - token (string) *required*: Remote system token, e.g., BITBUCKET, GITHUB, etc. - title (string) *required*: Remote system title. - config (string) *required*: JSON string containing configuration parameters for the remote system. - reviewTemplateId (string): Optional review template ID used by this remote system.

Creates a new review in Collaborator. All parameters are optional. **Toolset:** Review Management **Parameters:** - creator (string): Collaborator username of the review creator. Optional. Default: currently logged in user. - title (string): Title of the review. Optional. Default: null. - templateName (string): Review template name. Optional. Default: system default template. - accessPolicy (string): Access policy for the review. Optional. Default: ANYONE.

Deletes a remote system configuration in Collaborator by its ID. **Toolset:** Remote System Configuration Management **Parameters:** - id (union) *required*: ID of the remote system Configuration to delete.

Edits parameters of an existing remote system configuration in Collaborator. Only title and config are editable after creation. **Toolset:** Remote System Configuration Management **Parameters:** - id (string) *required*: ID of the remote system Configuration to edit. - title (string): Remote system title. - config (string): JSON string containing configuration parameters for the remote system. - reviewTemplateId (string): Optional review template ID used by this remote system.

Finds a review in Collaborator by its review ID. **Toolset:** Review Management **Parameters:** - reviewId (string) *required*: The Collaborator review ID to find.

Retrieves reviews from Collaborator using ReviewService.getReviews. All parameters are optional and only provided ones are sent. **Toolset:** Review Management **Parameters:** - login (string): Collaborator username to filter reviews. - role (string): Role to filter reviews (e.g., AUTHOR). - creator (boolean): Whether to filter by creator. - reviewPhase (string): Review phase to filter (e.g., PLANNING). - fullInfo (boolean): Whether to retrieve full review info. - fromDate (string): Minimal creation date in format "yyyy-MM-dd" - toDate (string): Maximal creation date in format "yyyy-MM-dd"

Rejects a review in Collaborator by its review ID and reason. **Toolset:** Review Management **Parameters:** - reviewId (union) *required*: The Collaborator review ID to reject. - reason (string) *required*: Reason for rejecting the review.

Invoke any ReviewService method by name and arguments. For finishReviewPhase and waitOnPhase, provide reviewId (required) and until (optional, defaults to 'ANY'). **Toolset:** Review Management **Parameters:** - action (enum) *required* - args (record<string, any>) *required*

Tests the connection for a remote system configuration in Collaborator by its ID. **Toolset:** Remote System Configuration Management **Parameters:** - id (union) *required*: ID of the remote system Configuration to test connection for.

Updates the webhook for a remote system configuration in Collaborator by its ID. **Toolset:** Remote System Configuration Management **Parameters:** - id (union) *required*: ID of the remote system Configuration to update the webhook for.

Apply a label to a pacticipant. **Toolset:** Labels **Parameters:** - pacticipantName (string) *required*: Name of the pacticipant - labelName (string) *required*: Name of the label

Add a single role to a user (admin). **Toolset:** Admin **Parameters:** - userId (string) *required*: UUID of the user - roleId (string) *required*: UUID of the role

Create a new role with specific permissions (admin). **Toolset:** Admin **Parameters:** - name (string) *required*: Name of the role - permissions (array) *required*: Permissions granted by this role - description (string): Description of the role

Create a new system account (admin). **Toolset:** Admin **Parameters:** - name (string) *required*: Name of the system account

Create a new team (admin). **Toolset:** Admin **Parameters:** - name (string) *required*: Name of the team - administratorUuids (array): UUIDs of team administrators - environmentUuids (array): UUIDs of environments assigned to this team - pacticipantNames (array): Names of pacticipants assigned to this team

Create a new user account (admin). **Toolset:** Admin **Parameters:** - email (string) *required*: Email address of the new user - name (string) *required*: Display name of the new user - firstName (string): First name - lastName (string): Last name - externalIdpId (string): External identity provider ID (for SAML/SSO) - externalIdpUsername (string): External IdP username (for SAML/SSO)

Delete a role (admin). **Toolset:** Admin **Parameters:** - roleId (string) *required*: UUID of the role

Delete a team (admin). **Toolset:** Admin **Parameters:** - teamId (string) *required*: UUID of the team

Delete a user account (admin). **Toolset:** Admin **Parameters:** - userId (string) *required*: UUID of the user

Retrieve details for a specific role by UUID (admin). **Toolset:** Admin **Parameters:** - roleId (string) *required*: UUID of the role

Retrieve API tokens for a system account (admin). **Toolset:** Admin **Parameters:** - accountId (string) *required*: UUID of the system account - pageNumber (number): Page number (default: 1) - pageSize (number): Results per page (default: 5)

Retrieve details for a specific team by UUID (admin). **Toolset:** Admin **Parameters:** - teamId (string) *required*: UUID of the team

Check if a specific user is a member of a team (admin). **Toolset:** Admin **Parameters:** - teamId (string) *required*: UUID of the team - userId (string) *required*: UUID of the user

Retrieve details for a specific user by UUID (admin). **Toolset:** Admin **Parameters:** - userId (string) *required*: UUID of the user

Send invitations to new users (admin). **Toolset:** Admin **Parameters:** - users (array) *required*: List of users to invite

List all available permission scopes (admin). **Toolset:** Admin **Parameters:** - pageNumber (number): Page number (default: 1) - pageSize (number): Results per page (default: 5)

List all roles defined in the workspace (admin). **Toolset:** Admin **Parameters:** - pageNumber (number): Page number (default: 1) - pageSize (number): Results per page (default: 5)

List all users in a specific team (admin). **Toolset:** Admin **Parameters:** - teamId (string) *required*: UUID of the team - pageNumber (number): Page number (default: 1) - pageSize (number): Results per page (default: 5)

List all teams in the workspace (admin). **Toolset:** Admin **Parameters:** - q (string): Filter teams by name - page (number): Page number (default: 1) - size (number): Results per page (default: 5)

List all users in the workspace (admin). **Toolset:** Admin **Parameters:** - active (boolean): Filter by active/inactive status - q (string): Filter by name or email - userType (number): 0 = regular users, 1 = system accounts - page (number): Page number (default: 1) - size (number): Results per page (default: 5)

Add or remove individual users from a team using JSON Patch (admin). **Toolset:** Admin **Parameters:** - teamId (string) *required*: UUID of the team - operations (array) *required*: JSON Patch operations to apply

Remove a single role from a user (admin). **Toolset:** Admin **Parameters:** - userId (string) *required*: UUID of the user - roleId (string) *required*: UUID of the role

Remove a specific user from a team (admin). **Toolset:** Admin **Parameters:** - teamId (string) *required*: UUID of the team - userId (string) *required*: UUID of the user

Reset all roles to their factory defaults (admin). **Toolset:** Admin **Parameters:** None

无需输入参数。

Replace all members of a team (admin). **Toolset:** Admin **Parameters:** - teamId (string) *required*: UUID of the team - uuids (array) *required*: UUIDs of users to set as team members (replaces existing)

Replace all roles assigned to a user (admin). **Toolset:** Admin **Parameters:** - userId (string) *required*: UUID of the user - roles (array) *required*: Array of role UUIDs to assign

Update an existing role's name and permissions (admin). **Toolset:** Admin **Parameters:** - roleId (string) *required*: UUID of the role to update - name (string) *required*: Name of the role - permissions (array) *required*: Permissions granted by this role - description (string): Description of the role

Replace a team's configuration (admin). **Toolset:** Admin **Parameters:** - teamId (string) *required*: UUID of the team to update - name (string) *required*: Name of the team - administratorUuids (array): UUIDs of team administrators - environmentUuids (array): UUIDs of environments assigned to this team - pacticipantNames (array): Names of pacticipants assigned to this team

Update a user's profile or active status (admin). **Toolset:** Admin **Parameters:** - userId (string) *required*: UUID of the user to update - active (boolean): Whether the user is active - email (string): New email address - firstName (string): First name - lastName (string): Last name - name (string): Display name

Performs a comprehensive compatibility check to determine whether a specific version of a service (pacticipant) can be safely deployed into a given environment. It analyzes the complete contract matrix of consumer-provider relationships to confirm that all required integrations are verified and compatible. **Toolset:** Can I Deploy **Parameters:** - pacticipant (string) *required*: The name of the pacticipant (application/service) being evaluated for deployment - version (string) *required*: The version of the pacticipant that you want to check if it's safe to deploy - environment (string) *required*: The target environment where the pacticipant version will be deployed (e.g., 'production', 'staging', 'test')

Check your PactFlow AI entitlements and credit balance if you encounter 401 Unauthorized errors or permission/credit issues when using PactFlow AI features. **Toolset:** PactFlow AI Status **Use Cases:** 1. Diagnose 401 unauthorized errors when attempting to use PactFlow AI features 2. Check remaining AI credits when PactFlow AI operations are rejected due to insufficient credits 3. Verify account entitlements when users receive permission denied errors for PactFlow AI functionality 4. Troubleshoot PactFlow AI access issues by retrieving current entitlement status and credit balance 5. Provide detailed error context when PactFlow AI features are unavailable due to account limitations

无需输入参数。

Create a new deployment environment in PactFlow. **Toolset:** Environments and Deployments **Parameters:** - name (string) *required*: Unique name for the environment (e.g. 'production', 'staging') - production (boolean) *required*: Whether this is a production environment - displayName (string): Human-readable display name - teamUuids (array): UUIDs of teams that own this environment

Register a new application/service (pacticipant) in the workspace. **Toolset:** Pacticipants **Parameters:** - name (string) *required*: Name of the pacticipant (cannot be changed after creation) - displayName (string): Human-readable display name - mainBranch (string): Name of the main/trunk branch (e.g. 'main') - repositoryName (string): Repository name - repositoryNamespace (string): Repository namespace/organisation - repositoryUrl (string): URL of the source repository

Create a new secret for use in webhook authentication. **Toolset:** Secrets **Parameters:** - name (string) *required*: Name of the secret - value (string) *required*: Value of the secret - description (string): Description of the secret - teamUuid (string): UUID of the owning team (cannot be changed after creation)

Create a new webhook to trigger on contract events. **Toolset:** Webhooks **Parameters:** - description (string) *required*: Human-readable description of the webhook - events (array) *required*: Events that trigger this webhook - request (object) *required*: HTTP request to send when triggered - consumer (object): Restrict to a specific consumer (omit for all) - provider (object): Restrict to a specific provider (omit for all) - enabled (boolean): Whether the webhook is enabled (default: true) - teamUuid (string): UUID of the owning team (null for global)

Delete ALL consumer-provider integrations in the workspace. **Toolset:** Integrations and Network **Parameters:** None

无需输入参数。

Delete a branch from a pacticipant. **Toolset:** Branches and Versions **Parameters:** - pacticipantName (string) *required*: Name of the pacticipant - branchName (string) *required*: Name of the branch to delete

Delete an environment by UUID. **Toolset:** Environments and Deployments **Parameters:** - environmentId (string) *required*: UUID of the environment

Delete a specific consumer-provider integration. **Toolset:** Integrations and Network **Parameters:** - providerName (string) *required*: Name of the provider - consumerName (string) *required*: Name of the consumer

Delete a pacticipant and all its associated data. **Toolset:** Pacticipants **Parameters:** - pacticipantName (string) *required*: Name of the pacticipant to delete

Delete a secret by UUID. **Toolset:** Secrets **Parameters:** - secretId (string) *required*: UUID of the secret

Delete a webhook by UUID. **Toolset:** Webhooks **Parameters:** - webhookId (string) *required*: UUID of the webhook

Trigger a test execution of a specific webhook. **Toolset:** Webhooks **Parameters:** - webhookId (string) *required*: UUID of the webhook

Generate Pact tests using PactFlow AI. You can provide one or more of the following input types: (1) request/response pairs for specific interactions, (2) code files to analyze and extract interactions from, and/or (3) OpenAPI document to generate tests for specific endpoints. When providing an OpenAPI document, a matcher is required to specify which endpoints to generate tests for. **Toolset:** Generate Pact Tests **Parameters:** - language (enum): Target language for the generated Pact tests. If not provided, will be inferred from other inputs. - requestResponse (object): Direct request/response pair for a specific interaction. Use this when you have concrete examples of API requests and responses - code (array): Collection of source code files to analyze and extract API interactions from. Include client code, data models, existing tests, or any code that makes API calls - openapi (any) - additionalInstructions (string): Optional free-form instructions to guide the generation process (e.g., 'Focus on error scenarios', 'Include authentication headers', 'Use specific test framework patterns') - testTemplate (object): Optional test template to use as a basis for generation. Helps ensure generated tests follow your specific patterns, frameworks, and coding standards

Retrieve the audit log of events in the workspace. **Toolset:** Audit **Parameters:** - since (string): Only include events at or after this ISO 8601 timestamp - userUuid (string): Filter events by PactFlow user UUID - type (string): Filter events by type (e.g. 'pact_publication') - sort (string): Sort order: '+timestamp' (asc, default) or '-timestamp' (desc) - from (string): Start result set from this audit event UUID (keyset pagination) - pageNumber (number): Page number (default: 1) - pageSize (number): Results per page (max 100) (default: 5) **Use Cases:** 1. Review recent changes to pacticipants, webhooks, or secrets 2. Investigate who published a specific pact or verification 3. Filter events by user or event type for compliance reporting 4. Track deployment recording activity across environments

Fetch the consumer Pact contract for a specific consumer-provider version pair in Bi-Directional Contract Testing. **Toolset:** Bi-Directional Contract Testing **Parameters:** - providerName (string) *required*: Name of the provider - providerVersionNumber (string) *required*: Provider version number - consumerName (string) *required*: Name of the consumer - consumerVersionNumber (string) *required*: Consumer version number - pageNumber (number): Page number (default: 1) - pageSize (number): Results per page (default: 5)

Fetch the consumer contract verification results for a given provider version in Bi-Directional Contract Testing. **Toolset:** Bi-Directional Contract Testing **Parameters:** - providerName (string) *required*: Name of the provider - providerVersionNumber (string) *required*: Provider version number - pageNumber (number): Page number (default: 1) - pageSize (number): Results per page (default: 5)

Fetch all consumer Pact contracts relevant to a given provider version in Bi-Directional Contract Testing. **Toolset:** Bi-Directional Contract Testing **Parameters:** - providerName (string) *required*: Name of the provider - providerVersionNumber (string) *required*: Provider version number - pageNumber (number): Page number (default: 1) - pageSize (number): Results per page (default: 5)

Fetch the consumer contract verification results for a specific consumer-provider version pair in Bi-Directional Contract Testing. **Toolset:** Bi-Directional Contract Testing **Parameters:** - providerName (string) *required*: Name of the provider - providerVersionNumber (string) *required*: Provider version number - consumerName (string) *required*: Name of the consumer - consumerVersionNumber (string) *required*: Consumer version number - pageNumber (number): Page number (default: 1) - pageSize (number): Results per page (default: 5)

Fetch the cross-contract verification results for a given provider version in Bi-Directional Contract Testing. **Toolset:** Bi-Directional Contract Testing **Parameters:** - providerName (string) *required*: Name of the provider - providerVersionNumber (string) *required*: Provider version number - pageNumber (number): Page number (default: 1) - pageSize (number): Results per page (default: 5)

Fetch the provider OpenAPI contract for a specific consumer-provider version pair in Bi-Directional Contract Testing. **Toolset:** Bi-Directional Contract Testing **Parameters:** - providerName (string) *required*: Name of the provider - providerVersionNumber (string) *required*: Provider version number - consumerName (string) *required*: Name of the consumer - consumerVersionNumber (string) *required*: Consumer version number - pageNumber (number): Page number (default: 1) - pageSize (number): Results per page (default: 5)

Fetch the provider contract self-verification results for a specific consumer-provider version pair in Bi-Directional Contract Testing. **Toolset:** Bi-Directional Contract Testing **Parameters:** - providerName (string) *required*: Name of the provider - providerVersionNumber (string) *required*: Provider version number - consumerName (string) *required*: Name of the consumer - consumerVersionNumber (string) *required*: Consumer version number - pageNumber (number): Page number (default: 1) - pageSize (number): Results per page (default: 5)

Fetch the provider OpenAPI contract for a given provider version in Bi-Directional Contract Testing. **Toolset:** Bi-Directional Contract Testing **Parameters:** - providerName (string) *required*: Name of the provider - providerVersionNumber (string) *required*: Provider version number - pageNumber (number): Page number (default: 1) - pageSize (number): Results per page (default: 5)

Fetch the self-verification results for a provider contract version in Bi-Directional Contract Testing. **Toolset:** Bi-Directional Contract Testing **Parameters:** - providerName (string) *required*: Name of the provider - providerVersionNumber (string) *required*: Provider version number - pageNumber (number): Page number (default: 1) - pageSize (number): Results per page (default: 5)

Fetch the cross-contract verification results for a specific consumer-provider version pair in Bi-Directional Contract Testing. **Toolset:** Bi-Directional Contract Testing **Parameters:** - providerName (string) *required*: Name of the provider - providerVersionNumber (string) *required*: Provider version number - consumerName (string) *required*: Name of the consumer - consumerVersionNumber (string) *required*: Consumer version number - pageNumber (number): Page number (default: 1) - pageSize (number): Results per page (default: 5)

Retrieve details for a specific branch of a pacticipant. **Toolset:** Branches and Versions **Parameters:** - pacticipantName (string) *required*: Name of the pacticipant - branchName (string) *required*: Name of the branch

Retrieve all versions published from a specific branch of a pacticipant. **Toolset:** Branches and Versions **Parameters:** - pacticipantName (string) *required*: Name of the pacticipant - branchName (string) *required*: Name of the branch - pageNumber (number): Page number (default: 1) - pageSize (number): Results per page (default: 5)

Retrieve the profile of the currently authenticated user. **Toolset:** User, Tokens and Preferences **Parameters:** None

无需输入参数。

Retrieve all versions currently deployed to a given environment. **Toolset:** Environments and Deployments **Parameters:** - environmentId (string) *required*: UUID of the environment - pageNumber (number): Page number (default: 1) - pageSize (number): Results per page (default: 5)

Retrieve all versions currently released and supported in a given environment. **Toolset:** Environments and Deployments **Parameters:** - environmentId (string) *required*: UUID of the environment - pageNumber (number): Page number (default: 1) - pageSize (number): Results per page (default: 5)

Retrieve deployment records for a specific pacticipant version in a specific environment. **Toolset:** Environments and Deployments **Parameters:** - pacticipantName (string) *required*: Name of the pacticipant - versionNumber (string) *required*: Version number - environmentId (string) *required*: UUID of the environment - pageNumber (number): Page number (default: 1) - pageSize (number): Results per page (default: 5)

Retrieve details for a specific environment by UUID. **Toolset:** Environments and Deployments **Parameters:** - environmentId (string) *required*: UUID of the environment

Retrieve all consumer-provider integrations belonging to a specific team. **Toolset:** Integrations and Network **Parameters:** - teamId (string) *required*: UUID of the team - pageNumber (number): Page number (default: 1) - pageSize (number): Results per page (default: 5)

Retrieve the latest version of a pacticipant, optionally filtered by tag. **Toolset:** Branches and Versions **Parameters:** - pacticipantName (string) *required*: Name of the pacticipant - tag (string): Tag to filter by. If omitted, returns the overall latest version.

Fetch metrics across the entire workspace **Toolset:** Metrics **Parameters:** None

无需输入参数。

Retrieve details for a specific pacticipant by name. **Toolset:** Pacticipants **Parameters:** - pacticipantName (string) *required*: Name of the pacticipant (application or service)

Check whether a specific label is applied to a pacticipant. **Toolset:** Labels **Parameters:** - pacticipantName (string) *required*: Name of the pacticipant - labelName (string) *required*: Name of the label

Retrieve the integration network graph for a specific pacticipant. **Toolset:** Integrations and Network **Parameters:** - pacticipantName (string) *required*: Name of the pacticipant to get network for - pageNumber (number): Page number (default: 1) - pageSize (number): Results per page (default: 5)

Retrieve details for a specific version of a pacticipant. **Toolset:** Branches and Versions **Parameters:** - pacticipantName (string) *required*: Name of the pacticipant - versionNumber (string) *required*: Version number to retrieve

Retrieve the pacts that a provider should verify, based on consumer version selectors and WIP/pending pact configuration. **Toolset:** Contracts **Parameters:** - providerName (string) *required*: Name of the provider to get pacts for - consumerVersionSelectors (array): Selectors specifying which consumer versions to include - includePendingStatus (boolean): Include the pending status in the results - includeWipPactsSince (string): Include WIP pacts published since this date (ISO 8601) - providerVersionBranch (string): Branch of the provider version being verified - providerVersionTags (array): Tags for the provider version being verified

Retrieve the states of a specific provider **Toolset:** Fetch Provider States **Parameters:** - provider (string) *required*: name of the provider to retrieve states for - pageNumber (number): Page number (default: 1) - pageSize (number): Results per page (default: 5)

Retrieve release records for a specific pacticipant version in a specific environment. **Toolset:** Environments and Deployments **Parameters:** - pacticipantName (string) *required*: Name of the pacticipant - versionNumber (string) *required*: Version number - environmentId (string) *required*: UUID of the environment - pageNumber (number): Page number (default: 1) - pageSize (number): Results per page (default: 5)

Retrieve metadata for a specific secret by UUID. **Toolset:** Secrets **Parameters:** - secretId (string) *required*: UUID of the secret

Retrieve system-wide preferences. **Toolset:** User, Tokens and Preferences **Parameters:** None

无需输入参数。

Fetch metrics for all teams **Toolset:** Metrics **Parameters:** None

无需输入参数。

Retrieve the current user's preferences. **Toolset:** User, Tokens and Preferences **Parameters:** None

无需输入参数。

Retrieve details for a specific webhook by UUID. **Toolset:** Webhooks **Parameters:** - webhookId (string) *required*: UUID of the webhook

Retrieve API tokens for the current user. **Toolset:** User, Tokens and Preferences **Parameters:** - pageNumber (number): Page number (default: 1) - pageSize (number): Results per page (default: 5)

Retrieve all branches for a given pacticipant, with optional filtering and pagination. **Toolset:** Branches and Versions **Parameters:** - pacticipantName (string) *required*: Name of the pacticipant - q (string): Filter branches by name - pageNumber (number): Page number (default: 1) - pageSize (number): Results per page (default: 5)

Retrieve all versions of a pacticipant that have ever been deployed or released. **Toolset:** Environments and Deployments **Parameters:** - pacticipantName (string) *required*: Name of the pacticipant - pageNumber (number): Page number (default: 1) - pageSize (number): Results per page (default: 5)

Retrieve the versions of a pacticipant associated with a given environment. **Toolset:** Environments and Deployments **Parameters:** - pacticipantName (string) *required*: Name of the pacticipant - pageNumber (number): Page number (default: 1) - pageSize (number): Results per page (default: 5) - environmentId (string) *required*: UUID of the environment

Retrieve all environments configured in the Pact Broker or PactFlow workspace. **Toolset:** Environments and Deployments **Parameters:** - pageNumber (number): Page number (default: 1) - pageSize (number): Results per page (default: 5)

Retrieve all consumer-provider integrations registered in the workspace. **Toolset:** Integrations and Network **Parameters:** - pageNumber (number): Page number (default: 1) - pageSize (number): Results per page (default: 5)

Retrieve all labels used across the workspace. **Toolset:** Labels **Parameters:** - pageNumber (number): Page number (default: 1) - pageSize (number): Results per page (default: 5)

Retrieve all versions for a given pacticipant. **Toolset:** Branches and Versions **Parameters:** - pacticipantName (string) *required*: Name of the pacticipant - pageNumber (number): Page number (default: 1) - pageSize (number): Results per page (default: 5)

Retrieve all pacticipants (applications/services) registered in the Pact Broker or PactFlow workspace. **Toolset:** Pacticipants **Parameters:** - pageNumber (number): Page number (default: 1) - pageSize (number): Number of results per page (default: 5)

Retrieve all pacticipants that have a specific label applied. **Toolset:** Labels **Parameters:** - labelName (string) *required*: Label name to filter by - pageNumber (number): Page number (default: 1) - pageSize (number): Results per page (default: 5)

Retrieve all secrets stored in the workspace. **Toolset:** Secrets **Parameters:** - pageNumber (number): Page number (default: 1) - pageSize (number): Results per page (default: 5)

Retrieve all webhooks configured in the workspace. **Toolset:** Webhooks **Parameters:** - pageNumber (number): Page number (default: 1) - pageSize (number): Results per page (default: 5)

Retrieve the comprehensive contract verification matrix that shows the relationship between consumer and provider versions, their associated pact files, and verification results stored in the Pact Broker or Pactflow. The matrix provides detailed visibility into which consumer and provider versions have been successfully verified against each other, and highlights failures with detailed information about the cause. **Toolset:** Matrix **Parameters:** - latestby (string): This property removes the rows for the overridden pacts/verifications from the results. The options are cvp (show only the latest row for each consumer version and provider) and cvpv (show only the latest row each consumer version and provider version). For a can-i-deploy query with one selector, it should be set to cvp. For a can-i-deploy query with two selectors, it should be set to cvpv. - limit (number): The limit on the number of results to return (1-1000, default: 100) (default: 100) - q (array) *required* **Use Cases:** 1. Quickly identify which consumer and provider version combinations have passed or failed verification. 2. Diagnose and investigate why a particular consumer-provider verification failed. 3. Visualize the overall contract compatibility across two pacticipants / services. 4. Perform advanced queries using selectors to understand compatibility within specific branches, environments, or version ranges. 5. Support informed deployment decisions by answering 'can I deploy version X of this service to production?' 6. Expose contract verification details to non-frequent API users in a more accessible format.

Partially update a pacticipant's metadata — only fields provided are changed. **Toolset:** Pacticipants **Parameters:** - pacticipantName (string) *required*: Name of the pacticipant to update - displayName (string): Human-readable display name - mainBranch (string): Name of the main/trunk branch (e.g. 'main') - repositoryName (string): Repository name - repositoryNamespace (string): Repository namespace/organisation - repositoryUrl (string): URL of the source repository

Publish one or more consumer Pact contracts to the Pact Broker or PactFlow, with branch and tag metadata. **Toolset:** Contracts **Parameters:** - pacticipantName (string) *required*: Name of the consumer application - pacticipantVersionNumber (string) *required*: Version number of the consumer - contracts (array) *required*: Contracts to publish - tags (array): Version tags (e.g. 'main', 'staging') - branch (string): Branch name of the consumer - buildUrl (string): URL of the CI build that produced these contracts

Publish a provider OpenAPI or AsyncAPI contract and self-verification results to PactFlow (Bi-Directional Contract Testing). **Toolset:** Contracts **Parameters:** - providerName (string) *required*: Name of the provider application - pacticipantVersionNumber (string) *required*: Version number of the provider - contract (object) *required*: Provider contract (OpenAPI or AsyncAPI spec) and verification details - tags (array): Version tags - branch (string): Branch name of the provider - buildUrl (string): URL of the CI build

Record that a version of a pacticipant has been deployed to an environment. **Toolset:** Environments and Deployments **Parameters:** - pacticipantName (string) *required*: Name of the pacticipant that was deployed - versionNumber (string) *required*: Version number that was deployed - environmentId (string) *required*: UUID of the target environment - applicationInstance (string): Identifies a specific instance when multiple instances of the same application are deployed to the same environment (e.g. 'blue', 'green')

Record that a version of a pacticipant has been released to an environment (for mobile/library release workflows). **Toolset:** Environments and Deployments **Parameters:** - pacticipantName (string) *required*: Name of the pacticipant that was released - versionNumber (string) *required*: Version number that was released - environmentId (string) *required*: UUID of the target environment

Regenerate (rotate) an API token by ID. **Toolset:** User, Tokens and Preferences **Parameters:** - tokenId (string) *required*: ID of the token to regenerate

Remove a label from a pacticipant. **Toolset:** Labels **Parameters:** - pacticipantName (string) *required*: Name of the pacticipant - labelName (string) *required*: Name of the label

Review Pact tests using PactFlow AI. You can provide the following inputs: (1) Pact tests to be reviewed along with metadata **Toolset:** Review Pact Tests **Parameters:** - pactTests (object) *required*: Primary pact tests that needs to be refined. - code (array): Collection of source code files to analyze and extract API interactions from. Include client code, data models, existing tests, or any code that makes API calls - userInstructions (string): Optional free-form instructions that provide additional context or specify areas of focus during the refinement process of the Pact test. - errorMessages (array): Optional error output from failed contract test runs. These can be used to better understand the context or failures observed and guide the recommendations toward resolving specific issues. - openapi (any)

Trigger a test execution of all matching webhooks without a real event. **Toolset:** Webhooks **Parameters:** None

无需输入参数。

Update an existing environment's metadata. **Toolset:** Environments and Deployments **Parameters:** - environmentId (string) *required*: UUID of the environment to update - name (string) *required*: Unique name for the environment - production (boolean) *required*: Whether this is a production environment - displayName (string): Human-readable display name - teamUuids (array): UUIDs of teams that own this environment

Fully replace a pacticipant's metadata (display name, main branch, repository URL, etc.). **Toolset:** Pacticipants **Parameters:** - pacticipantName (string) *required*: Name of the pacticipant to update - displayName (string): Human-readable display name - mainBranch (string): Name of the main/trunk branch (e.g. 'main') - repositoryName (string): Repository name - repositoryNamespace (string): Repository namespace/organisation - repositoryUrl (string): URL of the source repository

Update metadata for a specific pacticipant version. **Toolset:** Branches and Versions **Parameters:** - pacticipantName (string) *required*: Name of the pacticipant - versionNumber (string) *required*: Version number to update - buildUrl (string): URL of the CI build that produced this version

Update an existing secret's name, value, or description. **Toolset:** Secrets **Parameters:** - secretId (string) *required*: UUID of the secret to update - name (string): New name for the secret - value (string): New value for the secret - description (string): New description

Update an existing webhook's configuration. **Toolset:** Webhooks **Parameters:** - webhookId (string) *required*: UUID of the webhook to update - description (string): Human-readable description - events (array): Events that trigger this webhook - request (object): HTTP request to send when triggered - consumer (object): Restrict to a specific consumer - provider (object): Restrict to a specific provider - enabled (boolean): Whether the webhook is enabled - teamUuid (string): UUID of the owning team

Update execution status for individual or multiple test case runs in bulk, enforcing mandatory Test Run UDFs **Toolset:** Test Suites **Parameters:** - projectKey (string): Project key - unique identifier for the project (default: "default") - entityIDs (string) *required*: Comma-separated IDs of Test Case Runs to update. CRITICAL: the parameter name is 'entityIDs' — do NOT use 'tcRunIDs', 'testCaseRunIds', 'runIds', or other variants. Accepts a number or string (e.g., 66095087 or '66095087' for single, '66095069,66095075' for bulk). To get the entityIDs - Call API 'Execution/Fetch Testcase Run ID'. From the response, get value -> data[<index>].tcRunID - entityType (enum): Type of Entity to Execute: 'TCR' (Test Case Run) or 'TCSR' (Test Case Step Run) (default: "TCR") - qmTsRunId (string) *required*: Id of Test Suite Run to execute (required). CRITICAL: the parameter name is 'qmTsRunId' — do NOT use 'tsrunID', 'testSuiteRunId', 'tsRunID', or other variants. Accepts a number or string. To get the qmTsRunId - Call API 'Execution/Fetch Executions'. From the response, get value -> data[<index>].tsRunID - runStatusID (number) *required*: Id of the execution status to set (required). To get the runStatusID - Call API 'Admin/Project GET info Service' From the response, get value of following attribute -> allstatus[<index>].id Common statuses: Pass, Fail, Not Run, Blocked, WIP, etc. - dropID (union): Unique identifier of drop/build on which execution is to be performed (optional). To get the dropID - Call API 'Fetch Build/List' From the response, get value of following attribute -> data[<index>].dropID - isAutoExecuted (enum): Set '1' for automated and '0' for manual Execution Type - isBulkOperation (boolean): Set true for bulk operations (multiple entityIDs), false for single execution update. Default: true if multiple comma-separated entityIDs, false otherwise - comments (string): Optional comments for the execution status update - username (string): If Part 11 Complian

Bulk update User Defined Field (UDF) values for one or more Test Case Runs in a test execution. Runs asynchronously in the background. **Toolset:** UDF **Parameters:** - projectKey (string): Project key - unique identifier for the project (default: "default") - tcRunIDs (array) *required*: Array of Test Case Run IDs to update UDF values for. To get tcRunIDs — Call 'Fetch Test Case Runs by Test Suite Run' tool. From the response, get value of data[<index>].tcRunID. Example: [41572006, 41572009, 41572013] - UDF (record<string, object>) *required*: Object mapping UDF field names to their new values. Each key is the UDF field name (e.g. 'test_env', 'priority_field'). Each value is an object with fieldID and value (and optionally multiSelectAction for multi-select fields). All UDF fields are optional — include only the fields you want to update. **Output Description:** JSON object with success status, code 'CO.BULK_TC_EXECUTION_UDF_UPDATE_STARTED', and message confirming the background job was queued. **Use Cases:** 1. Bulk update a string UDF (e.g. build version, environment name) for multiple test runs 2. Set a date UDF field (e.g. execution date) across multiple test case runs 3. Update a numeric UDF field (e.g. story points, priority score) in bulk 4. Set a single-select lookup UDF to a new value for multiple runs 5. Append new values to a multi-select UDF field across multiple test runs 6. Replace all existing selections in a multi-select UDF with new values 7. Update a cascading list UDF (parent + child) for multiple test runs 8. Update multiple UDF fields of different types in a single bulk operation 9. Reset a UDF field value for all runs in a test suite execution 10. Sync automated test result metadata (environment, build, platform) into UDF fields after execution **Examples:** 1. Bulk update a STRING UDF for multiple test runs ```json { "tcRunIDs": [ 41572006, 41572009, 41572013 ], "UDF": { "8190_String": { "fieldID": 229241,

Create a new cycle within an existing release in QMetry for test execution planning **Toolset:** Projects **Parameters:** - projectKey (string): Project key - unique identifier for the project (default: "default") - cycle (object) *required* **Output Description:** JSON object containing the created cycle ID, cycle details, and association with the release **Use Cases:** 1. Create a new test cycle for a sprint within an existing release 2. Add additional testing phases to an existing release 3. Set up regression testing cycles for a specific release 4. Organize test execution by sprints, phases, or iterations 5. Create cycles with specific date ranges for milestone tracking 6. Establish test execution phases within release planning **Examples:** 1. Create a basic cycle with just a name in a release ```json { "cycle": { "name": "Sprint 2", "releaseID": 12345 } } ``` Expected Output: Cycle 'Sprint 2' created successfully in release ID 12345 2. Create a cycle with description and dates ```json { "cycle": { "name": "Regression Testing Cycle", "description": "Full regression testing for release 2.0", "startDate": "15-01-2024", "targetDate": "31-01-2024", "releaseID": 12345 } } ``` Expected Output: Cycle 'Regression Testing Cycle' created with start date 15-01-2024 and target date 31-01-2024 in release 12345 3. Create a locked cycle to prevent modifications ```json { "cycle": { "name": "Final QA Cycle", "description": "Locked cycle for final QA testing", "isLocked": true, "isArchived": false, "releaseID": 12345 } } ``` Expected Output: Locked cycle 'Final QA Cycle' created in release 12345 to prevent modifications 4. Create a cycle with all details including project ID and dates ```json { "cycle": { "name": "Sprint 3 - Feature Testing", "description": "Testing new features for Sprint 3", "startDate": "01-02-2024", "targetDate": "15-02-2024", "isLocked": false, "isArchived": false

Create a new defect/issue internally in QMetry. **Toolset:** Issues **Parameters:** - projectKey (string): Project key - unique identifier for the project (default: "default") - issueType (number) *required*: Issue type ID (e.g. Bug, Enhancement, etc.) - issuePriority (number) *required*: Issue priority ID (e.g. High, Medium, Low, etc.) - summary (string) *required*: Summary or title of the defect/issue - description (string): Detailed description of the defect/issue - sync_with (string): External system to sync with (e.g. JIRA, QMetry, etc.) - issueOwner (number): Owner/user ID for the issue - component (array): Component IDs associated with the issue - affectedRelease (array): Release IDs affected by this issue - affectedCycles (array): Cycle IDs affected by this issue - tcRunID (number): Test Case Run ID to link this defect/issue to a test execution (optional) - environment (string): Environment where the issue was found (e.g. 'Chrome', 'Firefox', 'Production'). Free-text string — no ID lookup needed. - issueState (number): Issue status ID. Optional by default — QMetry allows admins to make this mandatory at the project level. Get valid IDs from project info → customListObjs.issueState[index].id. Common values: Open, Reopened, Resolved, Closed. - udfFields (record<string, union>): Flat UDF field values. Keys = UDF field names from 'Fetch UDF Layout'. Values depend on fieldTypeName: STRING/LARGETEXT: string, NUMBER: number, DATETIMEPICKER: date string ('14-08-2026'), LOOKUPLIST: numeric ID, MULTILOOKUPLIST: array of IDs [101, 102], CASCADINGLIST: { parent: 101, child: 102 }. Call 'Fetch UDF Layout' with entityType + pageName='ADD' to discover available fields and list option IDs. **Output Description:** JSON object containing the new create issue with id, dfid(defectID). **Use Cases:** 1. Create a basic defect/issue with just a summary 2. Set issueType, issueOwner, component (labels), environment, and affectedRelease using valid IDs from project info 3. Create

Create a new release in QMetry with optional cycle for test planning and execution tracking **Toolset:** Projects **Parameters:** - projectKey (string): Project key - unique identifier for the project (default: "default") - release (object) *required* - cycle (object): Optional cycle to create within the release **Output Description:** JSON object containing the created release ID, release details, and cycle information if provided **Use Cases:** 1. Create a new release for a major product version (e.g., v2.0, Q1 Release) 2. Create a release with an initial cycle for immediate test planning 3. Set up release dates for sprint planning and milestone tracking 4. Organize test execution by product versions and cycles 5. Create release hierarchy for better test planning and reporting 6. Establish test execution phases with releases and cycles **Examples:** 1. Create a basic release with just a name ```json { "release": { "name": "Release 2.0" } } ``` Expected Output: Release 'Release 2.0' created successfully with generated release ID 2. Create a release with description and dates ```json { "release": { "name": "Q1 2024 Release", "description": "First quarter release for 2024", "startDate": "01-01-2024", "targetDate": "31-03-2024" } } ``` Expected Output: Release 'Q1 2024 Release' created with start date 01-01-2024 and target date 31-03-2024 3. Create a release with an initial cycle ```json { "release": { "name": "Release 3.0", "description": "Major product update" }, "cycle": { "name": "Sprint 1", "isLocked": false, "isArchived": false } } ``` Expected Output: Release 'Release 3.0' created with cycle 'Sprint 1' for test execution planning 4. Create a release with all details ```json { "release": { "name": "Summer 2024 Release", "description": "Summer product release with new features", "startDate": "01-06-2024", "targetDate": "31-08-2024" }, "cycle": { "name": "Beta Testing Cycle",

Create a new requirement in QMetry with metadata and release/cycle mapping. **Toolset:** Requirements **Parameters:** - name (string) *required*: Requirement name (required). - priority (number): Priority ID of the requirement. - component (array): Component (Label) IDs associated with the requirement. - requirementOwner (number): Owner ID of the requirement. - requirementState (number): State ID of the requirement. - releaseCycleMapping (array): Release/cycle mapping for the requirement. - description (string): Description of the requirement. - associateRelCyc (boolean): Whether to associate the release/cycle mapping. - rqFolderId (string): Requirement folder ID - SYSTEM AUTOMATICALLY RESOLVES THIS. Leave empty unless you have a specific folder ID. System will fetch project info using the projectKey and extract rootFolders.RQ.id automatically. Manual folder ID only needed if you want to target a specific sub-folder. - scope (string): Scope of the requirement, usually 'project'. (default: "project") - udfFields (record<string, union>): Flat UDF field values. Keys = UDF field names from 'Fetch UDF Layout'. Values depend on fieldTypeName: STRING/LARGETEXT: string, NUMBER: number, DATETIMEPICKER: date string ('14-08-2026'), LOOKUPLIST: numeric ID, MULTILOOKUPLIST: array of IDs [101, 102], CASCADINGLIST: { parent: 101, child: 102 }. Call 'Fetch UDF Layout' with entityType + pageName='ADD' to discover available fields and list option IDs. **Output Description:** JSON object containing the new requirement ID, summary, and creation metadata. **Use Cases:** 1. Create a basic requirement with just a name 2. Add detailed metadata like priority, component, and description to a requirement 3. Associate a requirement with a specific release/cycle for planning 4. Set requirementOwner and requirementState using valid IDs from project info 5. Create a requirement in a specific folder using rqFolderId 6. Set custom fields (UDFs) values on the new requirement **Examples:** 1. Cr

Create a new test case in QMetry with steps, metadata, and release/cycle mapping. **Toolset:** Test Cases **Parameters:** - tcFolderID (string): Test Case folder ID - SYSTEM AUTOMATICALLY RESOLVES THIS. Leave empty unless you have a specific folder ID. System will fetch project info using the projectKey and extract rootFolders.TC.id automatically. Manual folder ID only needed if you want to target a specific sub-folder. - skipSteps (boolean): Set to true ONLY when the user explicitly says they do NOT want steps created (e.g. 'create test case without steps', 'no steps', 'skip steps'). When true, the 'steps' field must be omitted entirely. When false or absent (the default), steps MUST always be included — auto-generate them from context if the user did not provide them. - steps (array): STEPS RULE — include this field unless the user explicitly says NOT to create steps. NEVER send steps: [] (empty array) — always send at least 1 valid step object. Omit this field entirely (and set skipSteps: true) ONLY when the user explicitly asks to skip steps. HOW TO POPULATE: - If user explicitly provides steps: parse each step into { orderId, description, inputData?, expectedOutcome? }. - If user does NOT provide steps (and did not say to skip them): auto-generate meaningful steps based on the test case name, description, and context. Use your knowledge to infer 2-5 logical, realistic steps for the feature or flow being tested. Example: name='Login Test Case' → [{orderId:1, description:'Navigate to login page'}, {orderId:2, description:'Enter credentials'}, {orderId:3, description:'Submit and verify success'}] - If user explicitly said NOT to create steps: omit this field and set skipSteps: true. STEP DEFAULT VALUES: After building the steps array, check 'stepDefaultValues' from Fetch UDF Layout. stepDefaultValues shape: { fieldName: defaultValue } For each step: for each key in stepDefaultValues, if the user did NOT explicitly provide a value for that

Create a new test suite in QMetry with metadata and release/cycle mapping. **Toolset:** Test Suites **Parameters:** - parentFolderId (string): Test Suite parent folder ID - SYSTEM AUTOMATICALLY RESOLVES THIS. Leave empty unless you have a specific folder ID. System will fetch project info using the projectKey and extract rootFolders.TS.id automatically. Manual folder ID only needed if you want to target a specific sub-folder. - name (string) *required* - isAutomatedFlag (boolean) - description (string) - testsuiteOwner (number) - testSuiteState (number) - associateRelCyc (boolean) - releaseCycleMapping (array): Release/cycle association for the test suite. CRITICAL SHAPE DIFFERENCE vs Test Case mapping: Test Suite uses: { releaseId: number, buildID: number } Test Case uses: { release: number, cycle: number[], version: number } — DO NOT use TC shape here. Set associateRelCyc=true when providing this array. Example: [{ releaseId: 92112, buildID: 130831 }] - udfFields (record<string, union>): Flat UDF field values. Keys = UDF field names from 'Fetch UDF Layout'. Values depend on fieldTypeName: STRING/LARGETEXT: string, NUMBER: number, DATETIMEPICKER: date string ('14-08-2026'), LOOKUPLIST: numeric ID, MULTILOOKUPLIST: array of IDs [101, 102], CASCADINGLIST: { parent: 101, child: 102 }. Call 'Fetch UDF Layout' with entityType + pageName='ADD' to discover available fields and list option IDs. **Output Description:** JSON object containing the new test suite ID, summary, and creation metadata. **Use Cases:** 1. Create a basic test suite with just a name and folder 2. Add detailed metadata like description to a test suite 3. Associate test suite with specific release/cycle for planning 4. Set testsuiteOwner, testSuiteState, and other metadata using valid IDs from project info 5. Create test suites for isAutomatedFlag true or false for automated or manual types, default is false 6. Add test suite to a specific folder using parentFolderId 7. Map test suite to multip

Execute a quality gate report by forwarding the request to the backend analytics engine and returning the results. **Toolset:** AI Agent **Parameters:** - projectKey (string): Project key - unique identifier for the project (default: "default") - reportName (string) *required*: Report name identifier (e.g. 'RR' for Release Readiness). - gateIdentifier (string) *required*: Gate identifier to execute the report against (e.g. 'GATE1'). - projectId (number) *required*: Numeric project ID for the report scope. - releaseId (number): Optional release ID to scope the report to a specific release. - cycleIds (array): Optional array of cycle IDs to scope the report to specific cycles. - extKeys (array): Optional array of external issue keys (e.g. Jira keys like 'PROJ-123') to scope the report to specific external requirements. - page (number): Optional page number for paginated report results. - limit (number): Maximum number of records to return per page. Defaults to 100 if not specified. (default: 100) **Use Cases:** 1. Generate a release readiness report for a specific project, release, and cycle 2. Execute a quality gate assessment to evaluate project health against gate criteria 3. Run a gate report scoped to specific cycles within a release 4. Run a gate report scoped to specific external (e.g. Jira) issue keys 5. Produce analytics data for quality gate evaluation and decision-making **Examples:** 1. Execute a release readiness report for project 45851, release 90698, cycle 129140 ```json { "reportName": "RR", "gateIdentifier": "GATE1", "projectId": 45851, "releaseId": 90698, "cycleIds": [ 129140 ] } ``` Expected Output: { "data": [...], "total": 0, "success": true, "page": {} } 2. Execute a gate report scoped to specific external issue keys ```json { "reportName": "RR", "gateIdentifier": "GATE1", "projectId": 45851, "releaseId": 90698, "extKeys": [ "PROJ-101", "PROJ-102" ] } ``` Expected Output: { "data": [...], "total": 0, "suc

Export HTML content as a downloadable report file via the backend. **Toolset:** AI Agent **Parameters:** - projectKey (string): Project key - unique identifier for the project (default: "default") - htmlContent (string) *required*: HTML content to be exported as a report. - fileName (string) *required*: Name for the exported report file (without extension). Letters, digits, '.', '_' and '-' only - no path separators or '..' sequences. **Use Cases:** 1. Export a generated release readiness report as an HTML file 2. Save AI-generated quality gate analysis as a downloadable report 3. Create a shareable HTML document from report content **Examples:** 1. Export a release readiness report ```json { "htmlContent": "<h1>Release Readiness Report</h1><p>Generated by AI Agent.</p>", "fileName": "release-readiness-report" } ``` Expected Output: Report file generated and returned by the backend. **Hints:** 1. REQUIRED: 'htmlContent' is the full HTML string to export. 2. REQUIRED: 'fileName' is the report file name (without extension). 3. Typically called after generating report content from 'Execute Quality Gate Report' results.

Fetch the hourly and daily QMetry Open API call limits, calls consumed, calls remaining, and reset times **Toolset:** Projects **Parameters:** - projectKey (string): Project key - unique identifier for the project (default: "default") **Output Description:** JSON object: limitEnabled (boolean), hourly and daily objects each with limit, consumed, remaining (numbers) and resetsAt (UTC timestamp), and serverTime (UTC timestamp) **Use Cases:** 1. Check how many API calls remain before running a large batch of operations 2. Diagnose rate-limit or quota-exceeded errors returned by other QMetry tools 3. Find out when the hourly or daily quota will reset 4. Confirm whether API call limits are enabled for the instance **Examples:** 1. Check the current API call quota ```json {} ``` Expected Output: limitEnabled flag, hourly and daily { limit, consumed, remaining, resetsAt }, and serverTime **Hints:** 1. No parameters are needed — the quota belongs to the account/API key, not to a project 2. Calling this tool is free: it does not consume hourly or daily quota 3. If limitEnabled is false, no API call limits are enforced and the counts are informational only 4. resetsAt and serverTime are UTC ISO-8601 timestamps — compare resetsAt with serverTime, not with local time, to compute time until reset 5. Before a large batch of create/update/link calls, check hourly.remaining and daily.remaining and warn the user if the batch would exceed them 6. If another QMetry tool fails with a rate-limit or quota error, call this tool to report remaining calls and the reset time

Fetches the status of an automation import job by request ID. **Toolset:** Automation **Parameters:** - projectKey (string): Project key - unique identifier for the project (default: "default") - requestID (number) *required*: Numeric request ID from import automation response. CRITICAL: parameter name is 'requestID' — do NOT use 'requestId', 'jobId', or other variants. Accepts a string or number. **Use Cases:** 1. 1. Check if an automation import job is completed or still in progress. 2. 2. Retrieve status, progress, and details for a specific automation import request. 3. 3. Monitor automation result processing for CI/CD integrations. **Examples:** 1. Fetch status for request ID 12345 ```json { "requestID": 12345 } ``` Expected Output: Status, progress, and details of the automation import job for request ID 12345.

Fetch QMetry builds from the current project **Toolset:** Projects **Parameters:** - projectKey (string): Project key - unique identifier for the project (default: "default") - start (number): Start index for pagination - defaults to 0 (default: 0) - page (number): Page number to return (starts from 1) (default: 1) - limit (number): Number of records (default 10). (default: 10) - filter (string): Filter criteria as JSON string (default '[]') (default: "[]") **Output Description:** JSON object with builds list and pagination metadata **Use Cases:** 1. Fetch all from the current project 2. Fetch all available builds for test execution planning 3. Get build metadata for test run assignments 4. List builds for reporting and analytics 5. Filter builds by name or archive status 6. Get paginated build results for large projects 7. Retrieve build information for CI/CD integration 8. Search for specific builds using filters 9. Get build details for test execution history **Examples:** 1. Get all builds (default behavior) ```json {} ``` Expected Output: List of all builds with default pagination (10 items per page) 2. Get builds with custom pagination ```json { "page": 1, "limit": 10, "start": 0 } ``` Expected Output: List of builds with custom pagination settings 3. Filter builds by name ```json { "filter": "[{\"value\":\"Build 1.0\",\"type\":\"string\",\"field\":\"name\"}]" } ``` Expected Output: Filtered list of builds matching the name criteria 4. Filter builds by archive status ```json { "filter": "[{\"value\":[1,0],\"type\":\"list\",\"field\":\"isArchived\"}]" } ``` Expected Output: List of builds filtered by archive status (archived and non-archived) **Hints:** 1. Use 'default' project key when user doesn't specify one 2. Default pagination: start=0, page=1, limit=10 3. Filter parameter should be a JSON string with filter criteria 4. Common filter fields: 'name' (string), 'isArchived' (list of 0,1) 5. Empty payload {} is sent when no parameters are p

Fetch the child values of a CASCADINGLIST UDF field for a given parent item ID. Use this before bulk-updating a CASCADINGLIST Test Run UDF to discover valid child item IDs. **Toolset:** UDF **Parameters:** - projectKey (string): Project key - unique identifier for the project (default: "default") - id (number) *required*: Numeric ID of the parent cascade list item to fetch child values for. Get this from the 'lookupOptions' returned by 'Fetch Test Run UDF Metadata' for a CASCADINGLIST field — each option has an 'id' field. - isArchReq (boolean): Whether to include archived child items in the response (default: false). (default: false) **Output Description:** JSON object with 'parentId' (the input ID), 'parentName' (the parent item's display name), 'children' array (each item has id, name, uniqueLabel, isArchived), and a '_note' explaining how to use the IDs. **Use Cases:** 1. Find valid child values for a CASCADINGLIST UDF before bulk-updating test runs 2. List all child options available under a specific parent cascade item 3. Resolve child item ID when user knows the parent but not the child 4. Discover cascade hierarchy for a UDF field before setting it on test executions **Examples:** 1. Fetch child values for parent cascade item with ID 5173534 ```json { "id": 5173534 } ``` Expected Output: { parentId: 5173534, parentName: "India", children: [{ id: 5173535, name: "i1", uniqueLabel: "i1", isArchived: false }, ...], _note: "Use 'id' from 'children' as the 'child' value in the CASCADINGLIST update." } 2. Fetch child values including archived items for parent ID 5126498 ```json { "id": 5126498, "isArchReq": true } ``` Expected Output: { parentId: 5126498, parentName: "abc", children: [...], _note: "..." } **Hints:** 1. MANDATORY WORKFLOW for CASCADINGLIST bulk update: 1. Call 'Fetch Test Run UDF Metadata' → get the CASCADINGLIST field's 'fieldID' (projectUserFieldID) and parent item options from 'lookupOptions'. 2. Call this tool ('Fetch Casca

Fetch QMetry defects or issues - automatically handles viewId resolution based on project **Toolset:** Issues **Parameters:** - projectKey (string): Project key - unique identifier for the project (default: "default") - viewId (number): ViewId for issues - SYSTEM AUTOMATICALLY RESOLVES THIS. Leave empty unless you have a specific viewId. System will fetch project info using the projectKey and extract latestViews.IS.viewId automatically. - start (number): Start index for pagination - defaults to 0 (default: 0) - page (number): Page number to return (starts from 1) (default: 1) - limit (number): Number of records (default 10). (default: 10) - filter (string): Filter criteria as JSON string (default '[]') (default: "[]") - isJiraIntegrated (boolean): Send true if current project is Integrated with Jira (default: false) - sort (string): Sort Records - refer json schema, Possible property - entityKey, name, typeAlias, stateAlias, createdDate, createdByAlias, updatedDate, updatedByAlias, priorityAlias, createdSystem, linkedTcrCount, linkedRqCount, dfOwner, attachmentCount, environmentText (default: "[{\"property\":\"name\",\"direction\":\"ASC\"}]") **Output Description:** JSON object with 'data' array containing issues. Each issue has 'id' (numeric defect ID — use this as defectId for Fetch Issue Details), 'entityKey', 'name'/'summary', and other fields. There is no 'DefectId' field in this response — 'id' is the defect identifier. **Use Cases:** 1. List all issues in a project 2. Search for specific issues using filters 3. Get paginated issue results **Examples:** 1. Get all issues from default project - system will auto-fetch viewId ```json {} ``` Expected Output: List of issues from default project with auto-resolved viewId 2. Get all issues from UT project - system will auto-fetch UT project's viewId ```json { "projectKey": "UT" } ``` Expected Output: List of issues from UT project using UT's specific IS viewId 3. Get issues by release/cycle filter ```json {

Get executions for a given test suite in QMetry **Toolset:** Test Suites **Parameters:** - projectKey (string): Project key - unique identifier for the project (default: "default") - tsID (number) *required*: Test Suite numeric ID. CRITICAL: the parameter name is 'tsID' — do NOT use 'testSuiteId', 'testSuiteID', 'suiteId', or other variants. Accepts a string or number. NOTE: To get the tsID - Call API 'Testsuite/Fetch Testsuite' From the response, get value of following attribute -> data[<index>].id - tsFolderID (number): Test Suite folder ID. CRITICAL: the parameter name is 'tsFolderID' — do NOT use 'testSuiteFolderId', 'folderId', 'folderID', or other variants. Accepts a string or number. Get from project info response → rootFolders.TS.id. Use FETCH_PROJECT_INFO tool first if not provided by user. - gridName (string): Grid Name to be displayed (default 'TESTEXECUTIONLIST') - viewId (number): ViewId for test execution - SYSTEM AUTOMATICALLY RESOLVES THIS. Leave empty unless you have a specific viewId. System will fetch project info using the projectKey and extract latestViews.TE.viewId automatically. - start (number): Start index for pagination - defaults to 0 (default: 0) - page (number): Page number to return (starts from 1) (default: 1) - limit (number): Number of records (default 10). (default: 10) - filter (string): Filter criteria as JSON string (default '[]') (default: "[]") **Output Description:** JSON object with executions array containing execution details, status, platforms, releases, and execution metadata. Each execution entry may include 'linkedDfCount' (defects linked to the test execution) and 'linkedStepDfCount' (defects linked to the test step executions) - report both when linked defects are asked about. **Use Cases:** 1. Get all executions for a specific test suite for reporting purposes 2. Analyze test execution results and trends within a test suite 3. Filter executions by release, cycle, platform, or automation status 4. Monitor test sui

Fetch full detail data for a QMetry issue including UDF field values **Toolset:** Issues **Parameters:** - projectKey (string): Project key - unique identifier for the project (default: "default") - defectId (number) *required*: Issue DefectId (numeric ID) — use data[<index>].id from Fetch Issues/Defects response. The field in the list API response is named 'id', not 'DefectId'. **Output Description:** JSON object with data property containing full issue details including UDFTypeData map and all UDF field values **Use Cases:** 1. Get UDF field values for a specific issue 2. Retrieve full issue metadata including custom fields 3. Inspect issue details before updating UDF values **Examples:** 1. Fetch details for issue with DefectId 1430676 ```json { "defectId": 1430676 } ``` Expected Output: Full issue detail object with UDFTypeData map and all UDF field values including MUL1, TCR_STR, etc. **Hints:** 1. CRITICAL: Use 'data[<index>].id' from Fetch Issues/Defects response as 'defectId'. The list API response field is named 'id' — there is no 'DefectId' field in the list response. Do NOT guess or derive defectId from the entity key suffix. 2. AUTO-RESOLVE: If user provides an issue entity key (e.g. VKMCP2-IS-1, MAC-IS-10), first call Fetch Defects or Issues with filter '[{"type":"string","value":"VKMCP2-IS-1","field":"entityKeyId"}]', then use 'data[<index>].id' as defectId. 3. UDF VALUES: Response includes a 'UDFTypeData' map with all UDF field values for the issue. 4. WORKFLOW: To fetch issue UDF values — (1) Fetch Issues with entityKey filter → get data[0].id, (2) in parallel Fetch UDF Layout entityType='IS' pageName='DETAIL' → get field labels/types, (3) call this tool with defectId=data[0].id → read UDFTypeData.

Get test case executions linked to a QMetry-native (non-Jira) defect/issue. ALWAYS present results as a unified table: Test Suite Key | Test Suite Name | Release | Cycle | Platform | Executed Version | Execution Status | <UDF Label columns…>. NEVER show a separate type+value UDF breakdown — always combine identification fields and UDF values in one table per execution row. **Toolset:** Issues **Parameters:** - projectKey (string): Project key - unique identifier for the project (default: "default") - linkedAssetId (number) *required*: Numeric defect ID of the QMetry issue. CRITICAL: parameter name is 'linkedAssetId' — do NOT use 'issueId', 'defectId', 'id', or other variants. Accepts a string or number. To get this ID, call the Fetch Defects or Issues tool and use data[<index>].id from the response. - start (number): Start index for pagination - defaults to 0 (default: 0) - page (number): Page number to return (starts from 1) (default: 1) - limit (number): Number of records (default 10). (default: 10) - platformID (string): Platform ID to filter executions by environment/platform - filter (string): JSON filter string. Supported fields: tcName (string), linkageLevel (string), executedVersion (string), runStatusName (list of status names), platformID (list of numeric IDs), executionCreatedByLoginAlias (list of usernames), isTestSuiteArchived (list: [1] active, [0] archived, [1,0] both). Example: '[{"type":"string","value":"login","field":"tcName"}]' (default: "[]") **Output Description:** JSON object with 'data' array of execution records, 'hasTcRunUdf' boolean flag, and 'total' count. Each execution record ALWAYS contains these mandatory identification fields: 'tsEntityKey' (Test Suite Key, e.g. 'MAC-TS-42'), 'tsName' (Test Suite Name), 'releaseName' (Release), 'cycleName' (Cycle), 'platformName' (Platform/environment), 'executedVersion' (Executed Version of the test case), 'runStatusName' (Execution Status label), 'tcRunID' (numeric Test Run ID), 'tcName' (Test C

Get issues that are linked (or not linked) to a specific test case in QMetry **Toolset:** Issues **Parameters:** - projectKey (string): Project key - unique identifier for the project (default: "default") - tcID (number) *required*: Test Case numeric ID. CRITICAL: the parameter name is 'tcID' — do NOT use 'testCaseId', 'testCaseID', 'tcId', or other variants. Accepts a string or number. This is the internal numeric identifier, not the entity key like 'MAC-TC-1684'. You can get this ID from test case search results or by using filters. - getLinked (boolean): True to get only those issues that are linked with this Test case Run, False to get those issues which are not linked with this Test case Run. Default value true (get linked issues). (default: true) - start (number): Start index for pagination - defaults to 0 (default: 0) - page (number): Page number to return (starts from 1) (default: 1) - limit (number): Number of records (default 10). (default: 10) - filter (string): Filter criteria as JSON string (default '[]') (default: "[]") **Output Description:** JSON object with issues array containing issue details, priorities, status, and linkage information **Use Cases:** 1. Get all issues linked to a specific test case for defect tracking 2. Find issues that are NOT linked to a test case (gap analysis) 3. Generate traceability reports between test cases and issues 4. Filter issues by type, priority, status, or owner 5. Monitor issue resolution progress for specific test cases 6. Audit issue-test case relationships for compliance 7. Filter issues by summary content or execution version 8. Get issue details for test execution planning 9. Track linkage level (Test Case vs Test Step level) 10. Quality assurance - ensure proper issue tracking **Examples:** 1. Get all issues linked to test case ID 4495658 (default behavior) ```json { "tcID": 4495658 } ``` Expected Output: List of issues linked to the test case with issue details, status, and metadata 2. Get all iss

Get issues that are linked (or not linked) to a specific test case run in QMetry **Toolset:** Issues **Parameters:** - projectKey (string): Project key - unique identifier for the project (default: "default") - entityId (number) *required*: Id of Test case run (required for fetching linked issues). CRITICAL: the parameter name is 'entityId' — do NOT use 'tcRunId', 'testCaseRunId', 'runId', or other variants. Accepts a string or number. NOTE: To get the entityId - Call API 'Execution/Fetch Testcase Run ID' From the response, get value of following attribute -> data[<index>].tcRunID - getLinked (boolean): True to get only those issues that are linked with this Test case Run, False to get those issues which are not linked with this Test case Run. Default value true (get linked issues). (default: true) - getColumns (boolean): Whether to get column information in response. (default: true) - istcrFlag (boolean): Set True for test case run operations (default: true) - start (number): Start index for pagination - defaults to 0 (default: 0) - page (number): Page number to return (starts from 1) (default: 1) - limit (number): Number of records (default 10). (default: 10) - filter (string): Filter criteria as JSON string (default '[]') (default: "[]") **Output Description:** JSON object with issues array containing issue details, priorities, status, owner information, and linkage metadata **Use Cases:** 1. Get all issues linked to a specific test case run for defect tracking 2. Find issues that are NOT linked to a test case run (gap analysis) 3. Generate defect reports and traceability matrix for test case runs 4. Monitor issue resolution progress for specific test case executions 5. Analyze test execution quality by examining linked defects 6. Filter issues by type, priority, status, or owner for test case runs 7. Audit issue-test case run relationships for compliance 8. Track defect lifecycle in relation to test execution results 9. Quality assurance - ensure proper issu

Fetch QMetry platforms from the current project **Toolset:** Projects **Parameters:** - projectKey (string): Project key - unique identifier for the project (default: "default") - start (number): Start index for pagination - defaults to 0 (default: 0) - page (number): Page number to return (starts from 1) (default: 1) - limit (number): Number of records (default 10). (default: 10) - sort (string): Sort criteria as JSON string (default '[{"property":"platformID","direction":"DESC"}]') (default: "[{\"property\":\"platformID\",\"direction\":\"DESC\"}]") - filter (string): Filter criteria as JSON string (default '[]') (default: "[]") **Output Description:** JSON object with platforms list and pagination metadata **Use Cases:** 1. Fetch all platforms from the current project 2. Get platform metadata for test execution planning 3. List platforms for test environment selection 4. Filter platforms by name or properties 5. Get paginated platform results for large projects 6. Retrieve platform information for cross-platform testing 7. Search for specific platforms using filters 8. Get platform details for test execution assignment **Examples:** 1. Get all platforms (default behavior) ```json {} ``` Expected Output: List of all platforms with default pagination (10 items per page) 2. Get platforms with custom pagination ```json { "page": 1, "limit": 10, "start": 0 } ``` Expected Output: List of platforms with custom pagination settings 3. Filter platforms by name ```json { "filter": "[{\"value\":\"Chrome\",\"type\":\"string\",\"field\":\"name\"}]" } ``` Expected Output: Filtered list of platforms matching the name criteria 4. Filter platforms by archive status ```json { "filter": "[{\"value\":[1,0],\"type\":\"list\",\"field\":\"isArchived\"}]" } ``` Expected Output: List of platforms filtered by archive status (archived and non-archived) 5. Get only archived platforms ```json { "filter": "[{\"value\":[1],\"type\":\"list\",\"field\":\"isArchived\"}]" } ```

Fetch QMetry projects list including projectID, name, projectKey, isArchived, viewIds and folderPath needed for other operations **Toolset:** Projects **Parameters:** - projectKey (string): Project key - unique identifier for the project (default: "default") - params (object) *required* - start (number): Start index for pagination - defaults to 0 (default: 0) - page (number): Page number to return (starts from 1) (default: 1) - limit (number): Number of records (default 10). (default: 10) - filter (string): Filter criteria as JSON string (default '[]') (default: "[]") **Output Description:** JSON object containing list of projects details, including Version, Build Number(if greater than or equal to 1), Project ID, name, Project Key and Date Format **Use Cases:** 1. Get project list to check user how many project access to particular apikey 2. Retrieve available fields of each project list including projectID, name, projectKey, isArchived, viewIds and folderPath needed for other operations 3. Validate project access and permissions **Examples:** 1. Get list of project available to user ```json { "params": { "showArchive": false } } ``` Expected Output: Project active/non archived list including some important fields like projectID, name, projectKey, isArchived, viewIds and folderPath needed for other operations 2. Get projects with custom pagination ```json { "params": { "showArchive": false }, "page": 1, "limit": 10, "start": 0 } ``` Expected Output: List of projects with custom pagination settings 3. Get not active/archived projects ```json { "params": { "showArchive": true } } ``` Expected Output: List of all projects including archived ones (showArchive: true sent in payload) 4. Filter projects by name ```json { "filter": "[{\"value\":\"MAC\",\"type\":\"string\",\"field\":\"name\"}]" } ``` Expected Output: Filtered list of projects matching the name criteria 5. Filter projects by project key ```json { "filter": "[{\"valu

Fetch QMetry project information including viewId and folderPath needed for other operations **Toolset:** Projects **Parameters:** - projectKey (string): Project key - unique identifier for the project (default: "default") **Output Description:** JSON object containing project details, viewIds, folderPaths, project configuration, 'dateTimeFormatID' (active date format ID), and 'dateTimeFormatNew' array (each entry: { id, name, unique_value } — use unique_value of the matching entry as the date format pattern for all API date fields). **Use Cases:** 1. Get project configuration before fetching test cases 2. Retrieve available viewIds for test case listing 3. Get folderPath information for project navigation 4. Validate project access and permissions **Examples:** 1. Get default project info ```json {} ``` Expected Output: Project configuration with viewIds, folderPaths, and project details 2. Get specific project info ```json { "projectKey": "MAC" } ``` Expected Output: MAC project configuration with available views and folders **Hints:** 1. Always call this first when user doesn't provide viewId or folderPath 2. Use 'default' project key when user doesn't specify one 3. Extract viewId from latestViews.TC.viewId for test case operations 4. Use empty string '' as folderPath for root directory 5. DATE FORMAT — IMPORTANT: response contains 'dateTimeFormatID' (number) and 'dateTimeFormatNew' (array). 6. dateTimeFormatID = active format ID for this project. 7. dateTimeFormatNew = [{ id, name, unique_value }] — find entry where id === dateTimeFormatID. 8. unique_value is the authoritative date format pattern using Java/QMetry conventions: 9. yyyy = 4-digit year | MM = 2-digit month (01-12) | dd = 2-digit day | MMM = 3-letter month (Jan/Feb/...) 10. Example mappings: 11. unique_value 'MM-dd-yyyy' → format: 12-25-2024 12. unique_value 'dd-MM-yyyy' → format: 25-12-2024 13. unique_value 'yyyy-MM-dd' → format: 2024-12-25 14. unique_val

Fetch the quality gate configuration for a project and AI agent, including assessment scope and gate criteria. **Toolset:** AI Agent **Parameters:** - projectKey (string): Project key - unique identifier for the project (default: "default") - projectId (number) *required*: Numeric project ID for which to fetch the quality gate configuration. This is the internal numeric identifier, not the project key. - agentIdentifier (string) *required*: Unique identifier of the AI agent whose gate configuration should be retrieved. **Use Cases:** 1. Retrieve gate criteria and thresholds before generating a quality gate report 2. Check which quality gates are configured for a project and agent 3. Inspect assessment scope and gate parameters for release readiness evaluation **Examples:** 1. Fetch gate configuration for project 45851 and agent 'RR' ```json { "projectId": 45851, "agentIdentifier": "RR" } ``` Expected Output: Gate configuration object with assessment scope, gate criteria, and thresholds. **Hints:** 1. REQUIRED: 'projectId' must be a valid numeric project ID (not the project key). 2. REQUIRED: 'agentIdentifier' must match a registered AI agent identifier. 3. Call this tool before 'Execute Quality Gate Report' to understand the gate criteria and available gates. 4. If AI Agent is not enabled for the project, the backend will return an appropriate error.

Fetch QMetry releases and cycles from the current project **Toolset:** Projects **Parameters:** - projectKey (string): Project key - unique identifier for the project (default: "default") - showArchive (boolean): Whether to include archived records in the results. When true, returns both active and archived items. When false, returns only active (non-archived) items. Applies to any entity type being fetched (test cases, requirements, releases, cycles, builds, platforms, etc.). **Output Description:** JSON object with project hierarchy containing releases and their associated cycles **Use Cases:** 1. Fetch associated releases and cycles of current project 2. Fetch available releases and cycles of current project 3. Get release and cycle information for test planning 4. List all releases and cycles in a project 5. Search for specific releases using release name or ID 6. Fetch cycle lists based on release ID 7. Search for specific cycles using cycle name or ID 8. Get project structure for test planning and execution 9. Retrieve release hierarchy for reporting purposes **Examples:** 1. Get active releases and cycles (default behavior) ```json {} ``` Expected Output: List of active releases and cycles excluding archived ones (showArchive: false sent in payload) 2. Get active/unarchived releases and cycles explicitly ```json { "showArchive": false } ``` Expected Output: List of active releases and cycles excluding archived ones (showArchive: false sent in payload) 3. Get not active/archived releases and cycles ```json { "showArchive": true } ``` Expected Output: List of all releases and cycles including archived ones (showArchive: true sent in payload) **Hints:** 1. Use 'default' project key when user doesn't specify one 2. PAYLOAD SCENARIOS: 3. - No showArchive parameter → payload: {showArchive: false} → Returns only active releases/cycles 4. - showArchive: false → payload: {showArchive: false} → Returns only active/non-archived releases/cycles 5. - showArchi

Get detailed information for a specific QMetry requirement by numeric ID **Toolset:** Requirements **Parameters:** - projectKey (string): Project key - unique identifier for the project (default: "default") - id (number) *required*: Requirement numeric ID (required for fetching specific requirement details). This is the internal numeric identifier, not the entity key like 'MAC-RQ-730'. You can get this ID from requirement search results or by using filters. - version (number) *required*: Requirement version number (required for fetching specific requirement version details). This is the internal numeric identifier for the version. **Output Description:** JSON object with requirement details including ID, key, summary, description, status, and all metadata **Use Cases:** 1. Get requirement details by numeric ID 2. Retrieve requirement metadata for reporting 3. Get requirement summary and properties 4. Fetch requirement details before linking or updating 5. Access requirement field values and custom fields 6. Get requirement version-specific information **Examples:** 1. Get requirement details by numeric ID ```json { "id": 4791316, "version": 1 } ``` Expected Output: Detailed requirement information including summary, description, status, and all fields **Hints:** 1. This API requires a numeric ID parameter, not entity key 2. If user provides entityKey (e.g., MAC-RQ-730), first call FETCH_REQUIREMENTS with a filter on entityKeyId to resolve the numeric ID 3. After resolving entityKey → numeric ID, call this tool with the resolved numeric ID 4. Version parameter is required - use 1 for the latest version unless user specifies otherwise 5. This tool provides complete requirement information including all custom fields 6. Use this tool to get detailed requirement information that's not available in the list view

Fetch QMetry requirements - automatically handles viewId resolution based on project **Toolset:** Requirements **Parameters:** - projectKey (string): Project key - unique identifier for the project (default: "default") - viewId (number): ViewId for requirements - SYSTEM AUTOMATICALLY RESOLVES THIS. Leave empty unless you have a specific viewId. System will fetch project info using the projectKey and extract latestViews.RQ.viewId automatically. - folderPath (string): Folder path for requirements - SYSTEM AUTOMATICALLY SETS TO ROOT. Leave empty unless you want specific folder. System will automatically use empty string "" (root directory). Only specify if user wants specific folder like "Automation/Regression". (default: "") - start (number): Start index for pagination - defaults to 0 (default: 0) - page (number): Page number to return (starts from 1) (default: 1) - limit (number): Number of records (default 10). (default: 10) - scope (string): Scope of the operation - defines the context for data retrieval. Common values: 'project' (default), 'folder', 'release', 'cycle'. Applies to any entity type being fetched or operated upon. (default: "project") - getSubEntities (boolean): Whether to include sub-entities. - hideEmptyFolders (boolean): Whether to hide empty folders. - folderSortColumn (string): Folder sort column (default 'name') - folderSortOrder (string): Folder sort order (ASC or DESC) - isJiraFilter (boolean): 'false' if using qmetry filter (default: false) - filterType (enum): Pass 'QMETRY' or 'JIRA' (default: "QMETRY") - filter (string): Filter criteria as JSON string (default '[]') (default: "[]") - udfFilter (string): User-defined field filter as JSON string (default '[]') (default: "[]") - sort (string): Sort Records - refer json schema, Possible property - name, entityKey, associatedVersion, priorityAlias, createdDate, createdByAlias, updatedDate, updatedByAlias, requirementStateAlias, linkedTcCount, linkedDfCount, attachmentCount, createdSystem, owne

Get requirements that are linked (or not linked) to a specific test case in QMetry **Toolset:** Requirements **Parameters:** - projectKey (string): Project key - unique identifier for the project (default: "default") - tcID (number) *required*: Test Case numeric ID. CRITICAL: the parameter name is 'tcID' — do NOT use 'testCaseId', 'testCaseID', 'tcId', or other variants. Accepts a string or number. This is the internal numeric identifier, not the entity key like 'MAC-TC-1684'. You can get this ID from test case search results or by using filters. - getLinked (boolean): True to get only requirements that are linked with this test case, false to get requirements which are not linked with this test case. Defaults to true (get linked requirements). (default: true) - start (number): Start index for pagination - defaults to 0 (default: 0) - page (number): Page number to return (starts from 1) (default: 1) - limit (number): Number of records (default 10). (default: 10) - rqFolderPath (string): Folder path for requirements - SYSTEM AUTOMATICALLY SETS TO ROOT. Leave empty unless you want specific folder. System will automatically use empty string "" (root directory). Only specify if user wants specific folder like "Automation/Regression". (default: "") - filter (string): Filter criteria as JSON string (default '[]') (default: "[]") **Output Description:** JSON object with requirements array, traceability information, and pagination metadata **Use Cases:** 1. Get all requirements linked to a specific test case for traceability analysis 2. Find requirements that are NOT linked to a test case (gap analysis) 3. Verify test case coverage by checking linked requirements 4. Impact analysis - see which requirements are affected when a test case changes 5. Generate traceability matrix between test cases and requirements 6. Filter linked requirements by various criteria 7. Audit test case-requirement relationships for compliance 8. Identify orphaned requirements or test cases with

Get detailed information for a specific QMetry test case by numeric ID - USE THIS for single test case lookup **Toolset:** Test Cases **Parameters:** - projectKey (string): Project key - unique identifier for the project (default: "default") - tcID (number) *required*: Test Case numeric ID. CRITICAL: the parameter name is 'tcID' — do NOT use 'testCaseId', 'testCaseID', 'tcId', or other variants. Accepts a string or number. This is the internal numeric identifier, not the entity key like 'MAC-TC-1684'. You can get this ID from test case search results or by using filters. - start (number): Start index for pagination - defaults to 0 (default: 0) - page (number): Page number to return (starts from 1) (default: 1) - limit (number): Number of records (default 10). (default: 10) **Output Description:** JSON object with test case details including ID, key, summary, description, and metadata **Use Cases:** 1. Get test case details by numeric ID (PREFERRED for single test case) 2. Fetch test case when user provides entityKey (e.g., 'VKMCP-TC-5') 3. Retrieve test case metadata for a specific test case 4. Get test case summary and properties for display or editing 5. Fetch test case details before accessing steps or version details 6. Lookup test case by name or ID without affecting UI filters **Examples:** 1. Get test case details by numeric ID ```json { "tcID": 4468020 } ``` Expected Output: Detailed test case information including summary, description, status **Hints:** 1. USE THIS TOOL when user asks to 'fetch test case VKMCP-TC-5' or 'get test case by ID' or 'find test case X' 2. This API requires a numeric tcID parameter 3. CRITICAL: If user provides entityKey (e.g., MAC-TC-1684), you have TWO options: 4. Option 1 (RECOMMENDED): Ask user for the numeric test case ID 5. Option 2: If you must resolve entityKey, use FETCH_TEST_CASES with filter ONLY ONCE, then immediately use this tool 6. After resolving entityKey → tcID, always use THIS tool (FETCH_TEST_CASE_DETAIL

Get execution records for a specific test case by numeric ID, including Test Run UDF values. ALWAYS present results as a unified table: Test Suite Key | Test Suite Name | Release | Cycle | Platform | Executed Version | Execution Status | <UDF Label columns…>. NEVER show a separate type+value UDF breakdown — always combine identification fields and UDF values in one table per execution row. **Toolset:** Test Cases **Parameters:** - projectKey (string): Project key - unique identifier for the project (default: "default") - tcid (number) *required*: Test Case numeric ID. CRITICAL: the parameter name is 'tcID' — do NOT use 'testCaseId', 'testCaseID', 'tcId', or other variants. Accepts a string or number. This is the internal numeric identifier, not the entity key like 'MAC-TC-1684'. You can get this ID from test case search results or by using filters. - tcversion (number): Test Case version number (optional, defaults to 1). This is the internal numeric identifier for the version. - start (number): Start index for pagination - defaults to 0 (default: 0) - page (number): Page number to return (starts from 1) (default: 1) - limit (number): Number of records (default 10). (default: 10) - scope (string): Scope of the operation - defines the context for data retrieval. Common values: 'project' (default), 'folder', 'release', 'cycle'. Applies to any entity type being fetched or operated upon. (default: "project") - filter (string): Filter criteria as JSON string (default '[]') (default: "[]") **Output Description:** JSON object with executions array. Each execution record ALWAYS contains these mandatory identification fields: 'tsEntityKey' (Test Suite Key, e.g. 'MAC-TS-42'), 'testsuiteName' (Test Suite Name), 'releaseName' (Release), 'cycleName' (Cycle), 'platform' (Platform/environment), 'executedVersion' (Executed Version of the test case), 'executionStatus' (Execution Status label), 'tcRunID' (numeric Test Run ID), and 'testRunUdfs' (array of objects each with name, lab

Get test case runs under a specific test suite run execution in QMetry, including Test Run UDF values. ALWAYS present results as a unified table: Test Case Key | Test Case Summary | Executed Version | Execution Status | Linked Defects (Execution) | Linked Defects (Steps) | <UDF Label columns…>. NEVER show a separate type+value breakdown — always combine identification fields and UDF values in one table per run. Linked defects are TWO separate counts, never combine them into one 'Issues Linked' column. **Toolset:** Test Suites **Parameters:** - projectKey (string): Project key - unique identifier for the project (default: "default") - tsrunID (string) *required*: Test Suite Run ID. CRITICAL: the parameter name is 'tsrunID' — do NOT use 'testSuiteRunId', 'tsRunID', 'testSuiteRunID', or any other variant. Accepts a string or number (e.g. 731600 or '731600' — both are valid). To get this value: Call 'Fetch Executions by Test Suite' → use data[<index>].tsRunID from the response. - viewId (number): ViewId for test execution - SYSTEM AUTOMATICALLY RESOLVES THIS. Leave empty unless you have a specific viewId. System will fetch project info using the projectKey and extract latestViews.TE.viewId automatically. - start (number): Start index for pagination - defaults to 0 (default: 0) - page (number): Page number to return (starts from 1) (default: 1) - limit (number): Number of records (default 10). (default: 10) - filter (string): Filter criteria as JSON string (default '[]') (default: "[]") - udfFilter (string): User-defined field filter as JSON string (default '[]') (default: "[]") - tcrUdfFilter (string): Test Case Run (TCR) UDF filter as JSON string (default '[]'). Used to filter test case runs by Test Run UDF field values. Format: '[{"type":"list","value":[<listItemId1>,<listItemId2>],"field":"<udfFieldKey>"}]'. Example: '[{"type":"list","value":[5108701,5108697],"field":"8260LUP"}]' filters runs where the UDF field '8260LUP' has those list item IDs. (default: "[]") -

Get detailed test case steps for a specific test case by numeric ID **Toolset:** Test Cases **Parameters:** - projectKey (string): Project key - unique identifier for the project (default: "default") - id (number) *required*: Test Case numeric ID (required for fetching steps or version details). Accepts a string or number. This is the internal numeric identifier, not the entity key like 'MAC-TC-1684'. You can get this ID from test case search results. - version (number): Test Case version number (optional, defaults to 1). This is the internal numeric identifier for the version. - start (number): Start index for pagination - defaults to 0 (default: 0) - page (number): Page number to return (starts from 1) (default: 1) - limit (number): Number of records (default 10). (default: 10) **Output Description:** JSON object with array of test steps including step description, expected result, and order **Use Cases:** 1. Get step-by-step instructions with expected results 2. Retrieve test case execution procedure for manual runs 3. Export or display detailed test steps for documentation 4. Fetch steps before automation mapping **Examples:** 1. Get steps for test case ID 123 ```json { "id": 123 } ``` Expected Output: Detailed steps with actions and expected results for test case 123 **Hints:** 1. Requires numeric ID, not entityKey 2. If user provides entityKey (e.g., MAC-TC-1684), resolve it first via FETCH_TEST_CASES to get the numeric ID 3. Version defaults to 1 if not specified 4. Use pagination for test cases with many steps

Fetch test case steps including UDF field values via viewColumns endpoint **Toolset:** Test Cases **Parameters:** - projectKey (string): Project key - unique identifier for the project (default: "default") - tcID (number) *required*: Test Case numeric ID. CRITICAL: the parameter name is 'tcID' — do NOT use 'testCaseId', 'testCaseID', 'tcId', or other variants. Accepts a string or number. This is the internal numeric identifier, not the entity key like 'MAC-TC-1684'. You can get this ID from test case search results or by using filters. - viewId (number): ViewId for test cases - SYSTEM AUTOMATICALLY RESOLVES THIS. Leave empty unless you have a specific viewId. System will fetch project info using the projectKey and extract latestViews.TC.viewId automatically. - version (number): Test Case version number (optional, defaults to 1). This is the internal numeric identifier for the version. - start (number): Start index for pagination - defaults to 0 (default: 0) - page (number): Page number to return (starts from 1) (default: 1) - limit (number): Number of records (default 10). (default: 10) **Output Description:** JSON object with data array (steps with UDF values), filterTemplate (UDF field definitions), columns (visible/hidden column config), total count, and viewId **Use Cases:** 1. Get step UDF field values for a test case 2. Retrieve steps with custom fields before updating step UDFs 3. Inspect step-level UDF data for reporting **Examples:** 1. Fetch steps with UDF values for test case ID 112768054 ```json { "tcID": 112768054 } ``` Expected Output: Steps with UDF object containing field values, ID_<field> arrays for lookup IDs, UDF_<field> prefixed values, filterTemplate with UDF field definitions **Hints:** 1. Response includes 'filterTemplate' array listing all UDF fields with their fieldType and udfmID 2. UDF values in each step row: UDF_<fieldName> = display value, UDF_ID_<fieldName> = numeric IDs 3. Step UDF object also has ID_<fieldName> for lookup ID

Get QMetry test case details for a specific version by numeric ID **Toolset:** Test Cases **Parameters:** - projectKey (string): Project key - unique identifier for the project (default: "default") - id (number) *required*: Test Case numeric ID (required for fetching steps or version details). Accepts a string or number. This is the internal numeric identifier, not the entity key like 'MAC-TC-1684'. You can get this ID from test case search results. - version (number) *required*: Test Case version number. This is the internal numeric identifier for the version. - scope (string): Scope of the operation - defines the context for data retrieval. Common values: 'project' (default), 'folder', 'release', 'cycle'. Applies to any entity type being fetched or operated upon. (default: "project") **Output Description:** JSON object with version-specific test case details **Use Cases:** 1. Get specific version details of a test case 2. Compare different versions of a test case 3. Retrieve version history information 4. Audit changes made across test case versions **Examples:** 1. Get version 2 details for test case ID 123 ```json { "id": 123, "version": 2 } ``` Expected Output: Version 2 details for test case 123 **Hints:** 1. Requires numeric ID, not entityKey 2. If user provides entityKey (e.g., MAC-TC-1684), first resolve it to numeric ID using FETCH_TEST_CASES 3. Version defaults to 1 if not specified 4. Provides version-specific metadata and history

Fetch QMetry test cases - automatically handles viewId resolution based on project **Toolset:** Test Cases **Parameters:** - projectKey (string): Project key - unique identifier for the project (default: "default") - viewId (number): ViewId for test cases - SYSTEM AUTOMATICALLY RESOLVES THIS. Leave empty unless you have a specific viewId. System will fetch project info using the projectKey and extract latestViews.TC.viewId automatically. - folderPath (string): Folder path for test cases - SYSTEM AUTOMATICALLY SETS TO ROOT. Leave empty unless you want specific folder. System will automatically use empty string "" (root directory). Only specify if user wants specific folder like "Automation/Regression". (default: "") - folderID (number): Folder ID - unique numeric identifier for the specific folder. Use this to target a specific folder within the project hierarchy. Applies to any entity type (test cases, requirements, test suites, etc.). - start (number): Start index for pagination - defaults to 0 (default: 0) - page (number): Page number to return (starts from 1) (default: 1) - limit (number): Number of records (default 10). (default: 10) - scope (string): Scope of the operation - defines the context for data retrieval. Common values: 'project' (default), 'folder', 'release', 'cycle'. Applies to any entity type being fetched or operated upon. (default: "project") - showRootOnly (boolean): Whether to show only root folders. - getSubEntities (boolean): Whether to include sub-entities. - hideEmptyFolders (boolean): Whether to hide empty folders. - folderSortColumn (string): Folder sort column (default 'name') - restoreDefaultColumns (boolean): Whether to restore default columns (default 'false') - folderSortOrder (string): Folder sort order (ASC or DESC) - filter (string): Filter criteria as JSON string (default '[]') (default: "[]") - udfFilter (string): User-defined field filter as JSON string (default '[]') (default: "[]") **Output Description:** JSON object with

Get test cases that are linked (or not linked) to a specific requirement in QMetry **Toolset:** Requirements **Parameters:** - projectKey (string): Project key - unique identifier for the project (default: "default") - rqID (number) *required*: Requirement numeric ID (required for fetching specific requirement details). This is the internal numeric identifier, not the entity key like 'MAC-RQ-730'. You can get this ID from requirement search results or by using filters. - getLinked (boolean): True to get only test cases that are linked with this requirement, false to get test cases which are not linked with this requirement. Defaults to true (get linked test cases). (default: true) - showEntityWithReleaseCycle (boolean): True to list only test cases which have given release and cycle, false for all test cases regardless of release/cycle association. Defaults to false (show all). (default: false) - start (number): Start index for pagination - defaults to 0 (default: 0) - page (number): Page number to return (starts from 1) (default: 1) - limit (number): Number of records (default 10). (default: 10) - tcFolderPath (string): Folder path to get test cases under specific folder. Use empty string "" for root folder or specify path like "/Sample Template". (default: "") - releaseID (string): Filter test cases by release ID. Accepts a string or number. Get release IDs from FETCH_RELEASES_AND_CYCLES tool. - cycleID (string): Filter test cases by cycle ID. Accepts a string or number. Get cycle IDs from FETCH_RELEASES_AND_CYCLES tool. - filter (string): Filter criteria as JSON string (default '[]') (default: "[]") - getSubEntities (boolean): Allow filter of sub-entities for requirement. (default: true) - getColumns (boolean): True to get column information in response. (default: true) **Output Description:** JSON object with test cases array, traceability information, and pagination metadata **Use Cases:** 1. Get all test cases linked to a specific requirement for traceabil

Get test cases that are linked (or not linked) to a specific test suite in QMetry **Toolset:** Test Suites **Parameters:** - projectKey (string): Project key - unique identifier for the project (default: "default") - tsID (number) *required*: Test Suite numeric ID. CRITICAL: the parameter name is 'tsID' — do NOT use 'testSuiteId', 'testSuiteID', 'suiteId', or other variants. Accepts a string or number. NOTE: To get the tsID - Call API 'Testsuite/Fetch Testsuite' From the response, get value of following attribute -> data[<index>].id - getLinked (boolean): True to get only those issues that are linked with this Test case Run, False to get those issues which are not linked with this Test case Run. Default value true (get linked issues). (default: true) - start (number): Start index for pagination - defaults to 0 (default: 0) - page (number): Page number to return (starts from 1) (default: 1) - limit (number): Number of records (default 10). (default: 10) - filter (string): Filter criteria as JSON string (default '[]') (default: "[]") **Output Description:** JSON object with test cases array containing test case details, properties, and suite linkage information **Use Cases:** 1. Get all test cases linked to a specific test suite for execution planning 2. Find test cases that are NOT linked to a test suite (gap analysis) 3. Analyze test suite composition and coverage 4. Filter linked test cases by various criteria 5. Plan test execution based on test suite structure 6. Generate test suite reports and documentation 7. Validate test suite contents before execution 8. Manage test case organization within test suites 9. Export test suite details for external reporting 10. Verify test case assignments in test suites **Examples:** 1. Get all test cases linked to test suite ID 1497291 (default behavior) ```json { "tsID": 1497291 } ``` Expected Output: List of test cases linked to the test suite with test case details and metadata 2. Get all test cases linked to test s

Fetch the metadata (field definitions) for all Test Run UDF (User Defined Fields) configured in this QMetry project. Returns each field's name, display label, type, and numeric fieldID (projectUserFieldID) required for bulk updates. **Toolset:** UDF **Parameters:** - projectKey (string): Project key - unique identifier for the project (default: "default") **Output Description:** JSON object with 'fields' array (each item has fieldID, name, label, fieldType, allowBlank, and optional listName/listMasterID) and 'lookupOptions' map for list-based fields. If lookupOptions is empty for a list field, options could not be fetched automatically. **Use Cases:** 1. Get the fieldID for 'planned_execution_date' before bulk updating it 2. List all available Test Run UDF fields and their types in the project 3. Find the lookup list item IDs for a LOOKUPLIST or MULTILOOKUPLIST Test Run UDF 4. Discover UDF field names and IDs when user says 'what Test Run UDF fields are available' **Examples:** 1. List all Test Run UDF fields in the project ```json {} ``` Expected Output: Array of fields with fieldID, name, label, fieldType, and lookupOptions for list-based fields. **Hints:** 1. ALWAYS call this tool before 'Bulk Update Test Run UDFs' when the user has not explicitly provided a numeric fieldID. The 'fieldID' in the bulk update corresponds to 'projectUserFieldID' in this response. 2. This tool is the authoritative source of fieldIDs for all Test Run UDF fields — do NOT guess or hard-code fieldIDs. 3. For LOOKUPLIST and MULTILOOKUPLIST fields, the response 'lookupOptions' contains items with 'id', 'name' (display label), and 'uniqueLabel' (internal key stored in executions). When execution UDF values are returned by Fetch Issue Executions or Fetch Test Run UDF Values, LOOKUPLIST/MULTILOOKUPLIST values are already resolved from uniqueLabel → name. For bulk updates, use the item 'id' as the value. 4. DATE fields use MM-DD-YYYY format (e.g. '06-23-2026') when setting values via Bul

Fetch the Test Run UDF (User Defined Field) values for all test case runs in a given test suite run. Returns each run's UDF values enriched with field label and type information from metadata. Use this tool for test suite run UDF values (sourceContext='testSuiteRun'). Do NOT use this tool for test case executions — 'Fetch Test Case Executions' already calls metadata internally and returns 'testRunUdfs' in every execution row. **Toolset:** UDF **Parameters:** - projectKey (string): Project key - unique identifier for the project (default: "default") - tsrunID (string): Test Suite Run ID. CRITICAL: the parameter name is 'tsrunID' — do NOT use 'testSuiteRunId', 'tsRunID', or any other variant. Accepts a string or number (e.g. 731600 or '731600' — both are valid). Get this from 'Fetch Executions by Test Suite' → use data[<index>].tsRunID from the response. Required when sourceRows is not provided. - viewId (number): View ID for the test execution list (latestViews.TE.viewId from project info). Auto-resolved from project info when omitted. Required when sourceRows is not provided. - sourceContext (enum): Which parent tool produced sourceRows. Use 'testSuiteRun' for Fetch Test Case Runs by Test Suite Run. Do NOT use this tool for Fetch Test Case Executions — that tool calls metadata internally and returns testRunUdfs on every execution row; use that data directly. Do NOT use this tool for Fetch Issue Executions; that tool already reads udfjson and enriches it with metadata. (default: "testSuiteRun") - sourceRows (array): Optional rows already returned by Fetch Test Case Runs by Test Suite Run. The UDF tool will reuse these rows, enrich/pivot UDF values, and preserve identification fields instead of making the same execution-list API call again. Do NOT pass Fetch Test Case Executions rows here — those rows already have testRunUdfs enriched. Do not pass issue execution rows here; use Fetch Issue Executions output directly for issue UDFs. - startIndex (number): Zero-based

Fetch full detail data for a QMetry test suite including UDF field values **Toolset:** Test Suites **Parameters:** - projectKey (string): Project key - unique identifier for the project (default: "default") - id (number) *required*: Test Suite ID (numeric ID) - scope (string): Scope of the operation - defines the context for data retrieval. Common values: 'project' (default), 'folder', 'release', 'cycle'. Applies to any entity type being fetched or operated upon. (default: "project") **Output Description:** JSON object with full test suite details including UDFTypeData map and all UDF field values **Use Cases:** 1. Get UDF field values for a specific test suite 2. Retrieve full test suite metadata including custom fields 3. Inspect test suite details before updating UDF values **Examples:** 1. Fetch details for test suite with ID 142013 ```json { "id": 142013 } ``` Expected Output: Full test suite detail object with UDFTypeData, UDF field values, and metadata

Fetch QMetry test suites - automatically handles viewId resolution based on project **Toolset:** Test Suites **Parameters:** - projectKey (string): Project key - unique identifier for the project (default: "default") - viewId (number): ViewId for test suites - SYSTEM AUTOMATICALLY RESOLVES THIS. Leave empty unless you have a specific viewId. System will fetch project info using the projectKey and extract latestViews.TS.viewId automatically. - folderPath (string): Folder path for test suites - SYSTEM AUTOMATICALLY SETS TO ROOT. Leave empty unless you want specific folder. System will automatically use empty string "" (root directory). Only specify if user wants specific folder like "Automation/Regression". (default: "") - start (number): Start index for pagination - defaults to 0 (default: 0) - page (number): Page number to return (starts from 1) (default: 1) - limit (number): Number of records (default 10). (default: 10) - scope (string): Scope of the operation - defines the context for data retrieval. Common values: 'project' (default), 'folder', 'release', 'cycle'. Applies to any entity type being fetched or operated upon. (default: "project") - getSubEntities (boolean): Whether to include sub-entities. - filter (string): Filter criteria as JSON string (default '[]') (default: "[]") - udfFilter (string): User-defined field filter as JSON string (default '[]') (default: "[]") - sort (string): Sort Records - refer json schema, Possible property - entityKey, name, testsuiteStatus, linkedPlatformCount, linkedTcCount, createdDate, createdByAlias, updatedDate, updatedByAlias, attachmentCount, owner, remExecutionTime, totalExecutionTime (default: "[{\"property\":\"name\",\"direction\":\"ASC\"}]") **Output Description:** JSON object with 'data' array containing test suites and pagination info **Use Cases:** 1. List all test suites in a project 2. Search for specific test suites using filters 3. Browse test suites in specific folders 4. Get paginated test suite results

Get test suites that can be linked to test cases in QMetry with automatic viewId resolution **Toolset:** Test Suites **Parameters:** - projectKey (string): Project key - unique identifier for the project (default: "default") - tsFolderID (number): Test Suite folder ID. CRITICAL: the parameter name is 'tsFolderID' — do NOT use 'testSuiteFolderId', 'folderId', 'folderID', or other variants. Accepts a string or number. Get from project info response → rootFolders.TS.id. Use FETCH_PROJECT_INFO tool first if not provided by user. - viewId (number): ViewId for test suite folders - SYSTEM AUTOMATICALLY RESOLVES THIS. Leave empty unless you have a specific viewId. System will fetch project info using the projectKey and extract latestViews.TSFS.viewId automatically. - start (number): Start index for pagination - defaults to 0 (default: 0) - page (number): Page number to return (starts from 1) (default: 1) - limit (number): Number of records (default 10). (default: 10) - getColumns (boolean): Whether to get column information in response. (default: true) - filter (string): Filter criteria as JSON string (default '[]') (default: "[]") **Output Description:** JSON object with test suites array and pagination metadata **Use Cases:** 1. Get test suites available for linking with test cases 2. Find appropriate test suites for test case organization 3. Browse test suites in specific folders for better management 4. Filter test suites by release, cycle, or archive status 5. Organize test execution by grouping test cases into test suites 6. Plan test suite structure for comprehensive test coverage 7. Manage test case categorization for reporting purposes 8. Search for existing test suites before creating new ones 9. Get root test suite folder contents using project info **Examples:** 1. Get test suites from root folder using auto-resolved viewId ```json { "tsFolderID": 113557 } ``` Expected Output: List of test suites available in the root test suite folder with auto-resolved

Fetch UDF (User Defined Field) definitions for Test Case, Test Suite, Issue, or Requirement entities. Returns field names, types, fieldIDs, and lookup option IDs. Call this BEFORE creating or updating an entity with UDF values. **Toolset:** UDF **Parameters:** - projectKey (string): Project key - unique identifier for the project (default: "default") - entityType (enum) *required*: Entity type to fetch UDF field definitions for. 'TC' = Test Case (also returns step UDFs in stepFields), 'TS' = Test Suite, 'IS' = Issue, 'RQ' = Requirement. - pageName (enum): 'ADD' returns fields for create operations (no fieldID needed). 'DETAIL' returns fields for update operations and includes fieldID (projectUserFieldID) required by the UDF update wrapper. Call with 'DETAIL' before updating an entity's UDF values. (default: "ADD") **Output Description:** JSON with 'entityType', 'pageName'. All data is scoped by entityType key in the QMetry newlayout response: TC uses qmUDF.TC / qmSDF.TC / qmDefaultValue.TC; TS uses qmUDF.TS / qmSDF.TS / qmDefaultValue.TS; IS uses qmUDF.IS / qmSDF.IS / qmDefaultValue.IS. 'fields' array — UDF fields (name, label, fieldTypeName, fieldID, isMandatory, optional listName); isMandatory=true when allowBlank=false in QMetry. 'systemFields' array — system fields like Summary/Priority/Status (name, label, fieldTypeName, isMandatory); isMandatory=true when allowBlank=false. 'defaultValues' object — { fieldName: defaultValueId } pre-configured defaults (auto-fill when user omits the field; no need to ask user). TC-only: 'stepFields' — step UDF fields; 'stepSystemFields' — step system fields (mandatory via tcSteps[].mandatory=true); 'stepDefaultValues' — { fieldName: defaultValueId } from qmTCSDefaultValue.TCS. 'listOptions' map (listName → [{id, name, isArchived}]). '_note' with workflow instructions. **Use Cases:** 1. Discover UDF fields before creating a Test Case with custom fields 2. Get fieldIDs before updating a Test Suite's UDF values 3. Find valid dr

Import/Publish automation test results from TestNG, JUnit, Cucumber, Robot, HPUFT, or QAF frameworks into QMetry **Toolset:** Automation **Parameters:** - file (string) *required*: Base64 encoded file content or file path. User must upload result file (.json, .xml, .zip up to 30 MB) - fileName (string) *required*: Original filename with extension (.json, .xml, or .zip) - entityType (enum) *required*: Format of result file: TESTNG, CUCUMBER, JUNIT, HPUFT, QAF, or ROBOT - automationHierarchy (enum): TestNG/JUnit hierarchy: 1=Test Case-Test Step, 2=Test Case only, 3=Test Suite-Test Case. Default: 1 - testsuiteName (string): Custom test suite name. Ignored if automationHierarchy=3 for JUnit or =2 for ROBOT - testsuiteId (string): Reuse existing Test Suite by ID or Entity Key. Ignored if automationHierarchy=3 for JUnit or =2 for ROBOT - tsFolderPath (string): Test suite folder path. Creates folder if doesn't exist. Ignored if reusing test suite - tcFolderPath (string): Test case folder path. Creates folder if doesn't exist. Ignored if reusing test case - platformID (string): Platform ID or Platform Name. Default: 'No Platform' - projectID (string): Project ID, Project Key, or Project name. Overrides project in header - releaseID (string): Release ID or Release name. Requires projectID if provided - cycleID (string): Cycle ID or Cycle name. Requires releaseID and projectID if provided - buildID (string): Build ID or Build name - testcase_fields (string): JSON string with test case system fields and UDFs. Ignored if reusing test case. Example: {"component":["com1"], "priority":"High"} - testsuite_fields (string): JSON string with test suite system fields and UDFs. Ignored if reusing test suite. Example: {"testSuiteState":"Open", "testsuiteOwner":"user"} - skipWarning (enum): 0=Fail if summary >255 chars, 1=Truncate summary to 255 chars. Default: 0 - is_matching_required (string): True=Create new TC if summary/steps don't match, False=Reuse linked TC. Default: True **Use

Link one or more issues to a QMetry Testcase Run (execution). **Toolset:** Issues **Parameters:** - projectKey (string): Project key - unique identifier for the project (default: "default") - issueIds (array) *required*: ID of issues to be linked to Testcase Run - tcrId (number) *required*: ID of Testcase Run to link issues with. CRITICAL: parameter name is 'tcrId' — do NOT use 'tcRunId', 'testCaseRunId', or other variants. Accepts a string or number. **Output Description:** JSON object with linkage status and details. **Use Cases:** 1. Link a single issue to a testcase run 2. Link multiple issues to a testcase run 3. Automate defect association during test execution 4. Maintain traceability between defects and test runs **Examples:** 1. Link one issue to a testcase run ```json { "issueIds": [ "5054834" ], "tcrId": 567890 } ``` Expected Output: Issue 5054834 linked to testcase run 567890 successfully. 2. Link multiple issues to a testcase run ```json { "issueIds": [ "5054834", "5054835" ], "tcrId": 567890 } ``` Expected Output: Issues 5054834, 5054835 linked to testcase run 567890 successfully. **Hints:** 1. if you have pass issue key (VT-IS-5, MAC-IS-10 etc.) then first fetch issue by issue key to get issue id. 2. To get the issueIds, call the Fetch issues linked with testcases tool and use data[<index>].defectID from the response. 3. To get the tcrId, call the Execution/Fetch Testcase Run ID tool and use data[<index>].tcRunID from the response. 4. Both issueIds and tcrId are required. 5. You can link multiple issues at once by providing an array of IDs.

Link one or more platforms to a QMetry Test Suite. **Toolset:** Test Suites **Parameters:** - projectKey (string): Project key - unique identifier for the project (default: "default") - qmTsId (number) *required*: Id of Test Suite (required). CRITICAL: the parameter name is 'qmTsId' — do NOT use 'tsId', 'testSuiteId', 'tsID', or other variants. Accepts a string or number. To get the qmTsId - Call API 'Testsuite/Fetch Testsuite'. From the response, get value -> data[<index>].id - qmPlatformId (string) *required*: Comma-separated Platform IDs (required). CRITICAL: the parameter name is 'qmPlatformId' — do NOT use 'platformId', 'platformID', 'platformIds', or other variants. Accepts a number or string. To get the qmPlatformId - Call API 'Platform/List'. From the response, get value -> data[<index>].platformID **Output Description:** JSON object with linkage status, success message, and details. **Use Cases:** 1. Link a single platform to a test suite 2. Link multiple platforms to a test suite for cross-platform testing 3. Define execution environments for a test suite 4. Organize test suites by supported platforms 5. Set up platform-specific test suite configurations **Examples:** 1. Link single platform to a test suite ```json { "qmTsId": 1511970, "qmPlatformId": "63004" } ``` Expected Output: Platform 63004 linked to test suite 1511970 successfully. 2. Link multiple platforms to a test suite ```json { "qmTsId": 1511970, "qmPlatformId": "63004,63005,63006" } ``` Expected Output: Platforms 63004, 63005, 63006 linked to test suite 1511970 successfully. **Hints:** 1. CRITICAL: qmTsId and qmPlatformId are REQUIRED parameters 2. To get the qmTsId (Test Suite ID): 3. 1. Call 'Testsuite/Fetch Testsuite' API 4. 2. From response, use data[<index>].id 5. 3. Example: Test Suite 'Login Tests' might have ID 1511970 6. To get the qmPlatformId (Platform ID): 7. 1. Call 'Platform/List' API (Fetch Platforms tool) 8. 2. From response, use data[<index>].platform

Link one or more requirements to a test case by entityKey and version IDs. **Toolset:** Requirements **Parameters:** - tcID (string) *required*: EntityKey of Testcase (e.g. 'COD-TC-29') - tcVersionId (number) *required*: Test Case version number. This is the internal numeric identifier for the version. - rqVersionIds (string) *required*: Comma-separated values of versionId of the Requirement (e.g. '236124,236125') **Output Description:** JSON object with success status and linkage details. **Use Cases:** 1. Link requirements to a test case for traceability 2. Bulk link multiple requirements to a single test case 3. Automate requirement coverage mapping **Examples:** 1. Link requirements to test case VT-TC-26 ```json { "tcID": "VT-TC-26", "tcVersionId": 5448515, "rqVersionIds": "5009939,5009937,4970699" } ``` Expected Output: Requirements linked to test case VT-TC-26 successfully. **Hints:** 1. To get the tcID, call the Testcase/Fetch List for Bulk Operation API and use data[<index>].entityKey. 2. To get the tcVersionId, call the Testcase/Fetch Versions API and use data[<index>].tcVersionID. 3. To get the rqVersionIds, call the requirement/List Versions API and use data[<index>].rqVersionID. 4. If user provides requirement entityKey (e.g., VT-RQ-18), first call requirements list with a filter on entityKeyId to resolve the rqVersionIds 5. If user provides testcase entityKey (e.g., VT-TC-26), first call testcase list with a filter on entityKeyId to resolve the tcVersionId and tcID. 6. rqVersionIds must be a comma-separated string of requirement version IDs.

Link one or more defects/issues to a test case by entityKey and issue IDs. **Toolset:** Test Cases **Parameters:** - tcID (string) *required*: EntityKey of the Test Case to link issues to (e.g. '8d7b-TC-63'). CRITICAL: the parameter name is 'tcID' — do NOT use 'testCaseId' or 'tcId'. - dfIDs (array) *required*: Array of numeric defect/issue IDs to link to the test case (e.g. [2039, 2038, 2037]). **Output Description:** JSON object with success status and linkage details. **Use Cases:** 1. Link defects/issues to a test case for traceability 2. Bulk link multiple issues to a single test case 3. Automate defect coverage mapping **Examples:** 1. Link issues to test case 8d7b-TC-63 ```json { "tcID": "8d7b-TC-63", "dfIDs": [ 2039, 2038, 2037, 1528 ] } ``` Expected Output: Issues linked to test case 8d7b-TC-63 successfully. **Hints:** 1. To get the tcID, call the 'Fetch Test Cases' tool and use data[<index>].entityKey. 2. dfIDs must be an array of numeric issue/defect IDs — resolve them using the 'Fetch Defects or Issues' tool. 3. If the user provides a test case entityKey (e.g., 8d7b-TC-63), use it directly as tcID. 4. CRITICAL: the parameter name is 'tcID' — do NOT use 'testCaseId' or 'tcId'. 5. CRITICAL: the parameter name is 'dfIDs' — do NOT use 'issueIds' or 'defectIds'.

Link test cases to a test suite in QMetry. **Toolset:** Test Suites **Parameters:** - tsID (number) *required*: Id of Test Suite (required). CRITICAL: parameter name is 'tsID' — do NOT use 'testSuiteId', 'testSuiteID', or other variants. - tcvdIDs (array) *required*: Array of Test Case Version IDs (required if fromReqs is false). CRITICAL: parameter name is 'tcvdIDs' — do NOT use 'tcVersionIds', 'testCaseVersionIds', or other variants. - fromReqs (boolean): Link TestCases from Requirements (optional, default false) **Output Description:** JSON object with linkage status and details. **Use Cases:** 1. Link test cases to a test suite by entity keys 2. Bulk link multiple test cases to a suite 3. Automate test suite composition from test cases **Examples:** 1. Link test cases to a test suite ```json { "tsID": 8674, "tcvdIDs": [ 5448504, 5448503 ], "fromReqs": false } ``` Expected Output: Test cases QTM-TC-32 and QTM-TC-35 linked to test suite 8674. 2. Link test cases directly to test suites with test cases entityKeys VT-TC-9, VT-TC-10 to test suite id 1487397 ```json { "tsID": 1487397, "tcvdIDs": [ 5448504, 5448503 ], "fromReqs": false } ``` Expected Output: Test cases VT-TC-9 and VT-TC-10 linked to test suite 1487397. 3. Link test case VT-TC-4, VT-TC-1,VT-TC-101, VT-TC-22 to test suite VT-TS-3 ```json { "tsID": 1487397, "tcvdIDs": [ 5448504, 5448503, 5448505, 5448506 ], "fromReqs": false } ``` Expected Output: Test cases VT-TC-4, VT-TC-1, VT-TC-101, and VT-TC-22 linked to test suite VT-TS-3. **Hints:** 1. To get the tsID, call the Fetch Test Suites for Test Case API with rootFolderId otherwise if given folderid so use that and from response get the id. 2. To get the tcvdIDs by testcase entityKey, call the Testcase/Fetch Versions API and use data[<index>].tcVersionID. 3. Set fromReqs to false to direct test case linkage.

Link test cases (including those linked to requirements) to a test suite in QMetry. **Toolset:** Test Suites **Parameters:** - tsID (number) *required*: Id of Test Suite (required). CRITICAL: parameter name is 'tsID' — do NOT use 'testSuiteId', 'testSuiteID', or other variants. - tcvdIDs (array) *required*: Array of Test Case Version IDs (required if fromReqs is true). CRITICAL: parameter name is 'tcvdIDs' — do NOT use 'tcVersionIds', 'testCaseVersionIds', or other variants. - fromReqs (boolean): Link TestCases from Requirements (optional, default true) **Output Description:** JSON object with linkage status and details. **Use Cases:** 1. Link requirements linked test cases to a test suite 2. Bulk link multiple requirements linked test cases to a suite 3. Automate test suite composition from requirements linked test cases **Examples:** 1. VT-RQ-18 Requirements Linked test cases to a test suite ```json { "tsID": 8674, "tcvdIDs": [ 5448504, 5448503 ], "fromReqs": true } ``` Expected Output: Test cases QTM-TC-32 and QTM-TC-35 linked to test suite 8674. 2. VT-RQ-19 Requirements Linked test cases to test suites id 1487397 ```json { "tsID": 1487397, "tcvdIDs": [ 5448504, 5448503 ], "fromReqs": true } ``` Expected Output: Test cases VT-TC-9 and VT-TC-10 linked to test suite 1487397. 3. VT-RQ-20 Requirements Linked test case to test suite VT-TS-3 ```json { "tsID": 1487397, "tcvdIDs": [ 5448504, 5448503, 5448505, 5448506 ], "fromReqs": true } ``` Expected Output: Test cases VT-TC-4, VT-TC-1, VT-TC-101, and VT-TC-22 linked to test suite VT-TS-3. **Hints:** 1. To get the tsID, call the Fetch Test Suites for Test Case API with rootFolderId otherwise if given folderid so use that and from response get the id. 2. To get the requirement linked tcvdIDs by requirement entityKey, call the Fetch Test Cases Linked to Requirement API by <requirementEntityKey> to fetch If user provides entityKey (e.g., MAC-RQ-1011), first ca

Set current QMetry project for your account **Toolset:** Projects **Parameters:** - projectKey (string): Project key - unique identifier for the project (default: "default") **Output Description:** JSON object containing project configuration details, confirmation of project switch, and available project metadata,including Version, Build Number(if greater than or equal to 1), Project ID, name, Project Key and Date Format **Use Cases:** 1. Switch to a specific project before performing test case operations 2. Set project context for batch operations on test cases 3. Configure the default project for the current session 4. Validate access to a specific project before proceeding with operations **Examples:** 1. Set default project as active ```json { "projectKey": "default" } ``` Expected Output: Project context set to 'default' with confirmation of project details 2. Switch to UT project ```json { "projectKey": "UT" } ``` Expected Output: Project context switched to 'UT' project with available configurations 3. Set MAC project as active for test case operations ```json { "projectKey": "MAC" } ``` Expected Output: Project context set to 'MAC' with viewIds and folder structure **Hints:** 1. Always set the project context before performing test case operations in multi-project environments 2. Use the same project key that you'll use in subsequent test case operations 3. Common project keys include 'default', 'UT', 'MAC', 'VT' - check with your QMetry admin for available projects 4. This operation must be performed before fetching test cases if working with non-default projects 5. The project context persists for the current session until changed again

Update an existing cycle in QMetry for test execution planning **Toolset:** Projects **Parameters:** - projectKey (string): Project key - unique identifier for the project (default: "default") - cycle (object) *required* **Output Description:** JSON object containing the updated cycle details and confirmation of update **Use Cases:** 1. Update cycle name for better organization 2. Modify cycle dates to reflect schedule changes 3. Adjust testing phase timelines within a release 4. Update cycle metadata for sprint tracking 5. Revise milestone dates for test execution planning 6. Rename cycles to match updated sprint naming conventions **Examples:** 1. Update cycle name ```json { "cycle": { "name": "Alpha_v1_Updated", "buildID": 1494, "releaseID": 3729 } } ``` Expected Output: Cycle updated successfully with new name 'Alpha_v1_Updated' 2. Update cycle dates ```json { "cycle": { "startDate": "10-10-2018", "targetDate": "11-11-2018", "buildID": 1494, "releaseID": 3729 } } ``` Expected Output: Cycle dates updated successfully with new start date 10-10-2018 and target date 11-11-2018 3. Update cycle name and dates together ```json { "cycle": { "name": "Sprint 2 - Updated", "startDate": "15-01-2024", "targetDate": "31-01-2024", "buildID": 1494, "releaseID": 3729 } } ``` Expected Output: Cycle updated with new name and dates successfully **Hints:** 1. CRITICAL: cycle.buildID is REQUIRED - must provide the build ID to identify the cycle to update 2. CRITICAL: cycle.releaseID is REQUIRED - must provide the release ID to identify the cycle to update 3. HOW TO GET buildID and releaseID: 4. 1. Call FETCH_RELEASES_CYCLES tool (API: 'Cycle/List') to get all cycles 5. 2. From the response, get buildID from projects.releases[<index>].builds[<index>].buildID 6. 3. From the response, get releaseID from projects.releases[<index>].releaseID 7. 4. Use those numeric IDs in cycle.buildID and cycle.releaseID parameters 8. Ex