service-test-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| STM_CONFIG | Yes | Path to the services catalog YAML file (services.yaml) that defines services, environments, authentication, and variables. | |
| STM_PW_NTLM | No | Password for the service user when NTLM authentication is used. Typically supplied via a VS Code prompt and stored securely; not written to disk in plain text. | |
| STM_HTTP_TOKEN | No | Bearer token required when running the MCP server over HTTP transport on a non-local address. |
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_servicesB | List configured services (SOAP/REST), environments and the default environment. Start here. |
| describe_serviceC | SOAP: WSDL ports, selected address and operation names. REST: base_url and OpenAPI operations (if configured). |
| describe_operationB | Input/output schema of an operation. SOAP: operation name -> input_schema, example_params, output_schema. REST: 'METHOD /path' or operationId from the OpenAPI document. |
| check_serviceB | Connectivity check without calling an operation: SOAP loads the WSDL and binds the port; REST requests base_url. Without 'service' every service is checked. |
| soap_callA | Call a SOAP/WCF operation. params = JSON object of the operation's input elements (see describe_operation). Values may use {{variables}}. extract = {name: JSONPath} saves values from the response as session variables (e.g. {"token": "$.Token"}) so later calls can send {{token}} even though it is masked in the output. Returns status, fault (code/message/detail) or body (JSON), elapsed_ms. include_raw adds the SOAP envelopes. |
| rest_callA | Call a REST endpoint. path is relative to the service base_url (e.g. /hesaplar/123). body = JSON value, body_text = raw text (XML, form). path, query, headers and body may use {{variables}} (e.g. headers {"Authorization": "Bearer {{token}}"}). extract = {name: JSONPath} saves session variables. Returns status, body (parsed JSON or text), elapsed_ms. |
| session_variablesB | Show (masked) or clear the session variables saved by 'extract' on soap_call / rest_call. |
| check_last_responseA | Evaluate assertions against the last soap_call / rest_call response (real values, deterministic). Use it to try assertions before writing them into a scenario file. |
| validate_scenarioA | Validate scenario YAML (a file, a folder, or inline 'content'): structure, services, assertion syntax, JSONPath, and variables used before they are defined. Does not call any service. |
| run_scenarioA | Run one scenario file (or inline YAML 'content'). Steps run in order; extract passes values to later steps. verbosity: summary | failures (default: details only for failed steps) | full. |
| run_test_suiteA | Run every scenario under a folder (recursively), optionally only those with one of 'tags'. Returns a summary and failed assertions; junit_path writes a JUnit XML report. |
| reload_configA | Re-read services.yaml after it was edited (no server restart needed). |
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 12 tools
Most tools have clearly distinct roles: discovery (list_services), introspection (describe_service vs describe_operation differ by granularity), connectivity (check_service), and invocation split cleanly by protocol (soap_call vs rest_call). The main soft overlap is run_scenario vs run_test_suite (single file vs folder/tags) and check_last_response vs scenario assertions, but descriptions make the boundaries explicit enough to choose correctly.
The set is predominantly consistent snake_case verb_noun (list_services, describe_operation, check_service, validate_scenario, run_scenario, reload_config). Minor deviations exist: soap_call/rest_call use protocol-first ordering and session_variables is a noun-only name with no verb, but the pattern remains readable and predictable.
At 12 tools the server is well-scoped for an API/service testing surface, with each tool mapping to a distinct phase (discover, describe, check, call, validate, run, inspect, reload). Nothing feels redundant or missing at the count level.
The lifecycle is largely covered: discovery, schema introspection, connectivity checks, SOAP/REST invocation with variable extraction, assertion probing, scenario validation and execution (single and suite), plus config reload. Gaps are minor: no tool to list/discover available scenario files or suites, and no built-in scenario authoring/write operation, so agents must rely on external file access.