Call any Qase REST endpoint directly, for the few things no dedicated tool covers. Pass the HTTP method, a path starting with a version segment such as /v1/, and an optional body or query. The path must be an endpoint path on the configured Qase host; a full URL, or one that resolves to another host, is refused. See developers.qase.io for the reference. Prefer a dedicated tool wherever one exists: they normalize enums, validate arguments before spending a round trip, and shape the response for a model. This one hands back whatever the API returns. It sends JSON only and cannot upload files — multipart uploads go through qase_attachment_upload. A DELETE through this tool asks for confirmation the same way the dedicated delete tools do. Cost: one API call, typically 0.3-1.5s depending on the endpoint. No caching, no pagination help, no retries beyond the client defaults.

Upload files and get back the hashes that other tools reference them by — screenshots, logs, HAR files, videos. For one file pass file_base64 with the base64-encoded bytes, or file_path with an absolute path, plus filename with its extension. For several, pass files — one entry per file, each with its own filename — and they go up in a single request, hashes returned in the same order. Use file_base64 unless the server runs on the same machine as the file: a remote server, the hosted connector included, cannot see your filesystem, and file_path will simply not find the file. Qase accepts at most 20 files, 32 MB per file and 128 MB per request; a request over any of those is refused here before anything is sent, so split it across calls. The returned hash is what goes in the attachments field of qase_case_upsert, qase_result_record, qase_defect_upsert or qase_triage_defect — uploading alone attaches nothing, the hash has to be passed on. This is the only tool that sends multipart/form-data, which is why qase_api cannot send them. Upload once and reuse the hash rather than re-uploading the same evidence per case. Cost: one API call per request whatever the number of files, dominated by total size rather than round trip — well under a second for a screenshot, seconds for a video. Base64 inflates the payload by about a third.

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. Takes a list of cases with the same fields and the same enum handling as qase_case_upsert: labels ("high", "blocker") or numeric IDs both work, steps classic or Gherkin. The batch is validated as a whole, so an invalid item means nothing is created, and each item is then reported individually. Returns the IDs in the order submitted. This creates only; to change an existing case use qase_case_upsert with its id. Cost: one API call regardless of batch size. Ten cases measured 1.2s here against 5.6s as ten separate qase_case_upsert calls — four times faster and one tenth of the calls. Split larger imports across several calls.

Create or update a single test case. With id it updates that case, without id it creates a new one. Enum fields (priority, severity, type, layer, behavior, automation, is_flaky) accept either a label such as "high" or "blocker" or the project's numeric ID — the server normalizes both. Steps can be classic action/expected pairs or Gherkin, and may reference shared steps by hash. Writing more than one case? Use qase_case_bulk_create instead: it takes a list and sends one request. If the project has "Test case review" enabled, direct writes may need to go through a review — run qase_discover_tools with "review" for those tools. Cost: one API call, about 0.6s to create and 0.4s to update. Ten sequential calls measured 5.6s against 1.2s for one qase_case_bulk_create writing the same ten, so a loop is roughly four times slower.

Report a whole CI run in one call: creates the run, records every result, and completes it. This is the tool for a pipeline that has just finished — it replaces qase_run_upsert, then qase_result_record, then qase_run_complete, and leaves no half-open run behind if the agent stops early. Each result needs a numeric case_id plus a status, and may carry duration, comment, stacktrace and attachment hashes. Use qase_result_record instead when the run already exists and results arrive in stages; use qase_run_upsert when you need the run left open. A batch larger than 200 is split across requests for you, up to 2000 results in one report. Cost: one tool call covering three API operations, plus one extra request per 200 results. A run with two results measured about 0.7s, against roughly 1.5s for the same work as three separate calls, and it grows with the number of results rather than with the number of round trips.

Create or update a defect — a tracked problem found by testing. Without id it creates, with id it updates. Creating one requires title, actual_result and severity; the API rejects a defect missing any of the three. Severity is given as a label ("blocker", "critical", "major", "normal", "minor", "trivial") and the server maps it to the workspace's numeric ID, custom options included. Status is a label too ("open", "in_progress", "resolved", "invalid") and passes through as written; setting it to "resolved" on an existing defect goes through the dedicated resolve endpoint. When the defect comes from a specific test failure, use qase_triage_defect instead. The API has no way to attach runs or results to a defect, so reference the failing results in the text rather than expecting a link. Find existing defects with qql_search before filing a duplicate. Cost: one API call, about 0.5s, plus a cached lookup of the severity options.

Find and switch on tools that are hidden by default. Only core tools appear in the tool list; deletes, test plans, milestones, environments, shared steps and parameters, external issue links, case reviews, and project and custom-field management all exist but stay hidden until discovered. Search by what you are trying to do — "delete", "milestone", "plan", "review", "custom field" — and matching tools are activated and become callable. Every word in the query must appear in a tool's name or description, so prefer two or three words over a sentence. Activation is announced to your client with notifications/tools/list_changed: if a tool listed as activated here is still absent from your tool list, your client did not act on that notification — call the same endpoint through qase_api rather than reporting the capability as missing. Never conclude a capability is missing without searching here first. Cost: no API call, matching happens in memory, about 3ms. Free to call as often as needed.

