Qase Test Management

Call any Qase REST endpoint directly, for the few things no dedicated tool covers: method, a /v1/… path on the configured host, optional body or query. Prefer a dedicated tool where one exists — they normalize enums and validate before spending a call. JSON only; uploads go through qase_attachment_upload. A DELETE asks for confirmation like the dedicated delete tools. Cost: one API call, 0.3-1.5s.

Delete an attachment by its hash (from qase_attachment_upload). Anything referencing it keeps the reference but the file is gone; this cannot be undone. Asks the user for confirmation first. Cost: one API call, about 0.4s.

Upload files and get back the hashes other tools reference them by. Pass `file_base64` plus `filename` for one file, or `files` for several in one request; `file_path` only works when the server runs on the same machine as the file — never on the hosted connector. The hash must then be passed in an `attachments` field; uploading alone attaches nothing. This is the only tool that sends multipart/form-data, which is why qase_api cannot send files. Cost: one API call per request, dominated by size.

Create up to 100 test cases in one request — the batch form of qase_case_upsert, and the right tool whenever more than one case is being written. Same fields and enum handling as qase_case_upsert; creates only, update through qase_case_upsert with `id`. Cost: one API call regardless of batch size — ten cases measured 1.2s against 5.6s as ten separate calls.

Delete a test case by project code and ID. Its execution history goes with it and this cannot be undone; consider marking it deprecated through qase_case_upsert instead. No bulk delete — one call each, each asking the user for confirmation. Cost: one API call, about 0.4s.

Create or update a single test case: with `id` it updates, without it creates. Enum fields accept a label such as "high" or the project's numeric ID. Writing more than one case? Use qase_case_bulk_create — one request instead of one per case. If the project has "Test case review" enabled, writes may need a review — run qase_discover_tools with "review". Cost: one API call, about 0.6s to create, 0.4s to update.

Report a whole finished CI run in one call: creates the run, records every result, completes it. Use qase_result_record instead when the run already exists and results arrive in stages. Each result needs a numeric `case_id` and a status; batches over 200 are split for you, up to 2000. Cost: three API operations behind one call, about 0.7s for a small run.

Delete a custom field by ID. Reach is workspace-wide: it disappears from every project, with the values entered for it, and this cannot be undone. To remove it from one project only, edit `projects_codes` with qase_custom_field_upsert. Asks the user for confirmation first. Cost: one API call, about 0.4s.

Create or update a custom field. On create, `entity` (case, run, defect) and `type` are required and fixed forever — the update endpoint cannot change them. Fields are workspace-wide; scope with `projects_codes` or is_enabled_for_all_projects. Read existing fields with qase_project_context or qase_get. Cost: one call to create, two to update, 0.5-0.9s.

Delete a defect by project code and ID; its links to results go with it and this cannot be undone. Usually resolving it through qase_defect_upsert with `id` is the right move, so the record survives. Asks the user for confirmation first. Cost: one API call, about 0.4s.

Create or update a defect: with `id` it updates, without it creates, and then `title`, `actual_result` and `severity` are required. Severity and status are labels ("blocker", "open"…), mapped for you. For a defect born from a specific test failure use qase_triage_defect; search with qql_search before filing a duplicate. Cost: one API call, about 0.5s.

Search the tool catalogue by what you are trying to do — "delete", "milestone", "review", "custom field" — and get back the matching tools with their descriptions. Every tool is already listed and callable; use this when you do not know which one fits, rather than re-reading the whole list. Cost: no API call, matching happens in memory, about 3ms.

Delete an environment by project code and ID. Runs that referenced it lose the attribution, so filtering history by that environment stops working; this cannot be undone. Asks the user for confirmation first. Cost: one API call, about 0.4s.

Create or update an environment — a named target such as staging or production that runs are attributed to. With `id` it updates, without it creates. Existing environments come back from qase_project_context. Cost: one API call, about 0.5s.

Link or unlink test cases and runs to issues in Jira Cloud or Jira Server — the only trackers supported. A case may link several issues; a run holds one, and a new link replaces it. Read links back with qase_get. Cost: one API call for the whole set of links, about 0.5s.

Fetch one known record by type and ID — case, suite, run, result, plan, defect, milestone, environment, shared_step, review, custom_field and more. Use it only when you already have the ID and want that one record; for several, anything filtered, or a loop over IDs, use qql_search — one search returns the whole page. Cost: one API call, 0.3-0.5s; ten in sequence measured 5.3s against 1.2s for one qql_search.

Delete a milestone by project code and ID. Runs and cases keep existing but lose the association, so release reporting built on it stops working; this cannot be undone. Asks the user for confirmation first. Cost: one API call, about 0.4s.

Create or update a milestone — a dated marker, typically a release, that runs and cases are grouped under. With `id` it updates, without it creates. Existing milestones come back from qase_project_context. Cost: one API call, about 0.5s.

Delete a test plan by project code and ID. Only the plan goes — its cases and the runs made from it stay — but anything launching it by ID breaks; this cannot be undone. To change its cases use qase_plan_upsert instead. Asks the user for confirmation first. Cost: one API call, about 0.4s.

Create or update a test plan — a named, reusable set of case IDs such as a smoke or regression pack. With `id` it updates, without it creates. qase_regression_run turns a plan into a run in one call. Cost: one API call, about 0.5s, growing with the number of cases.

Seed everything about a project in one call: details, the full suite tree, milestones, environments, custom fields and users — make it first when starting on a project. Each collection returns its first 100; check `coverage` and pass `full: true` to page. For one record by ID qase_get is cheaper; for filtered questions use qql_search. Cost: six API calls behind one, 0.5-1.3s cold, cached 5 minutes.

