Skip to main content
Glama
Blazemeter

BlazeMeter Service Virtualization MCP Server

Official
by Blazemeter

virtual_services_sandbox

Tests HTTP transactions in a sandbox: initialize a transaction, send a request, and review match results or mismatch reasons.

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'}, 'body': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'default': None, 'description': "Plain-text request body to send in the sandbox test. Do not base64-encode it yourself - the tool encodes it automatically before sending it to the backend, which expects a field named 'body' (not 'content') containing base64.", 'title': 'Body'}}, '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

NameRequiredDescriptionDefault
argsYes
actionYes

Output Schema

NameRequiredDescriptionDefault
infoNoInfo messages
errorNoError message
totalNoTotal available records
resultNoResult
warningNoWarning messages
has_moreNoMore records per page to list

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.10

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description carries the full behavioral burden and does so thoroughly. It discloses the mandatory two-step workflow, what each action does, that calling init alone does not test anything, how matched and mismatch_reasons should be interpreted, and that body is encoded automatically.

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 front-loaded with purpose and the critical two-step workflow, and its action-by-action structure is helpful. It is somewhat long and repeats full nested schema blocks, but much of that detail is justified because the top-level schema provides almost no parameter documentation.

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 multi-action workflow and nested request/response objects, the description is complete enough for an agent to invoke the tool correctly. It explains the required call order, the arguments for each action, and how to interpret the response, including matched and mismatch_reasons.

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 has 0% description coverage, but the description compensates by documenting the action values and their required args, including workspace_id, transaction_id, and the SandboxRequest fields. It also adds meaning to the nested request and response structures beyond what the generic schema communicates.

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 states a specific verb and resource: testing HTTP transactions in a sandbox. It explicitly distinguishes this tool from messaging-related siblings by saying MESSAGING transactions are not supported, which is important given the sibling set.

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

Usage Guidelines4/5

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

It gives clear usage guidance: use for HTTP transaction verification or re-testing after an update, and it explicitly excludes MESSAGING transactions. It also mandates the two-call sequence init then test_request, though it does not name sibling alternatives for managing HTTP transactions outside the sandbox.

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