Skip to main content
Glama
Blazemeter

BlazeMeter Service Virtualization MCP Server

Official
by Blazemeter

virtual_services_test_data

Create, read, list, and update Test Data Manager datasets for virtual services from schemas or CSV files so transaction variables resolve with realistic test data.

Instructions

    Operations on TDM (Test Data Manager) datasets for virtual services.

    Dataset variables are referenced in transaction DSLs using ${fieldName} syntax (not Handlebars).
    Matcher name rules — MUST follow these exactly or matching will fail:
      - URL path with ${fieldName}: matcherName MUST be "equals_url". Never use "matches_url" with variables.
        Example: path "/users/${id}", matcherName "equals_url", matchingValue "/users/${id}"
      - Headers, query params, cookies: matcherName must be "equals" or "equals_insensitive".
        "contains", "matches", "not_matches" do NOT work with dataset variables.
      - Body (plain text): matcherName "equals"
      - Body (JSON): "equals_json" (variables embedded as JSON values e.g. {"id": "${id}"}) and
        "equals_xml" are the ONLY body matchers that get an auto-populated sampleBody. "matches_json"
        with equalTo() helper e.g. [[$.field, equalTo(${id})]] does NOT get a sampleBody — prefer
        equals_json/equals_xml when a request payload should be preserved as the sample body.
      - Body (XML): matcherName "equals_xml" or "matches_xml" with matching() helper
      - Path matchers (matches_json/matches_xml): ONE [[path, fn(arg)]] pair per matcher, where fn is
        equalTo(value) or matching(regex) and the argument is written WITHOUT quotes (quotes are matched
        literally). To check several paths, use one matcher per path.
      - matchingValue/sampleBody on body matchers are supplied as plain text — the
        virtual_services_http_transaction tool base64-encodes/decodes them automatically on
        create/update/read/list. Do NOT base64-encode them yourself before calling that tool.
      - Response content: base64-encoded string containing ${fieldName} — variables resolve at runtime.
    Additional rules:
      - If the same variable appears multiple times in one transaction (e.g. /test/${id}/${id}?q=${id}),
        ALL occurrences must match the SAME value in the incoming request.
      - Variables not defined in the dataset are treated as literal strings — the request must contain
        the exact text "${varName}" to match.
    Note: Handlebars ({{...}}) is separate — it is for dynamic response templating, not dataset substitution.

    Actions:
    - create_from_schema: Create a dataset by defining entities with field names and generator
        expressions. Supported generators include sequenceGenerator(start), randInt(min,max),
        randText(minLen,maxLen), randDate(min,max), guid(), regExp(pattern), and 80+ others.
        See https://help.blazemeter.com/docs/guide/test-data-generator-functions.html
        args(dict):
            workspace_id (int): Mandatory.
            service_id (int): Mandatory.
            service_name (str): Mandatory. Used in package/asset naming.
            entities (list): Mandatory. Each entry:
                name (str): entity name.
                fields (list): each {name: str, generator: str}.
                repeat (int, default=1000): rows to generate.
            global_variables (dict, optional): flat str→str map of global variables.

    - create_from_csv: Create a dataset from a local CSV file. Column headers become field names;
        the entity name is derived as "{stem}_csv" (e.g. accounts.csv → entity "accounts_csv").
        Generators use valueOfCSV("{filename}", "{field}") — values are sampled from CSV rows at runtime.
        args(dict):
            workspace_id (int): Mandatory.
            service_id (int): Mandatory.
            service_name (str): Mandatory.
            csv_file_path (str): Mandatory. Absolute local path to the CSV file.
            global_variables (dict, optional): flat str→str map of global variables.

    - list: List data-model assets in a workspace (TDM assets endpoint, type=data-model).
        args(dict):
            workspace_id (int): Mandatory.
            limit (int, default=50): max results.
            offset (int, default=0): skip count.

    - read: Read a data-model asset by service. Fetches with full content (withData=true).
        args(dict):
            workspace_id (int): Mandatory.
            service_id (int): Mandatory.
            service_name (str): Mandatory.

    - update: Update an existing schema-based data-model by replacing its entities/fields. Use this
        when the dataset was created with create_from_schema.
        args(dict):
            workspace_id (int): Mandatory.
            service_id (int): Mandatory.
            service_name (str): Mandatory.
            entities (list): Mandatory. Full new entity list (same format as create_from_schema).
            global_variables (dict, optional): flat str→str map of global variables.

    - update_from_csv: Update an existing CSV-based data-model from a local CSV file. Use this
        when the dataset was created with create_from_csv. Rebuilds the entity with valueOfCSV
        generators. Optionally renames entity fields via field_mappings (e.g. when the entity field
        name should differ from the CSV column name).
        By default only the data-model JSON is updated (field rename / mapping change).
        Set upload_csv=true only when the CSV file content itself has changed.
        args(dict):
            workspace_id (int): Mandatory.
            service_id (int): Mandatory.
            service_name (str): Mandatory.
            csv_file_path (str): Mandatory. Absolute local path to the CSV file (used for headers).
            field_mappings (list, optional): rename CSV columns to different entity field names.
                Each entry: {name: str (entity field name), csv_column: str (CSV column name)}.
                Example: [{"name": "account_name2", "csv_column": "account_name"}]
            upload_csv (bool, default=false): set true to re-upload the CSV file content.
            global_variables (dict, optional): flat str→str map of global variables.

    TdmAsset Schema:
    {'additionalProperties': True, 'properties': {'id': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'default': None, 'description': 'Asset id (UUID)', 'title': 'Id'}, 'name': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'default': None, 'description': 'Asset name', 'title': 'Name'}, 'displayName': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'default': None, 'description': 'Asset display name', 'title': 'Displayname'}, 'type': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'default': None, 'description': 'Asset type: data-model, mock-svc, global-entity', 'title': 'Type'}, 'packageId': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'default': None, 'description': 'Package id this asset belongs to', 'title': 'Packageid'}, 'content': {'anyOf': [{}, {'type': 'null'}], 'default': None, 'description': 'Parsed data-model content (present when withData=true)', 'title': 'Content'}}, 'title': 'TdmAsset', 'type': 'object'}

