Skip to main content
Glama
Blazemeter

BlazeMeter Service Virtualization MCP Server

Official
by Blazemeter

virtual_services_http_transaction

Create, read, update, and test HTTP transactions for service virtualization. Validate and convert templates, assign assets, and confirm request matching via sandbox tests.

Instructions

    Operations on HTTP transactions. 
    Use this when a user needs to create or select a HTTP transaction.
    DSL type field is mandatory and must be set to "HTTP".
  1. General Rules:
        - If redirect url is required in transaction creation or update, provide it as a redirectUrl field in dsl,
        not as a matcher.
        - Assign intermediate values with {{#assign "varName"}}{{value}}{{/assign}}.
        - Keep JSON objects outside helper calls; helpers should only produce values.
        - Do not nest helpers more than 1–2 levels deep.
        - Each helper must have exactly one opening and one closing brace; do not add extra # or braces.
        - Use handlebars helpers supported by wiremock, specified in https://wiremock.org/docs/response-templating/
        - Use validate_template and convert_template actions to validate and convert templates before using them in transaction definition.
        - Dataset variables (from virtual_services_test_data) are referenced with ${fieldName} syntax, NOT Handlebars.
          Matcher name rules — MUST follow exactly:
            * URL path with ${fieldName}: matcherName MUST be "equals_url". NEVER use "matches_url" with variables.
            * Headers / query params / cookies: matcherName must be "equals" or "equals_insensitive" only.
              "contains", "matches", "not_matches" do NOT work with dataset variables.
            * Body plain text: matcherName "equals"
            * Body JSON: matcherName "equals_json" (embed as value e.g. {"id": "${id}"})
              or "matches_json" with equalTo() e.g. [[$.field, equalTo(${id})]]
            * Body XML: matcherName "equals_xml" or "matches_xml" with matching() helper
            * Response content: base64-encode the string containing ${fieldName} — resolves at runtime.
          Extra rules:
            * Same variable used multiple times (path + header + body) must match the SAME value in the request.
            * Undefined variables are treated as literal strings — request must contain the exact text "${varName}".
        - IMPORTANT: When a transaction DSL contains Handlebars templates, always use
          create_and_test instead of create. A transaction is only complete when sandbox
          returns matched=true for all test cases. If matched=false, read mismatch_reasons,
          fix the DSL with update, re-init with virtual_services_sandbox init, then re-test with virtual_services_sandbox test_request.
    Actions:
    - read: Read an HTTP Transaction. Get the information of a transaction.
        args(dict): Dictionary with the following required parameters:
            workspace_id (int): Mandatory. The id of the workspace to list transactions from.
            id (int): Mandatory. The id of the transaction to get information.
    - list: List all HTTP transactions. 
        args(dict): Dictionary with the following required parameters:
            workspace_id (int): Mandatory. The id of the workspace to list transactions from.
            serviceId (int): Optional. The id of the service to list transactions from. Without this it will list all transactions in the workspace.
            virtual_service_id (int): Optional. The id of the virtual service to list transactions from. Without this it will list all transactions in the workspace.
            limit (int, default=10, valid=[1 to 50]): The number of transactions to list.
            offset (int, default=0): Number of transactions to skip.
    - validate_template: Validate template. Validates template used in transaction definition.
        args:
            template (str): Mandatory. The handlebars template to validate.
    - convert_template: Convert template. Converts template to blazemeter format.
        args:
            template (str): Mandatory. The handlebars template to validate.
            encode (bool, default=True): Whether to encode the converted template to Base64.
    - create_and_test: Create a new HTTP transaction and immediately validate it in sandbox.
        Use this instead of `create` when the DSL contains Handlebars templates.
        A transaction is only complete when sandbox returns matched=true for all test cases.
        On all-fail: error contains the failure summary; transaction still exists — use update to fix the DSL,
        then re-init with virtual_services_sandbox init and re-test with virtual_services_sandbox test_request.
        On partial fail: warning lists failures; transaction still exists.
        args:
            name (str): Mandatory. The name of the transaction.
            serviceId (int): Mandatory. The id of the service.
            dsl (GenericDsl): Mandatory. The DSL definition.
            workspace_id (int): Mandatory. The id of the workspace.
            delay (int): Optional. Response delay in milliseconds.
            test_cases (list[SandboxRequest]): Mandatory. At least one test request.
                Each entry has: method (str), path (str), name (str),
                queryParameters (list, optional), headers (list, optional), content (str base64, optional).
        Returns:
            info: ["transaction_id=<id>", "tests_passed=<n>", "tests_total=<n>"]
            result: List of SandboxResponse per test case.
            result[].matched: True if the test request matched the transaction.
            result[].body: Decoded response body (plain text or JSON).
            result[].mismatch_reasons: Why the request did not match (when matched=False).
            error: All test cases failed, or creation/sandbox init failed.
                On sandbox init failure, info still contains transaction_id so the transaction can be recovered.
            warning: Some (not all) test cases failed.
    - create: Create a new HTTP transaction.
        Important: before using template in transaction definition validate it and 
        convert it first using validate_template and convert_template actions.
        args(Transaction): A Transaction object with the following fields:
            name (str): Mandatory. The name of the transaction.
            serviceId (int): Mandatory. The id of the service to create the transaction in.
            dsl (GenericDsl): Mandatory. The DSL definition of the transaction.
            workspace_id (int): Mandatory. The id of the workspace.
            delay (int): Optional. Response delay in milliseconds.
    - update: Updates a certain transaction.
        Important: before using template in transaction definition validate it and  
        convert it first using validate_template and convert_template actions.
        args(Transaction): A Transaction object with the following fields:
            id (int): Mandatory. The id of the transaction.
            name (str): Mandatory. The new name of the transaction.
            dsl (GenericDsl): Mandatory. The DSL definition of the transaction.
            workspace_id (int): Mandatory. The id of the workspace. 
            delay (int): Optional. Response delay in milliseconds.
    - assign_keystore: Assign keystore asset to the transaction.
        args(dict):
            id (int): Mandatory. The id of the transaction.
            asset_id (int): Mandatory. The id of the keystore asset to assign.
            alias (str): Mandatory. The certificate alias to use.
            workspace_id (int): Mandatory. The id of the workspace.  
    - assign_certificate: Assign certificate asset to the transaction.
        args(dict):
            id (int): Mandatory. The id of the transaction.
            asset_id (int): Mandatory. The id of the certificate asset to assign.
            workspace_id (int): Mandatory. The id of the workspace.           

    Transaction Schema (including full GenericDsl with RequestDsl and ResponseDsl):
    {'$defs': {'AssignedAsset': {'properties': {'assetId': {'description': 'The identifier of the asset', 'title': 'Assetid', 'type': 'integer'}, 'assetUsageType': {'description': 'The usage type of the asset', 'title': 'Assetusagetype', 'type': 'string'}, 'alias': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'default': None, 'description': 'The asset certificate alias', 'title': 'Alias'}}, 'required': ['assetId', 'assetUsageType'], 'title': 'AssignedAsset', 'type': 'object'}, 'GenericDsl': {'additionalProperties': True, 'properties': {'requestDsl': {'$ref': '#/$defs/RequestDsl', 'description': 'Request DSL for the transaction request matching'}, 'responseDsl': {'$ref': '#/$defs/ResponseDsl', 'description': 'Response DSL for the transaction response matching'}, 'redirectUrl': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'default': None, 'description': 'Redirect URL for the transaction', 'title': 'Redirecturl'}, 'type': {'default': 'HTTP', 'description': "The type of the transaction. Supported value is 'HTTP'.", 'title': 'Type', 'type': 'string'}}, 'required': ['requestDsl', 'responseDsl'], 'title': 'GenericDsl', 'type': 'object'}, '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'}, 'MatcherDsl': {'additionalProperties': True, 'properties': {'key': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'default': None, 'description': "Matcher key. For URL matchers has static value 'url', for header matchers - header name, for body matchers static name 'body', for query parameter matchers - query parameter name", 'title': 'Key'}, 'matcherName': {'description': "The name of the matcher. Supported values for URL matchers: 'matches_url', 'equals_url'. Supported values for header/query matchers: 'equals', 'equals_insensitive', 'contains', 'matches', 'not_matches', 'absent'. Supported values for body matchers: 'equals', 'equals_insensitive', 'contains', 'matches', 'not_matches', 'absent', 'equals_json', 'equals_xml', 'matches_json', 'matches_xml', 'matches_xml_schema', 'matches_xml_cdata'.", 'title': 'Matchername', 'type': 'string'}, 'matchingValue': {'description': "Value to match against. Not used for 'absent' matcher_name. ", 'title': 'Matchingvalue', 'type': 'string'}, 'optional': {'default': False, 'description': 'If true, the matcher is optional and does not need to be present to match.', 'title': 'Optional', 'type': 'boolean'}, 'namespaces': {'anyOf': [{'items': {'$ref': '#/$defs/XmlMatcherNamespace'}, 'type': 'array'}, {'type': 'null'}], 'default': None, 'description': "Namespaces used for XML matching. Only used if matcher_name is one of 'equals_xml', 'matches_xml', 'matches_xml_schema', 'matches_xml_cdata'.", 'title': 'Namespaces'}, 'cdataXpath': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'default': None, 'description': "CDATA XPath expression used for XML CDATA matching. Only used if matcher_name is 'matches_xml_cdata'.", 'title': 'Cdataxpath'}}, 'required': ['matcherName', 'matchingValue'], 'title': 'MatcherDsl', 'type': 'object'}, 'RequestDsl': {'additionalProperties': True, 'properties': {'method': {'default': 'GET', 'description': "HTTP method of the request for the transaction request matching. Uppercase, e.g., 'GET', 'POST'", 'title': 'Method', 'type': 'string'}, 'path': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'default': None, 'description': "Mandatory.Path of the request for the transaction request matching. E.g., '/api/v1/resource'. Used instead of matcher_name for URL matcher definition. Important: Should have same value as url.matchingValue.", 'title': 'Path'}, 'url': {'$ref': '#/$defs/MatcherDsl', 'default': None, 'description': 'Mandatory. Matcher definition for the full URL of the request'}, 'headers': {'anyOf': [{'items': {'$ref': '#/$defs/MatcherDsl'}, 'type': 'array'}, {'type': 'null'}], 'default': [], 'description': 'List of matchers for the headers of the request', 'title': 'Headers'}, 'queryParams': {'anyOf': [{'items': {'$ref': '#/$defs/MatcherDsl'}, 'type': 'array'}, {'type': 'null'}], 'default': [], 'description': 'List of matchers for the query parameters of the request', 'title': 'Queryparams'}, 'body': {'anyOf': [{'items': {'$ref': '#/$defs/MatcherDsl'}, 'type': 'array'}, {'type': 'null'}], 'default': [], 'description': 'List of matchers for the body of the request', 'title': 'Body'}}, 'title': 'RequestDsl', 'type': 'object'}, 'ResponseDsl': {'additionalProperties': True, 'properties': {'status': {'description': 'HTTP status code of the response for the transaction response matching. E.g., 200, 404.', 'title': 'Status', 'type': 'integer'}, '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'}, 'statusCodeConditions': {'anyOf': [{'items': {'$ref': '#/$defs/StatusCodeCondition'}, 'type': 'array'}, {'type': 'null'}], 'default': [], 'description': 'Status code conditions for the response', 'title': 'Statuscodeconditions'}}, 'required': ['status'], 'title': 'ResponseDsl', 'type': 'object'}, 'StatusCodeCondition': {'additionalProperties': True, 'properties': {'status': {'default': 200, 'description': 'Status code', 'title': 'Status', 'type': 'integer'}, 'statusMessage': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'default': 'OK', 'description': 'HTTP header name', 'title': 'Statusmessage'}, 'matcher': {'$ref': '#/$defs/MatcherDsl', 'description': 'Condition matcher'}}, 'required': ['matcher'], 'title': 'StatusCodeCondition', 'type': 'object'}, 'XmlMatcherNamespace': {'properties': {'prefix': {'description': 'XML namespace prefix.', 'title': 'Prefix', 'type': 'string'}, 'uri': {'description': 'XML namespace URI.', 'title': 'Uri', 'type': 'string'}}, 'required': ['prefix', 'uri'], 'title': 'XmlMatcherNamespace', 'type': 'object'}}, 'properties': {'id': {'default': None, 'description': 'The unique identifier of the transaction', 'title': 'Id', 'type': 'integer'}, 'name': {'description': 'The name of the transaction', 'title': 'Name', 'type': 'string'}, 'serviceId': {'anyOf': [{'type': 'integer'}, {'type': 'null'}], 'default': None, 'description': 'The unique identifier of the service where the transaction belongs', 'title': 'Serviceid'}, 'dsl': {'$ref': '#/$defs/GenericDsl', 'description': 'Transaction DSL'}, 'assets': {'anyOf': [{'items': {'$ref': '#/$defs/AssignedAsset'}, 'type': 'array'}, {'type': 'null'}], 'default': None, 'description': 'List of assets', 'title': 'Assets'}}, 'required': ['name', 'dsl'], 'title': 'HttpTransaction', '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 the full burden and excels. It details error behavior (e.g., create_and_test failures leave the transaction existing, requiring update and sandbox re-init), return formats, and side effects. It also explains matcher rules and dataset variable handling, providing deep behavioral insight.

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 well-structured with clear sections (General Rules, Actions, Transaction Schema) and front-loads the purpose. However, it is extremely long, especially the embedded JSON schema, which could be considered excessive for a description even though it adds value.

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?

For a tool with this complexity, the description is exhaustive. It covers all 9 actions, their parameters, return info for create_and_test, plus the full transaction schema and edge cases like variable matching and template validation. Despite the output schema existing, the description still provides necessary operational context.

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 (action/args), so the description provides all parameter meaning. It documents each action's args with required/optional status, defaults, valid ranges, and the full GenericDsl structure with field descriptions. This fully compensates for 0% schema coverage.

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 clearly states the tool performs 'Operations on HTTP transactions' and explicitly says 'Use this when a user needs to create or select a HTTP transaction.' The name and content distinguish 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 Guidelines4/5

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

It provides explicit usage context ('Use this when...') and internal action-level guidance, e.g., 'Use create_and_test instead of create when the DSL contains Handlebars templates.' However, it does not explicitly mention alternatives for non-HTTP transactions, falling short of full when-not/alternatives guidance.

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