Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
STM_CONFIGYesPath to the services.yaml configuration file for the MCP server.
STM_HTTP_TOKENNoBearer token used by clients when running the MCP server over HTTP transport.
STM_SECRET_MOBIL_APP_PASSWORDYesMobile 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

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
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

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

B3.3/5.0

Scored across 17 tools

Disambiguation4/5

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.

Naming Consistency4/5

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.

Tool Count4/5

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.

Completeness4/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo issues