End-to-end API testing — generate and run tests from OpenAPI, curl, Postman, or real user traffic.
Listed on
First seen 2 Oct 2026. One server, whatever directories list it: each directory listing keeps its own page and history.
2
Directories
Collected by InvokeRank
7
Tools
From an anonymous probe
-
ToolBench grade
Not graded by Arcade
18,537
GitHub stars
From MCP Toplist
Tools
| Tool | Description | Behaviour |
|---|---|---|
| devloop_begin_oauth_install | Start the Path B agent-walked install for the V1 flow. Returns a playbook the AI walks with the dev to land a kep_* PAT in their editor's MCP config. Current implementation routes through app.keploy.io/settings/api-keys (the existing PAT-issuance surface). The full auto-provision OAuth round-trip (browser OAuth → /auth/temp-code/exchange → /user/mcp/provision → PAT auto-pasted) lands when the enterprise-ui /auth/cli-install page is built; this tool's interface won't change when that lifts, only the underlying steps will get shorter. ABSOLUTE: this tool surfaces a public URL. Do NOT print API keys, PATs, or OAuth tokens to the conversation. The dev pastes the secret into their editor config directly; the agent never sees it. | Destructive |
| devloop_setup_instructions | Return the V1 "user maintains the flow" install guide — covers Path A (clipboard one-liner), Path B (agent-walked OAuth), and the keploy/api-tests/ on-disk layout V1 creates. Safe to call without authentication; call this when the dev asks 'how do I add Keploy to this repo?' or when a devloop_* tool returns missing-API-key. | Destructive |
| get_auth_status | Check whether the current MCP session has a valid-looking Keploy PAT attached. Returns { authenticated, auth_header_present, hint }. Useful as a first step for an agent to decide whether to call other tools or show setup instructions — differentiates 'no header at all' from 'header present but wrong prefix / unsupported format'. | Destructive |
| get_setup_instructions | Return step-by-step instructions for connecting this MCP server to Cursor, Windsurf, VS Code, Claude Desktop, Claude Code, or Trae. Safe to call without authentication — use this when the user asks 'how do I set up Keploy MCP?' or when a tool call fails with an auth error. | Destructive |
| get_tool_schema | Fetch the exact schema(s) for tool(s) you ALREADY know by name — e.g. names a skill/playbook gave you (getTestReportFull, updateTestCase, listTestReports, getMock, getTestCase, getApp, listApps, ...). Returns ONLY the named tools: no fuzzy matching, no unrelated tools. Use this instead of search_tools whenever you know the name — it is exact and cheap. Use search_tools only to DISCOVER names you do not already know. Returns {"tools": [{name, description, inputSchema}, ...], "not_found": [names...]}. | Destructive |
| invoke_tool | Run any Keploy tool by name. Most tools are hidden from the default list. Know the name from a skill? get its schema with get_tool_schema; don't know the name? discover it with search_tools. Then call invoke_tool with that name and an "arguments" object matching the tool's inputSchema. Example: invoke_tool {"name": "getTestReportFull", "arguments": {"appId": "...", "testRunId": "...", "fields": ["status"]}} | Destructive |
| search_tools | DISCOVER tool names you do NOT already know, by keyword. Most Keploy tools are hidden from the default tool list to save context. If you ALREADY know the exact name (e.g. a skill named it), call get_tool_schema instead — it is exact and far cheaper than this fuzzy search. Returns {"matches": [{name, description, inputSchema}, ...], "total_catalog": N}. Search by intent words, e.g. "test report", "mock patch", "update test case", "cloud replay branch", "record". | Destructive |