Fetch one known record by type and ID: case, suite, run, result, plan, defect, milestone, environment, shared_step, shared_parameter, configuration, attachment, author, user, review, or custom_field. code is required for project-scoped entities and can be omitted for global ones (user, author, attachment, custom_field). Narrow the payload with fields, or pass ["*"] for everything. Use this only when you already know the ID and want a single record. For several records, for anything filtered or cross-project, or when you are about to call this in a loop, use qql_search instead — one search returns the whole page at once. Cost: one API call, 0.3-0.5s. Ten of these in sequence measured 5.3s against 1.2s for a single qql_search returning the same ten records, so a loop over IDs is roughly four times slower and ten times more calls.

Seed everything about a project in one call: project details, the full suite tree, milestones, environments, custom fields, and users. This is the first call to make when starting work on a project — it replaces six separate list calls and gives the model the metadata it needs to build any later query. Each collection returns its first 100 entities; the coverage field reports { total, loaded, truncated } per collection, so check it before assuming a list is complete, and pass full: true to page through everything. For a single record you already have the ID for, qase_get is cheaper; for filtered or cross-project questions, use qql_search. Cost: six API calls behind one tool call, 0.5-1.3s cold, and 16-48KB of response depending on project size. Cached for 5 minutes, so repeat calls inside that window return in about 5ms. full: true costs one extra call per 100 entities and can return thousands of items.

Build and start a test run from a suite, a test plan, or an explicit list of case IDs, in one step. Use it to launch a regression cycle without first querying for cases and then creating a run around them — give it the source and it resolves the cases itself. For a run you assemble by hand, use qase_run_upsert and pass the case IDs. For a pipeline that has already finished and just needs its results filed, use qase_ci_report instead: this tool opens a run, it does not close one. Cost: two API calls behind one tool call — resolving the source, then creating the run — roughly 1s, growing with the number of cases the source resolves to.

Record up to 200 results into an existing run. A case says what should be tested; a result says what happened when it ran — status, duration, comment, stacktrace, attachments — so a result always needs a run to live in. Pass several results in one call rather than calling once per test: the tool takes a list and sends them together. 200 is the ceiling for one call, and a longer list is refused before anything is written — split it into consecutive calls rather than dropping the tail. If the run does not exist yet and this is a finished CI job, qase_ci_report is the single call that creates the run, records the results and completes it, and it splits a larger batch for you. Status is a label, one of "passed", "failed", "blocked", "skipped" or "invalid" — unlike the case enums, numeric IDs are not accepted here. Cost: one API call for the whole list, about 0.5s for a small batch, growing with payload rather than with the number of results.

Mark a test run as complete so it reports as finished rather than in progress. Call it once the results are in; a run left open keeps showing as running and skews dashboards and any "is the release ready" question asked later. Note that completing does not seal the run: the API still accepts results recorded into it afterwards, and they change its counts, so completion is a reporting state rather than a lock. If the results are all in hand at once, qase_ci_report does this as its final step and you do not need this call. Cost: one API call, about 0.4s.

Create or update a test run. Without id it opens a new run; with id it updates that one. A run is the container results are recorded into, so open it before calling qase_result_record. Optionally scope it to a milestone, an environment, a plan, or an explicit list of case IDs. To build a run from a suite or plan without listing cases yourself, use qase_regression_run. For a CI job that has already finished, use qase_ci_report instead — it opens the run, files the results and closes it in one call, so no half-finished run is left behind. Cost: one API call, about 0.5s.

Create or update a test suite — the folder cases live in. Without id it creates, with id it updates. Nest a suite by passing parent_id; the whole existing tree comes back from qase_project_context, so read that first rather than guessing at parent IDs. Building a deep tree means one call per node, so create parents before children and reuse the IDs returned. Cost: one API call, about 0.5s.

Create a defect from a test failure, with the failure context written into it. Requires title, actual_result and severity — the API rejects a defect missing any of the three. Note: the API offers no way to attach existing runs or results to a defect. The runs and results seen on a defect in the UI are populated by the test runner when it reports a result as a defect, so there is nothing to pass here for that — reference the failing results inside actual_result instead, and do not expect a link to appear. For a defect unrelated to a test failure use qase_defect_upsert. Cost: one API call, about 0.5s. Triaging a whole run means one call per defect, so cluster identical failures and file one defect per distinct cause rather than one per failed test.

Read the QQL reference before writing a query. Pass a topic: overview, syntax, entities, operators, functions, examples, aggregation, or enumValues. entities lists the fields each entity actually exposes, and enumValues gives the accepted values for status, priority, severity and the rest — both matter, because QQL rejects a query naming an attribute that does not exist on the entity rather than ignoring it, and the field names differ from those in the write tools. Read this once per session before the first qql_search rather than guessing and retrying. Cost: no API call, static text, about 2ms. Free to call, and cheaper than one rejected query.

Search any entity with Qase Query Language: filtering, cross-project queries, sorting, and aggregation. This is the right tool for every question that is not "give me this one record by ID" — "cases without automation", "results that failed this week", "open blockers across projects" — and the right way to fetch many records at once instead of looping over qase_get. Call qql_help first for the syntax, the fields available per entity, and the enum values; a query naming an unknown attribute is rejected outright. Use qase_get instead when you already know the entity and its ID and want just that one. Cost: one API call. 0.5-0.9s for pages up to 50 records; a page of 100 measured 0.9-2.8s depending on how much each record carries. Prefer one search over N single fetches: the same ten records cost 1.2s here against 5.3s as ten qase_get calls.