Conversational API Test MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MCP_WORKSPACE_ROOT | No | Default `workspaceRoot` when a tool call omits it. | |
| MCP_API_ALLOWED_HOSTS | No | Comma-separated hostnames requests may target. Unset = any host. | |
| MCP_API_REVEAL_SECRETS | No | `true` disables redaction. Local debugging only. | |
| MCP_API_ENV_PASSTHROUGH | No | Comma-separated env var names (trailing `*` = prefix) exposed to `{{env.NAME}}`. Unset = none. | |
| MCP_API_MAX_RESPONSE_BYTES | No | Response size cap. Default 10 MB. |
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
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_api_definitionsB | List YAML API definition files under |
| read_api_definitionA | Read and validate a whole API YAML definition. Prefer summarize_api_definition for triage. |
| upsert_canonical_api_definitionA | Create or update a canonical YAML under |
| reorganize_mcp_api_definitionsA | Plan or apply merging multiple YAML definitions into fewer files. |
| discover_legacy_api_sourcesC | Find Postman collections, OpenAPI/Swagger, or Insomnia exports. |
| convert_legacy_to_canonicalA | Turn a Postman collection, an OpenAPI/Swagger spec or an Insomnia export into a YAML definition under |
| import_curlA | Turn a |
| execute_api_requestA | Send one request from a YAML definition. Variables resolve YAML < .env.mcp.local < session (after set_environment, {ENV}_KEY wins over KEY); an unresolved placeholder is sent as the literal {{KEY}}. Runs |
| get_environment_variableA | Read a session variable set by capture or set_environment_variable. Credential-looking values come back as [REDACTED] with |
| set_environment_variableC | Set a session variable for subsequent requests. |
| set_environmentA | Set the active logical environment for this workspace session (session CURRENT_ENV, e.g. STAGING). Interpolation resolves {CURRENT_ENV}VAR from .env.mcp.local before generic VAR (prefix-first). Put all env secrets there (DEVELOP, STAGING_); YAML stays generic. |
| assert_responseA | Assert on the last HTTP response: status, jsonPathExists, maxDurationMs and value |
| explain_request_contextC | Summarize YAML keys, .env.mcp.local keys, session keys, and optional endpoint snippet. |
| summarize_api_definitionA | Summarize a canonical API YAML without returning the full definition. Use names_only for triage (optionally with |
| execute_api_flowA | Run a sequence of requestIds in a single MCP round trip. Pass inline |
| run_evalA | Evaluate an endpoint whose answer varies (LLM / RAG / search) — or any endpoint over many inputs — in one call. Runs each case |
| dry_run_requestB | Build the URL, method, headers and body preview for a requestId without sending the request. Credentials in headers, query string and body are redacted. |
| summon_vanderA | Call this whenever the user addresses Vander by name ("hi Vander", "oi Vander", "Vander, review X") or asks for a VANDER review. Pass |
| init_workspaceA | Create the starting structure in a project: the |
| plan_vander_checksA | Build the VANDER checklist (Verbs, Authorization, Negative, Data, Errors, Responsiveness) for one requestId, derived deterministically from its definition. Sends nothing. The id prefix is the axis ( |
| run_vander_checksA | Execute the automatic VANDER checks for one requestId. Returns one row per check ( |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| vander | Talk to Vander, a senior API QA persona that reviews an endpoint through Verbs, Authorization, Negative, Data, Errors and Responsiveness. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| api-docs-efficient-read-paths | |
| api-catalog-summary |
TDQS
Scored across 21 tools
Most tools target distinct actions (list vs read vs summarize, plan vs run VANDER checks, single request vs flow vs eval). A few pairs overlap in purpose—read_api_definition vs summarize_api_definition, convert_legacy_to_canonical vs import_curl—but descriptions provide clear guidance on when to use each.
Nearly all names follow a snake_case verb_noun pattern (execute_api_request, plan_vander_checks, set_environment_variable). Minor deviations such as set_environment vs set_environment_variable and the whimsical summon_vander keep it from being perfectly uniform, but the convention is still predictable.
21 tools is heavy for the domain; the server covers definition management, legacy conversion, execution, evals, VANDER checks, environment handling, and workspace init. Several pairs could arguably be merged (read/summarize, plan/run VANDER), making the count borderline rather than well-scoped.
The surface covers create/read/update via upsert, list, summarize, legacy conversion, request execution, assertions, flows, evals, VANDER checks, environment variables, and workspace init. A notable gap is an explicit delete tool for definitions or endpoints; upsert with replace_file can overwrite but does not obviously delete.