The chain is the product: the spec drives scenarios, scenarios drive code in the framework you actually use, and the scaffolding tool leaves behind a project that runs on its own afterwards. Note the licence terms in the README — personal use and contributions are free, while commercial use or redistribution needs the author's permission.
An API testing server for QA work: ingest a specification, generate scenarios, turn them into executable tests, run them, and read the report.
- ingest_spec loads an OpenAPI or Swagger document, a Postman collection or a GraphQL schema, and takes your preferred language and framework at the same time
- It analyses the specification on ingest and tells you which environment values it is going to need
- set_env_vars supplies the base URL and credentials — bearer token, API key, basic auth, or your own named values
- generate_scenarios produces test scenarios, including negative cases and edge cases unless you turn them off
- generate_test_cases turns those into executable code in your chosen combination: TypeScript with Playwright or Supertest, JavaScript with Jest or Cypress, Python with pytest or requests
- get_supported_languages lists the available language and framework pairings
- run_api_tests executes them with a concurrency limit; run_load_tests runs a load profile with a user count, ramp-up and duration
- generate_project_files scaffolds a complete runnable project with dependencies, configuration, tests and a README
- get_session_status reports progress, and get_workspace_info and debug_file_system show where generated files land
- Reports come back as HTML through MCP resources, and two prompts cover writing a test plan and analysing failures
Python, with Node as well if you run it through npx. Credentials for the API under test are supplied through the environment tool rather than the specification. Generated files are written into your workspace.
One command — npx @kirti676/api-tester-mcp@latest
