api-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| scan_endpointsA | Recursively scans a project directory (React Native, web, Flutter, or backend) for API endpoints — fetch/axios/Dart-http/Dio client calls and Express/NestJS/Flask/FastAPI/Spring server routes. Writes a discovery report and endpoints.json. |
| detect_openapiB | Searches the project for an existing OpenAPI/Swagger document (swagger.json, openapi.yaml, etc.) and reports what was found. |
| generate_openapiA | Builds an OpenAPI 3.0 spec from discovered endpoints. If an existing spec is found and useExisting is true, it is loaded instead of regenerated. Writes the spec into the project's .api-mcp directory. |
| generate_testsA | Generates a test plan (happy-path, edge, negative, and security cases) for every discovered endpoint, based on its HTTP method and parameters. Writes tests.json. Does not execute anything. |
| run_testsB | Generates the test plan and executes it against the running server (like Postman). Saves full responses to results.json and a Markdown report. Requires baseUrl unless endpoints use absolute URLs. |
| full_auditA | One-call pipeline: scans for endpoints, generates/loads an OpenAPI spec, generates test + edge cases, executes them against the live server, and writes all reports. Provide baseUrl and auth so execution can reach the server. |
| export_reportA | Regenerates the HTML report and a colorful, multi-sheet XLSX spreadsheet from previously saved endpoints.json / results.json (in the project's .api-mcp folder). Use this to get shareable HTML/Excel output without re-running the tests. |
| detect_base_urlA | Scans config (.env), axios/Dart baseURL settings, and absolute URLs in the code to find candidate API base URLs. Works for web and mobile apps. QA can use the top candidate or override it. |
| loginA | Given a base URL and credentials, auto-detects the login endpoint, posts the credentials (trying email/username field variants), and extracts the token from the response. Returns the token and reports exactly what worked. |
| qa_auditA | The QA one-call workflow. Provide the project path and a list of role credentials (email/username + password). The tool detects the base URL and login endpoint, logs in as each role, runs the test suite per role (read-only by default), and writes a per-role + combined report. Set includeWrites=true only against a throwaway/staging env. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| qa-audit | Guided read-only QA audit: detects the API base URL + login endpoint, logs in as each role, tests every endpoint, and writes HTML/XLSX reports. |
| scan | Discover every API endpoint in the current project (web / React Native / Flutter) and write a discovery report. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 10 tools
Each tool has a clearly distinct purpose: detecting base URLs, detecting OpenAPI specs, scanning endpoints, generating specs, generating tests, running tests, logging in, full audit, QA audit, and exporting reports. Descriptions are detailed and unique, preventing confusion.
Most tool names follow a verb_noun pattern with snake_case (e.g., detect_base_url, generate_tests). A couple use compound nouns (full_audit, qa_audit) but still adhere to the overall lowercase underscore convention, making them predictable.
Ten tools cover the entire API auditing workflow without being excessive. Each tool addresses a specific step or role, making the set well-scoped for the domain.
The tools cover the full lifecycle: endpoint discovery, OpenAPI spec handling, test generation, execution, login, and reporting. No obvious gaps exist for the intended purpose of API testing and auditing.