Skip to main content
Glama
Blazemeter

BlazeMeter Service Virtualization MCP Server

Official
by Blazemeter

virtual_services_sandbox

Validate HTTP transactions in a sandbox by initializing the transaction and sending a test request to confirm matching.

Instructions

    Testing HTTP transactions in sandbox.
    Use this for HTTP transaction verification, or to re-test an existing transaction after update.
    MESSAGING transactions are not supported in sandbox.
    IMPORTANT: Testing a transaction in the sandbox ALWAYS requires two sequential tool calls:
      1. Call `init` first — places the transaction into the sandbox environment.
      2. Then call `test_request` — sends the actual HTTP request and returns the match result.
    Both steps are mandatory. Calling only `init` does NOT test anything; you MUST follow it with `test_request`.
    Response fields: matched=true means the request was matched by the configured transaction.
    matched=false means no transaction matched — read mismatch_reasons to understand which
    matchers failed and what to fix in the DSL.
    Actions:
    - init: Places transaction into sandbox. Must be called BEFORE test_request.
        args(dict): Dictionary with the following required parameters:
            workspace_id (int): Mandatory. The id of the workspace.
            transaction_id (int): Mandatory. The id of the transaction to test.
    - test_request: Sends test request to sandbox and returns match result. Must be called AFTER init.
        args(dict): Dictionary with the following required parameters:
            request (SandboxRequest): Mandatory. The request definition (method, path, headers, body).
            workspace_id (int): Mandatory. The id of the workspace.
    Sandbox Request Schema:
    {'$defs': {'HttpHeader': {'additionalProperties': True, 'properties': {'name': {'description': 'HTTP header name', 'title': 'Name', 'type': 'string'}, 'value': {'description': 'HTTP header value', 'title': 'Value', 'type': 'string'}}, 'required': ['name', 'value'], 'title': 'HttpHeader', 'type': 'object'}, 'QueryParameter': {'additionalProperties': True, 'properties': {'name': {'description': 'Query parameter name', 'title': 'Name', 'type': 'string'}, 'value': {'description': 'Query parameter value', 'title': 'Value', 'type': 'string'}}, 'required': ['name', 'value'], 'title': 'QueryParameter', 'type': 'object'}}, 'properties': {'method': {'description': 'The http method', 'title': 'Method', 'type': 'string'}, 'path': {'description': 'The request url path', 'title': 'Path', 'type': 'string'}, 'name': {'description': 'The name of the service', 'title': 'Name', 'type': 'string'}, 'queryParameters': {'anyOf': [{'items': {'$ref': '#/$defs/QueryParameter'}, 'type': 'array'}, {'type': 'null'}], 'default': [], 'description': 'List of query parameters', 'title': 'Queryparameters'}, 'headers': {'anyOf': [{'items': {'$ref': '#/$defs/HttpHeader'}, 'type': 'array'}, {'type': 'null'}], 'default': [], 'description': 'List of response headers', 'title': 'Headers'}, 'content': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'default': None, 'description': 'Base64 encoded body of the response', 'title': 'Content'}}, 'required': ['method', 'path', 'name'], 'title': 'SandboxRequest', 'type': 'object'}
    Sandbox test_request response schema:
    {'$defs': {'HttpHeader': {'additionalProperties': True, 'properties': {'name': {'description': 'HTTP header name', 'title': 'Name', 'type': 'string'}, 'value': {'description': 'HTTP header value', 'title': 'Value', 'type': 'string'}}, 'required': ['name', 'value'], 'title': 'HttpHeader', 'type': 'object'}, 'MatchingLogEntry': {'additionalProperties': True, 'properties': {'t': {'default': None, 'description': 'Timestamp of when the message was logged (in milliseconds since epoch)', 'title': 'T', 'type': 'integer'}, 'm': {'default': None, 'description': 'Log message', 'title': 'M', 'type': 'string'}}, 'title': 'MatchingLogEntry', 'type': 'object'}}, 'properties': {'status': {'description': 'HTTP status code of the response for the transaction response matching. E.g., 200, 404.', 'title': 'Status', 'type': 'integer'}, 'statusMessage': {'description': 'HTTP status message of the response', 'title': 'Statusmessage', 'type': 'string'}, 'headers': {'anyOf': [{'items': {'$ref': '#/$defs/HttpHeader'}, 'type': 'array'}, {'type': 'null'}], 'default': [], 'description': 'List of response headers', 'title': 'Headers'}, 'body': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'default': None, 'description': 'Decoded response body (plain text or JSON). Empty when no transaction matched.', 'title': 'Body'}, 'matchingLog': {'anyOf': [{'items': {'$ref': '#/$defs/MatchingLogEntry'}, 'type': 'array'}, {'type': 'null'}], 'default': [], 'description': 'Raw matching log entries from WireMock, used for debugging.', 'title': 'Matchinglog'}, 'matched': {'default': False, 'description': 'True when the request was matched by a transaction (matchingLog is empty). False means no transaction matched — check mismatch_reasons.', 'title': 'Matched', 'type': 'boolean'}, 'mismatch_reasons': {'description': 'Plain-text reasons why the request did not match any transaction. Populated from matchingLog when matched=False.', 'items': {'type': 'string'}, 'title': 'Mismatch Reasons', 'type': 'array'}}, 'required': ['status', 'statusMessage'], 'title': 'SandboxResponse', 'type': 'object'}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
argsYes
actionYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
infoNoInfo messages
errorNoError message
totalNoTotal available records
resultNoResult
warningNoWarning messages
has_moreNoMore records per page to list
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses the required sequential behavior of init and test_request, explains that matched=false indicates no match and to read mismatch_reasons, and describes response fields and their meanings. There is no contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is lengthy but well-structured with sections for actions, sandbox request schema, and response schema. It includes both natural-language explanations and JSON schemas, which is somewhat redundant but valuable for a complex tool. Every major point is covered, though a bit verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complex two-action flow and sparse schema, the description is exceptionally complete. It explains when to use it, the exact sequence of calls, all parameter formats, how to interpret responses (matched, mismatch_reasons), and limitations (no messaging). No gaps remain.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema is generic (only action and args) with 0% coverage. The description fully compensates by listing the two actions with their required args (workspace_id, transaction_id, request) and embedding the complete SandboxRequest schema with field descriptions and required properties, giving the agent all necessary parameter details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Testing HTTP transactions in sandbox,' clearly naming the resource (HTTP transactions) and the action (testing in sandbox). It also states 'Use this for HTTP transaction verification, or to re-test an existing transaction after update,' and explicitly excludes MESSAGING transactions, distinguishing it from sibling tools like virtual_services_messaging_transaction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides explicit usage guidance: 'Use this for HTTP transaction verification, or to re-test an existing transaction after update,' and warns that MESSAGING transactions are not supported. It details the mandatory two-step process (init then test_request) and clarifies that calling only init does nothing, preventing common errors.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Blazemeter/sv-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server