Input Schema

NameRequiredDescriptionDefault
argsYes
actionYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.10

TDQS

A4.3/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 burden and does so well: it discloses that update replaces the entire entity list, that update_from_csv by default only rewrites the data-model JSON unless upload_csv=true, that read fetches full content via withData=true, that base64 encoding is handled automatically by the sibling tool, and that violating matcher naming rules causes matching to fail. These are non-obvious side effects and failure modes an agent could not infer from structured fields.

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

Conciseness3/5

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

Purpose and action list are front-loaded, but the large matcher-rules block precedes the actions and reads as reference documentation for the transaction DSL rather than for this tool, consuming roughly half the text. The content is accurate and relevant to dataset variables, yet the ordering buries the actionable per-action contracts deeper than necessary.

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

Completeness4/5

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

For a complex multi-action tool with no output schema and no annotations, the description covers action semantics, args, generator syntax, and even embeds the TdmAsset shape so return values of read/list are inferable. Minor gaps remain: no statement of permissions/auth requirements or error behavior for failing creates.

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?

Schema coverage is 0% — the schema only declares a free-form args object — so the description must compensate, and it does: every action's args are enumerated with mandatory/optional status, types, defaults (limit 50, offset 0, repeat 1000, upload_csv false), formats (entities as {name, fields}, field_mappings entries), and worked examples. This is substantially more than the schema provides.

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

Purpose4/5

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

The opening line names a specific resource (TDM datasets for virtual services) and the six operations (create_from_schema, create_from_csv, list, read, update, update_from_csv) are spelled out explicitly. It is distinguishable from siblings like virtual_services_http_transaction, though that differentiation appears only incidentally in the base64 note rather than as an explicit statement of scope.

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?

Per-action routing guidance is present and useful: 'Use this when the dataset was created with create_from_schema' for update, and the same for update_from_csv, plus 'Set upload_csv=true only when the CSV file content itself has changed.' What is missing is guidance on when to use this tool at all versus related virtual-service tools, or prerequisites (e.g. whether a service must exist first).

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