You give us the repo. We build & maintain your API test suite.

TestingForge reads your code, generates a structured API test suite, runs it in CI, and proposes updates whenever your API changes — with a human reviewer in the loop.

API-first. No browser/UI tests. No empty collections to fill in by hand.

AI-native control plane · MCP

Turn your IDE into a TestingForge operator

TestingForge MCP is not API documentation. It exposes real tools, guided workflows, and scoped actions so your AI assistant can work inside your workspace—not read OpenAPI and guess the next HTTP call.

Your AI can inspect bricks, edit scenarios, start runs, read results, and follow the same paths your team uses in the app.

Connect Cursor Read the docs hosted v0.7.0 · zero install

The problem it solves

You already use AI in the editor for code. TestingForge lives elsewhere: bricks, environments, runs, CI keys, SCM links. Copying curl from Swagger and pasting JSON by hand does not scale—and it does not teach the model how your team actually works.

API docs alone

Raw endpoints, no workflow context
You write every request body
No brick guides, stage rules, or org scoping baked in
Easy to call the wrong environment or miss a required field

TestingForge MCP

Named tools: workspace_list_bricks, workspace_start_run, …
Built-in guides: mcp_guide, brick_guide, workspace_guide
Actions map to the same Machine API the product uses
Hosted—no SDK, Node server, ZIP, or wrapper repo

What you get

Connect Cursor, Claude Desktop, ChatGPT, or any MCP client. One workspace key, structured access, tools that ship with the product.

Operate, don’t integrate

AI calls tools meant for testing work: list bricks, patch a step, import curl, start a run, poll status, read failure causes—not generic HTTP.

Guides built in

brick_guide explains fields and auth profiles. scm_guide walks repo linking. The model gets context before it acts.

Scoped to your org

Same TF_API_KEY as CI. Every tool runs as your workspace with role checks—no shadow admin channel beside the product.

Always current

We host the server. New tools and guide updates land when we deploy—you do not reinstall a local package.

Escape hatch when needed

machine_api_routes lists the surface area; machine_api_request covers edge paths. Prefer the named tools when they exist.

Five-minute setup

Export one key, paste one mcp.json, restart the IDE. No clone of this app repo required for your product workspace.

Brick authoring Run & debug SCM & CI snippets Pulse checks Secrets & domains

How it works

One hosted endpoint. Your IDE speaks MCP; we translate tool calls into the same backend your team uses in the browser.

Get a workspace key Generate TF_API_KEY in CI & Notifications. It ties MCP to one organization, same as pipelines.
Point your MCP client at TestingForge Remote URL https://testingforge.io/mcp/server and Bearer auth. We run the server; you do not.
Start with guides In Agent, run mcp_guide so the model learns available tools and safe patterns before changing data.
Work in plain language Ask for bricks, runs, or analysis. The assistant picks tools, you approve calls, results stay in the thread.

Example prompts

After mcp_guide, try prompts like these in Cursor Agent or any MCP host:

Run mcp_guide, then list bricks in my default scenario grouped by section.

Import this curl into a new brick in the smoke group and try it against staging.

Start a workspace run on domain 12 with scenario Jamworks and summarize progress until it finishes.

Show the last three failed runs and group failures by cause_totals.

Walk me through linking a GitHub repo and paste the CI snippet for the first connection.

Explain auth_profile options for ED3P bricks before I patch brick 440.

FAQ

Is this the same as your REST API docs?

No. OpenAPI describes endpoints. MCP exposes tools—higher-level actions with descriptions, guides, and guardrails. Use API docs when you are writing integration code; use MCP when you want AI to operate TestingForge.

Do I need to install Node or download anything?

No. The MCP server is hosted at https://testingforge.io/mcp/server. You only configure your IDE and set TF_API_KEY.

Which clients are supported?

Any MCP host with remote HTTP support—Cursor, Claude Desktop, and others that accept url + headers in mcp.json.

How is access controlled?

Your CI API key authenticates every call. Tools respect the same organization boundary and roles as the Machine API. Treat the key like a password; regenerate if it leaks.

Will new product features show up in MCP?

Yes. We add tools and refresh guides on deploy. You keep the same connection string—no local package to bump.

Can the AI change production data?

It can only do what your key allows—typically the same mutations you could make in the workspace UI. Use staging domains, optional bricks, and Cursor’s tool approval. Review destructive tool calls before they run.

Connect your IDE in a few minutes

Export your key, add the config, restart Cursor. Your assistant becomes a TestingForge operator—not a passive reader of API docs.

Get connection details Sign in

Connection details

Hosted endpoint: https://testingforge.io/mcp/server. Recommended: ${env:TF_API_KEY} in app/.cursor/mcp.json when you work in this repository.

Connect your IDE to the TestingForge control plane — structured tools and guides, not raw API docs. Same TF_API_KEY as CI; hosted, no local install. About MCP · Docs

https://testingforge.io/mcp/server

Get your CI API key — Workspace → CI & Notifications → Generate or copy tf_… (shown once after regenerate).
Expose the key to Cursor — In a terminal: export TF_API_KEY='tf_…', then start Cursor from that terminal — or add the export to your shell profile. Cursor launched from the Dock does not see one-off exports.
Add MCP config — Copy mcp.json below into ~/.cursor/mcp.json or use the project file app/.cursor/mcp.json when you open the repo. Settings → MCP (Cmd+Shift+J) → enable testingforge.
Restart and verify — Quit Cursor completely, reopen, open Agent and run mcp_guide. Then try workspace_list_bricks or get_organization.

1. Shell export (recommended)

export TF_API_KEY='tf_…'

Then launch Cursor from that terminal, or add the line to ~/.zshrc.

2. `mcp.json` (uses `${env:TF_API_KEY}`)

{
    "mcpServers": {
        "testingforge": {
            "url": "https://testingforge.io/mcp/server",
            "headers": {
                "Authorization": "Bearer ${env:TF_API_KEY}"
            }
        }
    }
}

Save as ~/.cursor/mcp.json or use committed app/.cursor/mcp.json in this repo.

Alternative: paste key directly into JSON (no env var)

Only if Cursor cannot read TF_API_KEY. Do not commit this file with a real key.

{
    "mcpServers": {
        "testingforge": {
            "url": "https://testingforge.io/mcp/server",
            "headers": {
                "Authorization": "Bearer <paste CI API key from this page>"
            }
        }
    }
}

Try in Agent:

mcp_guide
brick_guide
workspace_guide
scm_guide
get_organization
workspace_list_bricks

Troubleshooting

401 Unauthorized — Wrong or missing key. Regenerate in CI & Notifications if unsure, update TF_API_KEY, restart Cursor.
MCP server not listed / tools missing — Full quit and reopen Cursor. Check Settings → MCP that testingforge is on. Confirm TF_API_KEY is set in the environment Cursor inherits.
Connection failed / 404 — Endpoint must be https://testingforge.io/mcp/server (hosted prod). Local localhost only works if you run the Laravel app yourself — Cursor users normally use prod.
Key worked yesterday — Regenerate invalidates the old key immediately. Update CI secrets, TF_API_KEY, and any hardcoded Bearer values.

Security: never commit TF_API_KEY to git. Regenerating the key in the UI or via regenerate_ci_api_key invalidates the previous key immediately. Sign in to generate a key.