Create a project. The code must be unique in the workspace, and there is no update endpoint afterwards — title, code and access cannot be changed through the API, so choose them deliberately. Read an existing project with qase_project_context. Cost: one API call, about 1.5s.

Delete an entire project by code — every case, suite, run, result, defect and milestone in it, with no trash to recover from; this cannot be undone. The most destructive call in the API; confirm the code with qase_project_context first. Asks the user for confirmation and does not proceed without it. Cost: one API call, about 0.5s.

Build and start a test run from a suite, a plan, or an explicit list of case IDs, in one step — it resolves the cases itself. It opens a run, it does not close one: for a finished pipeline use qase_ci_report; to assemble a run by hand use qase_run_upsert. Cost: two API calls behind one, about 1s.

Delete one result from a run, by run ID and result hash. The case and the rest of the run are untouched; pass rates shift and this cannot be undone. To discard a whole run use qase_run_delete. Asks the user for confirmation first. Cost: one API call, about 0.4s.

Record up to 200 results into an existing run — status, duration, comment, stacktrace, attachments — in one call, not one per test. Status is a label only: passed, failed, blocked, skipped, invalid. If the run does not exist yet and the job is finished, qase_ci_report creates, records and completes in one call. Cost: one API call for the whole list, about 0.5s.

Open several test case reviews in one request — the batch form of qase_review_create, for proposing more than one change. Same fields as qase_review_create; `case_id` for an edit review, omitted for a create review. The API has no endpoints for approving, merging or declining — those are UI-only; read status with qase_review_list. Cost: one API call regardless of batch size.

Open a test case review — the pull-request flow for cases. Pass `case_id` to propose changes to an existing case (send only the fields that change), or omit it to propose a new one. Several at once? Use qase_review_bulk_create. The API has no endpoints for approving, merging or declining — those are UI-only; read status with qase_review_list. Cost: one API call, about 0.5s.

Delete a review by ID. This removes the proposal entirely — it does not decline it, and declining is UI-only — and merged reviews cannot be deleted; the referenced case is untouched. Cannot be undone; asks the user for confirmation first. Cost: one API call, about 0.4s.

List a project's reviews with their current state — the only way to learn what happened to a review you opened, since the API has no endpoints for approving or merging — those are UI-only. Filter by status to see what is still open. For one review by ID, qase_get is cheaper. Cost: one API call, about 0.5s.

Update an open review: the proposed case fields, the reviewers, or both, by review ID. IMPORTANT: changing the proposal RESETS every approval already given; updating only `reviewers` keeps them. The API has no endpoints for approving, merging or declining — those are UI-only; read status with qase_review_list. Cost: one API call, about 0.5s.

Mark a test run complete so it reports as finished. It is a reporting state, not a lock — results recorded afterwards still land and change its counts. If all results are in hand at once, qase_ci_report does this as its final step. Cost: one API call, about 0.4s.

Delete a test run by project code and ID, together with every result in it; this cannot be undone. Rarely what you want: to stop accepting results use qase_run_complete, to fix one result use qase_result_delete. Asks the user for confirmation first. Cost: one API call, about 0.4s.

Create or update a test run — the container results are recorded into, so open it before qase_result_record. Scope it to a milestone, environment, plan or case list. To build one from a suite or plan use qase_regression_run; for a finished CI job use qase_ci_report, which opens, records and closes in one call. Cost: one API call, about 0.5s.

Delete a shared step by project code and hash. Every case referencing it loses those steps, so the reach is far wider than one record; check references first. Cannot be undone; to change content use qase_shared_step_upsert instead. Asks the user for confirmation first. Cost: one API call, about 0.4s.

Create or update a shared step — a block of steps written once and reused across cases. With `hash` it updates, without it creates; shared steps are identified by hash, which qase_case_upsert takes in a step's `shared` field. Updating changes every referencing case. Cost: one API call, about 0.5s.

Delete a test suite by project code and ID. WARNING: the cases inside, and any child suites, are deleted with it along with their history, and `delete_cases` currently has no effect. Read the tree from qase_project_context and move what matters first. Asks the user for confirmation. Cost: one API call, about 0.4s.

Create or update a test suite — the folder cases live in. With `id` it updates, without it creates; nest with `parent_id`. The existing tree comes back from qase_project_context, so read it rather than guess parent IDs. Cost: one API call, about 0.5s.

Read the full documentation of one tool before calling it for the first time in a session. Every description in the tool list is deliberately short — what the tool is for and what it costs — and the details that prevent a wrong first call live here: argument semantics, limits, what cannot be undone, and which tool to use instead. Pass the tool name exactly as listed. Cost: no API call, static text, about 1ms. Cheaper than one rejected call.

Create a defect from a test failure with the context written into it; `title`, `actual_result` and `severity` are required. The API has no way to attach runs or results to a defect — reference them in actual_result. For a defect unrelated to a failure use qase_defect_upsert. Cost: one API call, about 0.5s; file one defect per distinct cause.

Read the QQL reference before writing a query. Pass a `topic`: overview, syntax, entities, operators, functions, examples, aggregation or enumValues. Field names differ per entity and from the write tools, and a query naming an unknown attribute is rejected — read `entities` first. Cost: no API call, about 2ms; cheaper than one rejected qql_search.

Search any entity with Qase Query Language — filtering, cross-project, sorting, aggregation — and the right way to fetch many records at once instead of looping over qase_get. Call qql_help first for syntax, fields and enum values. Use qase_get when you already know the one ID you want. Cost: one API call, 0.5-0.9s per page; ten records here cost 1.2s against 5.3s as ten qase_get calls.