Certyn runs a remote MCP server. Sign in from Claude, ChatGPT, Cursor or any MCP client and the tools read and write the same projects, test cases, runs and issues you see in the app.
What it is
There is no gateway to deploy and no token to rotate. The connection is a URL and the Certyn account you already have.
Point your client at one URL
Certyn hosts the server. It speaks streamable HTTP over TLS, so there is nothing to install next to your editor and nothing to keep running.
https://api.certyn.io/api/mcp
You sign in, not a service account
The client opens the normal Certyn login. Claude, ChatGPT and Cursor have pre-registered clients; anything else registers itself on first connect.
openid · profile · email · offline_access · mcp
It sees exactly what you see
One connection reaches any project or environment your own account can already reach, and nothing beyond it. Tools take a project when the context matters.
It can change things, not only read them
Write a test case, file an issue, start a run, update the project wiki. Everything it does lands in the same records your team works from.
Cursor reads this from your user or project mcp.json. Claude and ChatGPT take the same server URL as a custom connector.
Before you start
{
"mcpServers": {
"certyn": {
"url": "https://api.certyn.io/api/mcp",
"auth": {
"CLIENT_ID": "tpc_jZgoggfpgCQ6q2ZwHeEr2B",
"scopes": [
"openid", "profile", "email", "offline_access", "mcp"
]
}
}
}
}Then try: "list my Certyn projects, run a quick test of the signup flow on staging, and tell me what failed". The Claude and ChatGPT connector IDs are in the setup guide.
A run started from an editor is not a side channel. It lands in the same activity list as a scheduled run or a CI run, with the same evidence attached.
These are direct record tools, not a chat wrapper. The client calls them and gets structured data back.
Projects and environments
list_projects, list_environments, list_env_vars, add_env_var.
Test cases
list_test_cases, get_test_case, search_test_cases, create_test_case, create_test_cases_batch, update_test_case.
Starting a run
run_quick_test, run_test_case, run_process, get_process_run_status.
Results and evidence
list_executions, get_execution_detail, get_execution_transcript, get_image_by_tool_id.
Issues
list_tickets, get_ticket, search_issues, create_ticket, update_ticket, retest_ticket.
What the project knows
get_project_wiki, update_wiki, get_recent_failures, get_project_stats, ask_certyn.
No. The connection uses OAuth against your Certyn account, the same login you use for the app. There is no client secret to store and no key to rotate. If you want a key for CI, that is a separate thing with its own scopes.
Exactly what your own account can reach, across the whole tenant. One connection covers every project and environment you have access to; tools take a project when the context matters. It cannot see anything you could not open in the app yourself.
Both. It can create and update test cases, file and update issues, start runs, and write the project wiki. Read tools are marked read-only so a client can show you which calls are safe before it makes them.
Claude, ChatGPT and Cursor have pre-registered client IDs, so they connect with the server URL alone. Any other MCP client registers itself on first connect through dynamic client registration.
No. The server is remote and speaks streamable HTTP over TLS. There is no stdio bridge, no sidecar process and nothing to keep alive on your machine.
Not in v1. The server is tool-only. Everything is exposed as a tool call, which is what every current client supports well.
Connect via MCP
Server URL, pre-registered client IDs, scopes and the setup flow.
MCP tool catalog
Arguments and response shapes for each tool.
Ask Certyn skills
What the assistant can answer, and the evidence it answers from.
For AI teams
The full loop: the agent writes, Certyn checks the running app.
Start on the free tier, no card. Connect a client in about two minutes.