MCP Tool Catalog

Certyn runs a remote MCP server over Streamable HTTP. It exposes 56 tools that read and write the same projects, test cases, runs, and issues you see in the app.

Endpoint

https://api.certyn.io/api/mcp

Manifest:

https://certyn.io/server.json

Auth model

• Transport: streamable-http
• Authentication: a user bearer token via Auth0/OIDC, or an API key in the X-API-Key header. A key is scope-limited, so pick the scopes deliberately: see choosing scopes.
• Prompts: supported. Five are advertised — setup_project, write_test_cases, run_gate, triage_failure, release_readiness.
• Unsupported: demo tokens, resources

For the pre-registered Claude, ChatGPT, and Cursor OAuth Client IDs and setup values, see Connect via MCP. The clients are public PKCE clients and do not use a client secret.

Common arguments

Most tools accept the same selectors:

• projectIdOrSlug: project ID or slug, resolved by Certyn server-side
• environmentKey: environment key such as staging or production. Call list_environments for a project's keys.
• testCaseId: Certyn test case ID
• ticketId: Certyn ticket ID, external issue ID, or project ticket number
• executionId: Certyn execution ID, returned by every run tool

Response conventions

So a response shape can be predicted rather than discovered:

• Collections are named after the entity. list_tickets returns tickets, list_test_cases returns testCases, list_environments returns environments. Listing and searching agree, so search_issues also returns tickets. The exception is a weekly plan, whose contents are items because "plan items" is what they are.
• Paging is page and pageSize, 1-based, defaulting to 50 and capped at 100. Tools that return an explicit top-N take limit instead, and daysBack is a time filter rather than paging. Paged responses carry totalCount and hasNextPage, so a truncated answer is distinguishable from a complete one.
• A detail tool returns everything its list tool returned, plus more. get_execution_detail carries the environmentKey and durationSeconds that list_executions shows, so drilling into a row never loses context.

All tools

Read tools carry the MCP read-only annotation, so a client can show you which calls are safe before it makes them.

---

Projects, environments, and context

list_projects

Lists projects visible to the current tenant user. No arguments.

Returns the same overview payload the app uses, including project IDs, slugs, default environment hints, onboarding status, and counts.

list_environments

Returns totalCount and hasNextPage alongside environments, so you can tell a complete answer from a truncated one.

list_env_vars

Secret values are masked: only the name is returned. Non-secret values are returned in full.

add_env_var

Fails if a variable with the same name already exists in that environment.

get_project_wiki

Returns overview, business logic, rules, common memory, Explorer memory, and lastEditedAt.

update_wiki

Each supplied section is replaced whole. Omitted sections are left unchanged.

---

Test cases

list_test_cases

get_test_case

search_test_cases

Semantic (vector) search by meaning, ranked by relevance, with a text-match fallback.

create_test_case

{
  "projectIdOrSlug": "acme-web",
  "name": "Checkout accepts valid cart",
  "instructions": "1. Add an item.\n2. Place the order.\nExpected: confirmation appears.",
  "description": "Smoke coverage for checkout.",
  "tags": ["checkout", "smoke"],
  "coverageKey": "checkout:valid-cart"
}

create_test_cases_batch

update_test_case

Updates only the fields supplied.

---

Issues

list_tickets

get_ticket

Returns status, severity, attachments, linked test case, latest run state, and external tracker metadata.

search_issues

Semantic search over a project's issues, with a text-match fallback.

search

Searches everything recorded for a project in one call: issues, test cases, past runs, learned memories, and the wiki. Each kind is matched both literally and semantically, and exact matches rank above semantic ones — so a friendly id like PROJ-142 or an exact title returns that record first.

Prefer search_issues or search_test_cases when you want one kind and need its filters.

Each hit carries type, id, title, excerpt, score, and exact, plus number, status, and severity for the kinds that have them.

create_ticket

Files a native Certyn issue. It does not create a remote Linear, Jira, or GitHub issue.

update_ticket

retest_ticket

Re-runs the agent against a shadow (agent-found) issue to confirm whether it still reproduces.

Returns the new executionId. Poll it with get_execution_detail.

---

Starting a run

list_processes

Lists a project's processes (test suites, agent explorations, and external-suite processes) with each one's latest run status. Use it to discover what run_process can execute.

run_process

Returns a processRunId. Poll it with get_process_run_status.

run_quick_test

Starts an ad-hoc exploratory test from a natural-language description.

Returns an executionId. Poll it with get_execution_detail.

run_test_case

Returns an executionId.

---

Results and evidence

get_process_run_status

Give one of processRunId or processName, or neither to list recent runs.

list_executions

get_execution_detail

Returns status, outcome, summary, artifacts, notes, and linked issues.

get_execution_transcript

The agent's messages, tool calls, and tool results, in order, so you can see exactly what it did and why.

Events are oldest-first within a page. Screenshot bytes are stored separately: fetch one with get_image_by_tool_id rather than pulling every image into the transcript.

get_debug_execution

Browser-side signal captured during a run: JavaScript console events and failed network requests. Use this to work out why an execution failed. For summary, artifacts and linked issues use get_execution_detail instead.

get_image_by_tool_id

Returns the image itself, so you can view one screenshot on demand.

---

Analysis

get_recent_failures

Triages recent failures in one call: failed executions in a window, each with its reason, any linked issues, and a flaky-versus-new classification.

get_project_stats

Test case counts, issue counts, pass rates, and recent session activity.

ask_certyn

Asks an open-ended question and returns a synthesized answer. Reach for it when no other tool answers the question directly: it pulls together the project's test cases, issues, failures, coverage, wiki, and run history to explain why something is happening or what the overall state is, rather than returning rows.

---

Weekly QA plan

get_weekly_plan

Returns each item's status and any linked runs.

propose_weekly_plan

Proposes a week of QA work for one environment. Gather evidence first with get_weekly_plan, get_recent_failures, and list_tickets. Proposing supersedes any open plan whose week overlaps.

update_weekly_plan

Items added to an already-approved plan are scheduled immediately.

approve_weekly_plan

Approving lets the plan's items self-execute at their scheduled times.

---

External test management

list_test_sources

Browses a connected TestRail, Zephyr Scale, Xray, or Azure Test Plans account.

A suite's id is the externalSourceId you pass to create_external_suite.

create_external_suite

Creates a reusable Certyn process that runs an external suite. Run it afterwards with run_process.

See Connect a Test Management Tool for the credentials each provider needs.

---

Conversations and coding tasks

list_conversations

get_conversation

get_coding_task_context

Returns the Certyn issue, reproduction result, evidence, and related runs for a coding task. Call it before implementing a coding-task fix.

---

Behavior notes

• All tool access is filtered to the current tenant and the signed-in user's permissions. MCP cannot reach anything you could not open in the app yourself.
• Project resolution accepts either a project ID or a slug.
• Write tools carry MCP write annotations, so a client can ask for confirmation before mutating project records.
• List limits are clamped server-side. Asking for more than the cap returns the cap.
• Run tools return an ID and finish immediately. Poll with get_process_run_status or get_execution_detail rather than waiting on the call.