Detects Angular HttpClient calls to discover API endpoints in Angular codebases.
Detects axios HTTP requests, including custom instances, to discover API endpoints.
Detects http, Dio, Retrofit-dart, and Chopper calls in Dart code to discover API endpoints.
Reads .env files to auto-detect the API base URL.
Detects Express router routes to discover server-side API endpoints.
Detects FastAPI route decorators to discover API endpoints.
Detects Fastify router routes to discover API endpoints.
Detects Flask route decorators to discover API endpoints.
Detects http, Dio, and other HTTP calls in Flutter apps to discover API endpoints.
Detects jQuery $.get, $.post, $.ajax calls to discover API endpoints.
Detects Koa router routes to discover API endpoints.
Detects Retrofit @GET and other annotations in Kotlin code to discover API endpoints.
Detects NestJS decorators (@Get, @Post, etc.) to discover API endpoints.
Detects Spring @GetMapping, @PostMapping, etc., to discover API endpoints.
Detects Alamofire requests in Swift code to discover API endpoints.
Detects SWR hook usage to discover API endpoints.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@api-mcp Run a QA audit on this project with role logins."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
š¦ Published on npm:
@hassanjamal/api-mcpā install withnpm i -g @hassanjamal/api-mcp(no cloning or building needed).
An MCP (Model Context Protocol) server you plug into any codebase ā React Native, web, Flutter, or a backend ā that:
Discovers every API endpoint in the code (client calls and server routes)
Reads or generates an OpenAPI / Swagger spec (if none exists, it builds one)
Generates test cases + edge cases for each endpoint, based on its HTTP method and params
Auto-logs in per role (from just credentials ā finds the login endpoint, extracts the token)
Harvests real IDs from responses + JWTs and injects the right resource id into each path param
Executes them against your running server ā like Postman ā scoped to each role's real permissions
Reports everything as PDF + XLSX (per-role + an overall audit + the endpoint inventory)
The QA one-call (qa_audit) does all of it from a project path + role logins. All artifacts are
written to a .api-mcp/ folder inside the project you point it at.
Platform | Frameworks / libraries detected |
Web |
|
React Native |
|
Flutter / Dart |
|
Mobile native | Retrofit (Android/Kotlin |
Backend routes | Express / Fastify / Koa |
Detection is text/pattern based, so it works on any language without running the code, and
handles both :param / {param} / <param> styles and JS ${...} / Dart $var interpolation.
Every framework above is covered by the regression suite (npm test) so accuracy can't silently
regress.
Related MCP server: REST API MCP Server
Install once, globally ā this gives a fast, reliable api-mcp command:
npm i -g @hassanjamal/api-mcpRequires Node.js 18+. Global install is recommended over
npxbecausenpxre-checks the registry on every launch (~6s) and can trip a host's connection health-check; the global binary starts in ~1s.
An MCP server does nothing on its own ā a host (the app you chat with an AI in) connects to it and exposes its tools. Pick your host:
Register it once for all your projects (user scope):
claude mcp add -s user api-mcp -- api-mcpVerify: claude mcp list ā api-mcp - ā Connected. (Mind the spacing: -- api-mcp.)
Settings ā MCP ā Add new server, or edit ~/.cursor/mcp.json:
{
"mcpServers": {
"api-mcp": { "command": "api-mcp" }
}
}Edit claude_desktop_config.json (Windows: %APPDATA%\Claude\claude_desktop_config.json):
{
"mcpServers": {
"api-mcp": { "command": "api-mcp" }
}
}Restart the host after editing config. The tools (and the /qa-audit, /scan slash commands)
then appear to the AI.
Updating: npm i -g @hassanjamal/api-mcp@latest
Two guided entry points show up as slash commands:
Command | Does |
| Prompts for base URL + role logins, then runs the full read-only per-role audit |
| Scans the current project and summarizes the endpoints found |
You can also just ask in natural language (see below) ā the slash commands are a convenience.
Tool | What it does |
| Scan a project and list every endpoint found. Writes |
| Report any existing Swagger/OpenAPI spec in the project. |
| Build an OpenAPI 3.0 spec from the code (JSON or YAML). Reuses an existing spec unless told otherwise. |
| Produce happy-path / edge / negative / security test cases. Writes |
| Execute the tests against your live server and save responses + a report. |
| One call that runs the entire pipeline end-to-end. |
| Regenerate the HTML report + colorful XLSX from already-saved JSON. |
| Auto-detect the API base URL from |
| Auto-detect the login endpoint, post credentials, and extract the token. |
| QA one-call: role credentials ā auto-login ā role-scoped, precise-ID testing ā PDF + XLSX reports. |
Once connected, just ask the AI in natural language, e.g.:
"Run a full API audit on this project against http://localhost:3000 using my API_TOKEN."
The AI will call full_audit with the right arguments.
A QA engineer provides only credentials per role ā the tool figures out the rest (base URL, login endpoint, token extraction, per-role runs):
"Run a qa_audit on this project with admin
a@x.com / pw, teachert@x.com / pw, students@x.com / pw."
qa_audit then:
Detects the API base URL from the code (.env, axios/Dart baseURL) ā or you pass baseUrl
Logs in as each role, extracting the token from the response or the JWT (token, accessToken, data.token, jwtā¦)
Harvests real resource IDs from every response + each JWT and injects the correct id into each
path param ({courseId} ā a real course id; a bare {id} ā that endpoint's own resource), preferring
ids the current role can access ā turning wrong-id 404s into real 200s
Scopes each role to endpoints its route-guard permits (reads authorizeAdmin(), @Roles('teacher')ā¦),
so you get more 200s and far less 403/404 noise
Skips session-breaking endpoints (logout/refresh/delete-account/password/register) so a test can't revoke its own token, and paces around rate limits (marks throttled requests not tested, not failed)
Writes PDF + XLSX only ā overall qa-audit.pdf, per-role qa-report-{role}.pdf/.xlsx, and
endpoints.pdf/.xlsx
Read-only by default. Useful arguments:
Argument | Default | Effect |
| ā |
|
| auto-detect | API base URL |
|
| also run POST/PUT/PATCH/DELETE (throwaway/staging only) |
|
| test each role only on endpoints its guard permits ( |
|
| also test logout/refresh/delete-account/password/register |
|
| max pacing wait per request; raise (e.g. |
The tool always tests the HTTP API, so the inputs are the same for both. The only difference is which source files get scanned for endpoints.
Web app | Mobile app (React Native / Flutter / native) | |
Provide | API base URL* + role credentials | API base URL* + role credentials ā same |
Base URL source | frontend | the app's config/constants (the backend it calls) |
What's scanned | JS/TS ( | Dart ( |
Execution | identical | identical |
A healthy API returns a mix of status codes under automated testing ā that's it correctly guarding itself, not a sign it's broken. Each request passes gates in order; the status tells you which gate stopped it:
Status | Meaning | A problem? |
200 | Worked ā returned data | ā success |
400 | Request incomplete/malformed (missing query param, wrong id type) | ā No ā validation working |
401 | Wrong identity for that endpoint | ā No ā auth working |
403 | Role/owner not permitted | ā No ā RBAC working (the inverse curve across roles proves it) |
404 | That resource doesn't exist for this user | ā No ā correct "not found" |
500 | Server crashed (unhandled exception) | š“ Yes ā the real bug to fix |
You can't (and shouldn't) get all-200s from automated testing ā that would mean the API accepts
anything. Only the 500s indicate actual defects.
*The base URL is auto-detected when possible; a mobile app has no "app URL" of its own ā you give the backend API URL it talks to (which lives in the app's config).
Live execution needs to know your server URL and auth. Provide it either per tool call
(baseUrl, bearerToken, headers arguments) or via a config file in the target project root.
Copy api-mcp.config.example.json to api-mcp.config.json:
{
"baseUrl": "http://localhost:3000",
"bearerToken": "${API_TOKEN}",
"headers": { "X-Api-Key": "${API_KEY}" },
"timeoutMs": 15000,
"sampleValues": { "id": 1, "body": { "name": "example" } }
}${ENV_VAR} references are expanded from the environment, so secrets stay out of the file.
Secret-looking headers are redacted in saved reports.
.api-mcp/)File | Contents |
|
File | Contents |
| Overall report ā KPIs, role matrix, and a "how to read the statuses" guide |
| Per-role results (status summary + full request/response table) |
| The discovered-endpoint inventory |
The other tools (scan_endpoints, generate_openapi, run_tests, full_audit) also write:
File | Contents |
| Endpoint inventory (Markdown + color-coded web page) |
| Structured endpoint list |
| Generated OpenAPI 3.0 spec (open in https://editor.swagger.io) |
| The full generated test plan |
| Pass/fail summary + status codes + failure details |
| Colorful multi-sheet spreadsheet ā Summary, Endpoints, Test Results |
| Full request/response record for every test |
.html reports are self-contained (no internet needed), color-coded by result and status
code, and adapt to light/dark themes. Just double-click to open in any browser.
test-report.xlsx is a styled workbook with three sheets:
Summary ā totals, pass/fail counts, and a status-code distribution
Endpoints ā every endpoint with method color badges
Test Results ā one row per test with complete data (request/response bodies, headers, status, duration, errors), color-coded green/red/amber, with auto-filters enabled.
Open it in Excel, Google Sheets, or LibreOffice. Secret-looking header values are redacted.
Already have results.json from a previous run and just want the pretty output? Ask the AI to
run export_report ā it rebuilds the HTML + XLSX from the saved JSON without re-running anything.
happy-path ā valid request with sample params/body; expects success
edge-case ā non-existent resources, malformed params, empty bodies
negative ā malformed JSON, wrong HTTP method (expects 4xx/405)
security ā same request with credentials stripped (expects 401/403)
git clone https://github.com/Hassan-Jamal/Automated_API_MCP.git
cd Automated_API_MCP
npm install
npm run build # compile to dist/
npm test # 63 tests: detectors, scanner, auth, schema, harvesting, PDF, etc.The examples/sample-app/ folder has JS, Dart, and Express files demonstrating the detectors.
Depends on the step:
Step | App/server running? |
Scan, generate Swagger, generate tests | No ā reads source code statically |
Execute tests ( | Yes ā sends real HTTP requests |
For a React Native or web app, what must be running is the backend API server the app
talks to (e.g. http://localhost:3000) ā not the emulator or the web frontend. This tool
calls the API directly, the same API your app calls. Point baseUrl at that server.
If your project is the backend (Express/NestJS/FastAPI/Flask), start it, then run the tests.
Tip: use
dryRun: trueonrun_teststo preview the requests without sending any ā handy before pointing it at a real server.
No cloning, no building ā the package is on npm. On each machine (needs Node.js 18+ and a host):
npm i -g @hassanjamal/api-mcp # install once
claude mcp add -s user api-mcp -- api-mcp # register for all projectsVerify with claude mcp list ā ā Connected. Then open an app folder and either use the
/qa-audit slash command or ask in natural language. To update later:
npm i -g @hassanjamal/api-mcp@latest.
Detection is heuristic (regex-based). It finds string-literal paths; fully dynamic URLs built
from variables may be partially normalized (${expr} ā {param}).
Generated request bodies are placeholders ā refine them via sampleValues in config for
endpoints with strict validation.
The executor sends real requests. Point it at a dev/staging server, not production.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Project root path. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explicitly lists what the tool scans (config files, axios/Dart settings, absolute URLs) and the output (candidate API base URLs with override capability). This is adequate for a read-only scanning tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the action, and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema), the description covers the scanning sources, types of apps, and output usage. Some details on candidate prioritization are omitted but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the parameter 'path' described as 'Project root path.' The description implies the path is used for scanning, adding minor context. Baseline is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies that the tool scans config files and code settings to find API base URLs, and mentions it works for web and mobile apps. This is a clear verb+resource combination, but it does not explicitly distinguish from sibling tools like detect_openapi.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for when to use the tool (web/mobile apps, QA use case) but does not mention when not to use it or compare with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches the project for an existing OpenAPI/Swagger document (swagger.json, openapi.yaml, etc.) and reports what was found.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Project root path. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral details. It only says 'reports what was found' without clarifying output format, error handling, or search depth. This leaves the agent uncertain about results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. While it could be expanded with behavioral details, it is efficient for its purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, but the description fails to specify what happens when no document is found or the exact return format. This leaves a gap in actionable context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'path' has a schema description 'Project root path.' The tool description does not add further meaning, but schema coverage is 100%, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for existing OpenAPI/Swagger documents, listing specific file names (swagger.json, openapi.yaml). This distinguishes it from sibling tools like detect_base_url or generate_openapi.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description only states what it does, without indicating prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Project root path (containing the .api-mcp folder). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states it 'regenerates' reports from saved files, implying a non-destructive read operation, but lacks details on error handling, required permissions, or what happens if files are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. The purpose is front-loaded, and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, no output schema), the description adequately covers what it does and when to use it. It could mention the output format (HTML+XLSX) more explicitly, but that is already in the title.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter (path). The description adds 'Project root path (containing the .api-mcp folder)' which is already in the schema. No additional semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it exports saved results to HTML and XLSX, specifies the source files (endpoints.json / results.json) and the folder (.api-mcp). It distinguishes from siblings by emphasizing it does not re-run tests.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use: 'to get shareable HTML/Excel output without re-running the tests.' While it does not list when-not-to-use or alternative tools, the context of sibling tools (e.g., run_tests) implies the distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Project root path. | |
| baseUrl | No | Base URL of the running server, e.g. http://localhost:3000. | |
| execute | No | Set false to scan and generate artifacts without live execution. | |
| headers | No | Extra headers applied to every request. Supports ${ENV_VAR}. | |
| bearerToken | No | Bearer token for Authorization header. Supports ${ENV_VAR}. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that it executes tests against a live server, implying network requests, but lacks details on side effects, report locations, or failure handling. No annotations are provided to supplement behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, front-loading the pipeline steps and essential input guidance. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's complexity, the description does not mention output format, report types, or failure behavior. With no output schema, this leaves significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the description adds value by grouping parameters (baseUrl and auth) and explaining their role in reaching the server, beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a one-call pipeline that performs scanning, spec generation, test generation, execution, and report writing. This distinguishes it from sibling tools that are individual steps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises to provide baseUrl and auth for execution, giving clear context. However, it does not explicitly mention when to use this tool vs the sibling sub-tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Project root path. | |
| title | No | API title for the spec info block. | |
| format | No | Output format for the spec file. | json |
| baseUrl | No | Server URL recorded in the spec's servers list. | |
| useExisting | No | Reuse an existing spec in the project if one is found. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. Discloses writing to .api-mcp directory and conditionality, but does not detail permissions, overwrite behavior, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences front-loading the main action with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers core behavior and output location despite lacking output schema. Adequately complete for a generation tool with lightweight semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. Description adds minimal extra context beyond schema descriptions, such as clarifying reuse condition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Explicitly states it builds an OpenAPI 3.0 spec from discovered endpoints, with clear verb and resource. Differentiates from sibling tools like detect_openapi.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains conditional behavior based on useExisting parameter, indicating when spec is loaded vs regenerated. Lacks explicit exclusions or alternatives for sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Project root path. | |
| baseUrl | No | Base URL of the running server, e.g. http://localhost:3000. | |
| headers | No | Extra headers applied to every request. Supports ${ENV_VAR}. | |
| bearerToken | No | Bearer token for Authorization header. Supports ${ENV_VAR}. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: writes tests.json, does not execute, bases tests on HTTP method and parameters. However, does not mention if it overwrites existing files, or the need for prior endpoint discovery.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, first states core purpose, second adds a key limitation. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, and description only mentions it writes tests.json. Does not explain return values, prerequisites (e.g., prior endpoint scan), or how endpoints are discovered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 4 parameters with descriptions. Description does not add further meaning to the parameters beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it generates a test plan for every discovered endpoint, writes tests.json, and does not execute anything. Distinguishes from sibling tools like run_tests.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage by specifying it works on discovered endpoints, but does not explicitly state when or when not to use it, nor mention prerequisites or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Project root path (used to auto-detect login endpoint). | |
| role | No | Label for this credential. | user |
| No | Email identifier. | ||
| baseUrl | No | API base URL. If omitted, the top detected candidate is used. | |
| password | Yes | Password. | |
| username | No | Username identifier (if not email). | |
| loginPath | No | Override login endpoint path. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses auto-detection, field variant attempts, and token extraction. However, lacks details on failure modes, side effects, or prerequisites beyond credentials. No annotations to supplement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences cover the core functionality efficiently, front-loaded with actionable information. No extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters and no output schema or annotations, the description is adequate but lacks details on return format, error handling, and what 'reports exactly what worked' means.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% parameter descriptions, so baseline is 3. Description adds process context but does not enhance individual parameter meanings beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The title and description clearly state the tool logs in and obtains an auth token. It specifies auto-detection of login endpoint, credential field variants, and token extraction. Different from sibling tools like detect_base_url or scan_endpoints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage when base URL and credentials are available, but does not explicitly state when to use or when not to, nor provide alternative tools. No direct comparison with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Project root path. | |
| roles | Yes | Credentials per role, e.g. [{role:'admin',email:'a@x.com',password:'ā¦'}]. | |
| baseUrl | No | API base URL. Omit to auto-detect from the code. | |
| loginPath | No | Override login endpoint path. | |
| roleScoped | No | Test each role only on endpoints its route-guard allows (plus unguarded ones), so you get more real 200s and far fewer 403/404s. Set false for full coverage. | |
| concurrency | No | ||
| includeWrites | No | Include POST/PUT/PATCH/DELETE tests. Only for throwaway/staging envs. | |
| includeDestructive | No | Also test session-breaking endpoints (logout, refresh-token, delete-account, password reset, register). Off by default ā testing logout revokes your own token. | |
| maxRateLimitWaitMs | No | Max ms to pace a request when the server's rate-limit budget is low. Raise toward the reset window (e.g. 900000) for exhaustive coverage under strict limits. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description fully discloses behavior: auto-detection of base URL and login endpoint, per-role login, read-only default, report generation, rate-limit pacing, and token revocation risks for includeDestructive. Very transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with purpose, no filler. Each sentence adds essential context without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers workflow and parameter behaviors well, but lacks description of output format or report structure. Given no output schema, the description should mention what the tool returns. Still adequate for complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 89% (high), so baseline 3. Description adds value by clarifying defaults (read-only), usage constraints (includeWrites only for throwaway), and side effects (includeDestructive token revocation). Exceeds schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it's a QA one-call workflow that logs in as roles, runs tests, and generates combined reports. It distinguishes from siblings like 'run_tests' (no login) and 'full_audit' (possibly different scope).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: 'Set includeWrites=true only against a throwaway/staging env' and cautions about includeDestructive revoking tokens. Implicitly contrasted with siblings via tool name and description, but lacks explicit when-to-use vs alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Project root path. | |
| dryRun | No | If true, list the planned requests without sending them. | |
| baseUrl | No | Base URL of the running server, e.g. http://localhost:3000. | |
| headers | No | Extra headers applied to every request. Supports ${ENV_VAR}. | |
| categories | No | Only run these test categories. Omit to run all. | |
| bearerToken | No | Bearer token for Authorization header. Supports ${ENV_VAR}. | |
| concurrency | No | How many requests to run in parallel. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses file saving and URL requirement but omits potential side effects (e.g., destructive requests) and doesn't explain concurrency or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. The key actions are front-loaded, and the requirement is stated separately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter tool with no output schema or annotations, the description covers overall purpose and a key prerequisite but leaves behavioral details (concurrency, error handling, response format) unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds context about generating a test plan and saving reports, but does not enhance individual parameter meanings beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it generates and executes a test plan, saving responses and a Markdown report. The 'like Postman' analogy aids understanding. However, it does not explicitly differentiate from siblings like 'generate_tests' or 'export_report'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It mentions the baseUrl prerequisite but provides no guidance on when to use this tool versus alternatives, nor any exclusions or context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute or relative path to the project root. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It describes the recursive scanning and file writing actions but does not mention if it is read-only, requires permissions, or has side effects beyond writing files. This is minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences, front-loading the main action and then the output. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of output schema and annotations, the description could provide more detail on the content of the report or endpoints.json, and how the tool interacts with sibling tools. It is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the 'path' parameter. The description adds no additional meaning, examples, or constraints beyond the schema, resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool recursively scans project directories for API endpoints, listing specific client and server technologies, and outputs a report and JSON file. This distinguishes it from sibling tools like detect_base_url or detect_openapi.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives such as detect_base_url or full_audit. It lacks when-to-use, when-not-to-use, or prerequisite information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.11detect_base_urldetect_openapiexport_reportfull_auditgenerate_openapigenerate_testsloginqa_auditrun_testsscan_endpointsEach 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for AI access to Swagger by SmartBear.
Conformance checker for MCP servers. Free, no key, verdicts recomputable and re-measured daily.
MCP server for secureFlows: token-free URL builders and integration-linting tools for AI agents.
A paid remote MCP for CLI tool MCP, built to return verdicts, receipts, usage logs, and audit-ready
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Hassan-Jamal/Automated_API_MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server