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.yaml configuration file for the MCP server. | |
| STM_HTTP_TOKEN | No | Bearer token used by clients when running the MCP server over HTTP transport. | |
| STM_SECRET_MOBIL_APP_PASSWORD | Yes | Mobile application user password, stored as a secret and referenced by the profile as {{secret.STM_SECRET_MOBIL_APP_PASSWORD}}. |
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_operationA | Input/output schema of an operation. Profile services: catalog entry (params example, request/response schema, kind, session). 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. |
| list_operationsA | Operations in the catalog of a profile service (name, kind read/mutating/auth/unknown, needs session, param names). search = part of the name/description or a wildcard (Get*); kind / tag filter. |
| call_operationA | Call an operation of a profile service by name. Pass only the operation's own params (see describe_operation); the server adds the envelope and headers, logs in with the test customer when needed, renews the session and retries once if the server ended it. Values may use {{variables}} and {{test_customer.Field}}. test_customer: name from list_test_customers (default: the profile's default). extract = {name: JSONPath} saves session variables; assertions = optional list checked on the response. fresh_session forces a new login. Returns business success/errors, status, body (masked), elapsed_ms. |
| list_test_customersC | Test customers of a profile service in an environment, the live sessions of this server and test_customers busy elsewhere (another VS Code window, agent or CI holds the login). |
| end_sessionsA | Log out and release test_customer leases so others can use those test customers. Without arguments: all sessions of this server. |
| import_traffic_logA | Read a traffic log (mobile app transaction log or HAR) ON THE SERVER and propose catalog changes: new / changed / unchanged operations, kinds, session need, test customer and credential fields, values chained from earlier responses, and a draft scenario of the flow. The raw log never reaches you; values are masked. Service and environment are found from the URLs (give them only if the host is not in services.yaml). apply=false (default) is a preview - show it to the user; apply=true writes the catalog. scenario_path writes the draft scenario YAML to a file (under scenario_root). |
| 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 call_operation / soap_call / rest_call response (real values). 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 17 tools
Tools are mostly distinct by resource and action, with clear separation between discovery (list/describe/check), calls, sessions, and scenario execution. The only mild overlap is among soap_call, rest_call, and call_operation, which all execute requests but target different service modes; descriptions clarify the choice.
All names use snake_case and most are verb-first (list_, describe_, check_, run_, validate_, import_, reload_, end_). A few deviate in form—soap_call, rest_call, session_variables—but remain readable and predictable.
17 tools is slightly above the typical 3–15 range, but the domain spans service discovery, connectivity, direct/profile calls, session management, traffic import, and scenario/suite execution. Each tool maps to a distinct test-automation capability, so the count is reasonable.
The surface covers the main test lifecycle: service/operation discovery, connectivity, SOAP/REST/profile calls, session and test-customer management, assertions, traffic-log import, and scenario validation/execution/suite runs. Minor gaps exist around explicit scenario file management (listing/reading/editing) and manual scenario creation, but these are largely external YAML workflows.