api-test-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
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| load_api_specA | Load and fully dereference an OpenAPI/Swagger spec from a URL or local file path (JSON or YAML). Call this first. Returns the API title, servers, and every documented endpoint. |
| list_endpointsA | List every endpoint (method + path) from the currently loaded API spec. |
| call_endpointA | Make an actual HTTP call to a documented endpoint and return the real status, headers, and body. Does not validate the response — use test_endpoint if you also want schema validation. |
| validate_responseC | Check a response body against the JSON schema documented for a given method + path + status code. |
| test_endpointA | Call a documented endpoint with real parameters, then validate the real response against its documented schema. Returns pass/fail plus the specific mismatches found. This is the main tool for 'does this endpoint actually work as documented'. |
| run_all_testsA | Best-effort run across every GET endpoint that needs no required parameters: calls each one for real and validates the response against the documented schema. Endpoints needing parameters are listed as skipped (use test_endpoint for those individually), and DELETE/OPTIONS/HEAD are never auto-run. Set includeMutating: true to also auto-generate example params/bodies from the schema and attempt POST/PUT/PATCH endpoints — off by default because that can create or modify real data on the live API. |
| check_healthA | One-shot health check: calls each given endpoint (or, if none given, every parameter-free GET in the loaded spec) and reports whether it responded, its status code, and latency. Useful for a quick 'is the API up' pass, e.g. before a demo or as part of CI. |
| diff_api_specsA | Compare two OpenAPI/Swagger specs (each a URL or local file path — e.g. an old tag vs. the current main) and report added/removed endpoints plus request/response schema changes, flagging which ones are likely to break existing clients (removed fields, newly-required fields, type changes, removed enum values) versus safe additive changes. Does not affect the spec currently loaded for the other tools. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 8 tools
Tools generally target distinct phases (load, list, call, validate, batch-test, health-check, diff), but call_endpoint/test_endpoint and run_all_tests/check_health both invoke live endpoints and could be confused if the goal is simply 'hit the API'. Descriptions do enough to resolve most ambiguity, so not a 5.
All tools use lowercase snake_case imperative verbs (load_, list_, call_, validate_, test_, run_, check_, diff_), and each name clearly signals the action. The pattern is highly consistent and predictable.
8 tools is well-scoped for an API testing server: loading, exploring, calling, validating, running tests, health-checking, and diffing specs. No redundant or extraneous tools are present.
The set covers the full workflow from loading an API spec to listing endpoints, making raw calls, validating responses, batch-running endpoint tests, health-checking, and comparing spec versions. Additional tools like auth management or report generation would be optional rather than obvious gaps.