Skip to main content
Glama
Blazemeter

BlazeMeter Service Virtualization MCP Server

Official
by Blazemeter

BlazeMeter Service Virtualization MCP Server

The BlazeMeter Service Virtualization MCP Server connects AI tools directly to BlazeMeter's Service Virtualization platform. This gives AI agents, assistants, and chatbots the ability to manage complete workflows from creation of transactions to deploying it to the virtual service. All through natural language interactions.

Use Cases

  • Service Management: Create and manage services.

  • Transaction Management: Create, validate, manage HTTP and Messaging transactions.

  • Action Management: Create, read, list, and manage transaction actions (Http calls and Webhooks).

  • Asset Management: Upload assets (certificates and keystores).

  • Sandbox Management: Attach HTTP transaction and test it.

  • Location Management: List available locations.

  • Configuration Management: Create and manage configurations for virtual services.

  • Virtual Service Management: Create, modify, deploy, stop a virtual service, track its status.

  • Messaging Virtual Service Management: Create, deploy, and manage messaging virtual services across IBM MQ, ActiveMQ, and Kafka brokers.

  • Recording Management: Capture live broker traffic into recordings and replay them via messaging virtual services.

  • Virtual Service Templates Management: Create, modify, create from the virtual service, apply to a virtual service.

  • Test Data Management: Create, update, and read TDM datasets for virtual services to drive data-driven transaction matching.


Related MCP server: jmeter-mcp

Prerequisites

  • BlazeMeter API credentials (API Key ID and Secret)

  • Compatible MCP host (VS Code, Claude Desktop, Cursor, Windsurf, etc.)

  • Docker (only for Docker-based deployment)

Setup

Get BlazeMeter API Credentials

Follow the BlazeMeter API Keys guide to obtain your API keys as JSON.

IMPORTANT

When downloading your API keys from BlazeMeter, save theapi-keys.json file in the same folder where you'll place the MCP binary.

Available Tools

The BlazeMeter MCP Server provides comprehensive access to BlazeMeter's API through the following tools:

Tool

Purpose

Key Capabilities

User

Blazemeter User Information

Get current user details, default account/workspace/project

Account

Blazemeter Account Management

List accounts, check AI consent, read account details

Workspace

Blazemeter Workspace Management

Manage workspaces, check billing usage

Service

Service Management

Create and manage services

Http Transaction

Http Transaction Management

Create, manage and validate http transactions

Messaging Transaction

Messaging Transaction Management

Create, manage and validate messaging transactions

Action

Action Management

Create, read, list and manage transaction actions

Virtual service

Virtual Service Management

Create, manage, deploy, stop virtual services

Virtual service template

Virtual Service Template Management

Create, manage, apply to the virtual service

Messaging Virtual Service

Messaging Virtual Service Management

Create, manage, deploy messaging virtual services for IBM MQ, ActiveMQ, Kafka

Recording

Recording Management

Create, manage recordings and recorded messages for messaging virtual services

Asset

Asset Management

Upload assets

Configuration

Configuration Management

Create, manage configurations

Sandbox

Sandbox Management

Assign http transaction, test it

Tracking

Tracking Management

Fetch tracking status for virtual service actions

Test Data

Test Data Management

Create, update, read TDM datasets for virtual services


User Management

What it does: Get information about BlazeMeter account and default settings.

Action

What you get

Get user info

Your username, default account, workspace, and project IDs


Account Management

What it does: Manage your BlazeMeter accounts and check permissions.

Action

What you get

Get account details

Account information and AI consent status

List accounts

All accounts you have access to


Workspace Management

What it does: Navigate and manage testing workspaces.

Action

What you get

Get workspace details

Workspace information and billing details

List workspaces

All workspaces in an account


Service Management

What it does: Creates and manages services.

Action

What you get

Create a new service

A service with provided name

Update an existing service

An updated service with provided name

Get service

A workspace service information

List services

All services in a workspace


Http Transaction Management

What it does: Creates, validates, and manages http transactions.

Action

What you get

Read an HTTP Transaction

Reads HTTP Transaction details

Create a new HTTP transaction

Creates a new HTTP transaction

Update HTTP transaction

Updates existing HTTP transaction

List all HTTP transactions

Lists all HTTP transactions in a workspace or service

Validate template

Validates handlebars template

Convert template

Safely converts handlebars template to VS format

Assign keystore

Assign keystore asset to an existing transaction

Assign certificate

Assign certificate asset to an existing transaction


Messaging Transaction Management

What it does: Creates, validates, and manages messaging transactions.

Action

What you get

Read a Messaging Transaction

Reads Messaging Transaction details

Create a new Messaging transaction

Creates a new Messaging transaction with optional priority, tags, source/destination mapping, and sample body

Update Messaging transaction

Updates existing Messaging transaction

List all Messaging transactions

Lists all Messaging transactions in a workspace, service, or messaging virtual service

Validate template

Validates handlebars template

Convert template

Safely converts handlebars template to VS format

Assign keystore

Assign keystore asset to an existing Messaging transaction

Assign certificate

Assign certificate asset to an existing Messaging transaction


Action Management

What it does: Creates, reads, and lists actions for a transaction.

Action

What you get

Read an Action

Reads a single transaction action's details

List Actions

Lists all actions of a transaction

Create an HTTP Call

Creates an HTTP Call sync action

Create a Web Hook

Creates a Webhook async

Assign keystore

Assign keystore asset to an existing action

Assign certificate

Assign certificate asset to an existing action


Asset Management

What it does: Creates, lists, manages assets.

Action

What you get

Read an Asset

Reads Asset details

List all Assets

Lists all assets in a workspace

Upload asset file

Creates an asset from user's file

Set keystore passwords

Sets passwords for existing certificate or keystore asset


Configuration Management

What it does: Creates, lists, manages configurations.

Action

What you get

Read a Configuration

Reads Configuration details

List all Configurations

Lists all configurations in a workspace

Create a Configuration

Creates new configuration

Update a Configuration

Adds new values to existing configuration


Location Management

What it does: Lists available locations.

Action

What you get

List all locations

Lists all locations in a workspace


Sandbox Management

What it does: Validates HTTP transactions without deploying a virtual service.

Action

What you get

Init sandbox

Assigns an existing transaction to the sandbox

Test request

Sends test http request to the sandbox and receives transaction response


Tracking Management

What it does: Reads virtual service action tracking details.

Action

What you get

Read a tracking

Reads virtual service action tracking details

Read an asset uplaod tracking

Reads file upload tracking details


Virtual Service Management

What it does: Create, manage, deploy, stop, update your virtual service.

Action

What you get

Read a Virtual Service

Reads Virtual Service details

Create a new Virtual Service

Creates a new Virtual Service with enabled HTTP runner

Update Virtual Service

Updates existing Virtual Service

List all Virtual Services

Lists all Virtual Services in a workspace or service

Deploy Virtual Service

Starts Virtual Service container

Configure Virtual Service

Updates running Virtual Service

Stop Virtual Service

Stops Virtual Service container

Assign transactions

Assigns transactions to the Virtual Service

Unassign transactions

Unassigns transactions from the Virtual Service

Assign configuration

Assigns configuration to the Virtual Service

Apply Virtual Service Template

Applies Virtual Service Template settings to the Virtual Service

Set Proxy

Adds proxy settings to the Virtual Service

Unset Proxy

Removes proxy settings from the Virtual Service

Assign Keystore

Assigns keystore asset to the Virtual Service

Assign Keystore + Truststore

Assigns keystore asset to the Virtual Service, to be used as both Keystore and Truststore


Messaging Virtual Service Management

What it does: Create, manage, deploy, stop messaging virtual services. Supports IBM MQ (JMS and Native), ActiveMQ Classic, ActiveMQ Artemis, and Kafka brokers.

Action

What you get

Read a Virtual Service

Reads Messaging Virtual Service details including broker config and protocol

Create a Virtual Service

Creates a Messaging Virtual Service for any supported protocol with full broker configuration

Update a Virtual Service

Partially updates a Messaging Virtual Service (only provided fields change)

List all Virtual Services

Lists all Messaging Virtual Services in a workspace or service

Deploy Virtual Service

Starts Messaging Virtual Service container

Stop Virtual Service

Stops Messaging Virtual Service container

Configure Virtual Service

Hot-reloads transactions into a running Messaging Virtual Service

Assign transactions

Assigns transactions to the Messaging Virtual Service

Unassign transactions

Unassigns transactions from the Messaging Virtual Service

Assign recordings

Assigns recordings to the Messaging Virtual Service for replay

Unassign recordings

Unassigns recordings from the Messaging Virtual Service

Assign configuration

Assigns configuration to the Messaging Virtual Service

Set Proxy

Adds proxy settings to the Messaging Virtual Service

Unset Proxy

Removes proxy settings from the Messaging Virtual Service

Assign queue

Assigns a queue to the Messaging Virtual Service

Assign topic

Assigns a topic to the Messaging Virtual Service

Supported protocols and required broker config fields:

Protocol

hostname

port

channel

queueManager

username

password

SSL

Embedded broker

Kafka-specific

IBM_MQ9_JMS

IBM_MQ9_NATIVE

ACTIVE_MQ_CLASSIC

opt

ACTIVE_MQ_ARTEMIS

opt

KAFKA

opt

opt

opt

autoOffsetReset, numPartitions


Recording Management

What it does: Creates and manages recordings of live broker traffic. Recordings can be attached to messaging virtual services for replay.

Action

What you get

List recordings

Lists all recordings in a workspace, optionally filtered by service or virtual service

Read a recording

Reads recording details including inline messages

Create a recording

Creates a new recording with optional runtime config (replayCount, delays)

Update a recording

Full replacement of a recording

Patch a recording

Partial update — only provided fields change

List messages

Lists recorded messages within a recording, sorted by index

Create message

Adds a recorded message to a recording (base64-encoded content)

Update message

Full replacement of a recorded message

Patch message

Partial update of a recorded message


Virtual Service Template Management

What it does: Create, manage virtual service templates.

Action

What you get

Read a Virtual Service Template

Reads Virtual Service Template details

Create a new Virtual Service Template

Creates a new Virtual Service Template

Update Virtual Service Template

Updates existing Virtual Service Template

List all Virtual Service Templates

Lists all Virtual Service Templates in a workspace or service

Assign transactions

Assigns transactions to the Virtual Service Template

Unassign transactions

Unassigns transactions from the Virtual Service Template

Assign configuration

Assigns configuration to the Virtual Service Template

Assign Keystore

Assigns keystore asset to the Virtual Service Template

Assign Keystore + Truststore

Assigns keystore asset to the Virtual Service Template, to be used as both Keystore and Truststore


Test Data Management

What it does: Creates and manages TDM (Test Data Manager) datasets that drive data-driven transaction matching. Dataset fields are referenced in transaction DSLs using ${fieldName} syntax.

Action

What you get

Create from schema

Creates a dataset by defining entities with field names and generator expressions

Create from CSV

Creates a dataset from a local CSV file; entity name is {stem}_csv, fields use valueOfCSV generators

List

Lists data-model assets in a workspace

Read

Reads a data-model asset with full content for a given service

Update

Replaces entities/fields on an existing schema-based dataset

Update from CSV

Rebuilds a CSV-based dataset from a local CSV file; supports field name remapping


Enabling or Disabling MCP Tools

The MCP server supports enabling or disabling specific tools at startup using the environment variable MCP_ENABLED_TOOLS. If the environment variable is not set or is an empty string, all available tools are automatically enabled.

To enable only certain tools, set the environment variable to a comma-separated list of tool names.

Example: MCP_ENABLED_TOOLS="blazemeter_user,blazemeter_account,virtual_services_virtual_service"


Observability (OpenTelemetry)

The server emits one trace span per MCP tool call using OpenTelemetry. By default it exports over gRPC to the Perforce collector at https://grpc.public.prd.shared.perforce.com. No configuration is needed for shipped releases; set OTEL_SDK_DISABLED=true (or --no-telemetry) to turn it off.

Override the destination — environment variable:

export OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4317   # gRPC (insecure for localhost)
sv-mcp --mcp

Override the destination — CLI argument (binary / uvx):

sv-mcp --mcp --otel-endpoint http://localhost:4317

The transport is always gRPC (OTLP/HTTP is not used). OTEL_EXPORTER_OTLP_ENDPOINT / --otel-endpoint overrides only the destination URL, not the protocol — and an http:// scheme there simply means an insecure (no-TLS) gRPC channel, so always target the collector's gRPC port (4317), never its HTTP port (4318).

A local verification stack (collector + Jaeger + Prometheus + Grafana) lives in integration/telemetry/docker compose up, then point the server at http://localhost:4317.

Passing authentication headers:

# env var (comma-separated key=value pairs)
export OTEL_EXPORTER_OTLP_HEADERS="Authorization=Bearer your-token"

# CLI flag (repeatable)
sv-mcp --mcp \
  --otel-endpoint http://your-collector:4318 \
  --otel-headers "Authorization=Bearer your-token" \
  --otel-headers "X-Dataset=sv-mcp"

Disable tracing entirely:

# env var
export OTEL_SDK_DISABLED=true

# CLI flag
sv-mcp --mcp --no-telemetry

Each span includes:

  • gen_ai.tool.name — MCP tool name (e.g. virtual_services_http_transaction)

  • mcp.tool.action — action dispatched (e.g. create_and_test)

  • mcp.client.name / mcp.client.version — MCP client identity from the initialize handshake (when provided)

  • error.type — set on failure (auth_failed, not_found, rate_limited, server_error, timeout, tool_error, api_error)

W3C Trace Context propagation: if your MCP client passes traceparent/tracestate in _meta, spans are linked to the parent trace automatically.

SDK availability by deployment:

The SDK is bundled in every deployment and exports to the Perforce gRPC collector by default — nothing extra is required to get tracing. Override only if you want a different destination:

Deployment

OTel SDK bundled

To redirect / disable

Docker image

✅ Yes

-e OTEL_EXPORTER_OTLP_ENDPOINT=... or -e OTEL_SDK_DISABLED=true

Standalone binary

✅ Yes

--otel-endpoint URL / --no-telemetry

uvx

✅ Yes

--otel-endpoint URL / --no-telemetry

Docker (redirect to your own collector):

docker run --rm -i \
  -e API_KEY_ID=your_key_id \
  -e API_KEY_SECRET=your_key_secret \
  -e OTEL_EXPORTER_OTLP_ENDPOINT=http://your-collector:4317 \
  sv-mcp

uvx:

uvx --from "git+https://github.com/Blazemeter/sv-mcp.git" sv-mcp \
  --otel-endpoint http://your-collector:4317

The server never crashes if the endpoint is unreachable or the SDK is not installed.


uvx installs and runs the package in an isolated environment — no manual setup required.

{
  "mcpServers": {
    "blazemeter-sv": {
      "command": "uvx",
      "args": [
        "--from", "git+https://github.com/Blazemeter/sv-mcp.git",
        "sv-mcp"
      ],
      "env": {
        "API_KEY_PATH": "/path/to/api-key.json"
      }
    }
  }
}

To pin a specific version or branch, change the --from value:

  • Tag: git+https://github.com/Blazemeter/sv-mcp.git@v1.0.4

  • Branch: git+https://github.com/Blazemeter/sv-mcp.git@main


MCP Client Configuration for Local testing using VS Code or Claude Desktop

  1. Run main.py with --mcp flag

  2. Configure your MCP client with the following settings:

{
  "mcpServers": {
    "virtual services mcp": {
      "disabled": false,
      "timeout": 60,
      "type": "stdio",
      "command": "path to your python interpreter /.../venv/bin/python",
      "args": [
        "path to project main.py /.../sv_mcp/main.py",
        "--mcp"
      ],
      "env": {
        "API_KEY_PATH": "path to api key file /.../api-key.json"
      }
    }
  }
}

Format of the Api key file

{
  "id": "your_api_key_id",
  "secret": "your_api_key_secret"
}

Docker Support

MCP Client Configuration for Docker

Build dokcer image using the following command: docker build . -t vs-mcp:latest

{
  "mcpServers": {
    "Docker BlazeMeter MCP": {
      "command": "docker",
      "args": [
        "run",
        "--rm",
        "-i",
        "-e",
        "API_KEY_ID=your_api_key_id",
        "-e",
        "API_KEY_SECRET=your_api_key_secret",
        "-e",
        "SOURCE_WORKING_DIRECTORY=/tmp",
        "-e",
        "OTEL_EXPORTER_OTLP_ENDPOINT=http://your-collector:4318",
        "-v",
        "/host/path/to/your/test/files:/tmp",
        "us-docker.pkg.dev/verdant-bulwark-278/sv-mcp/sv-mcp:latest"
      ]
    }
  }
}
IMPORTANT

For Windows OS, paths must use backslashes (\) and be properly escaped as double backslashes (\\) in the JSON configuration. E.g.: C:\\User\\Desktop\\mcp_test_folder

NOTE

In order to obtain theAPI_KEY_ID andAPI_KEY_SECRET refere to BlazeMeter API keys

Available Tools

17 tools
blazemeter_accountA
    Operations on account users. 
    Use this when a user needs to select a account.
    Actions:
    - read: Read a Account. Get the information of a account.
        args(dict): Dictionary with the following required parameters:
            account_id (int): The id of the account to get information.
    - list: List all accounts. 
        args(dict): Dictionary with the following required parameters:
            limit (int, default=10, valid=[1 to 50]): The number of tests to list.
            offset (int, default=0): Number of tests to skip.
    Hints:
    - If you need to get the default account, use the project id to get the workspace and with that the account.
    - Use the read operation if AI consent information is needed. The AI Consent it's located at account level.
ParametersJSON Schema
NameRequiredDescriptionDefault
argsYes
actionYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
infoNoInfo messages
errorNoError message
totalNoTotal available records
resultNoResult
warningNoWarning messages
has_moreNoMore records per page to list

TDQS

A4/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It clearly lists read and list actions, implying read-only behavior, and adds context about AI consent at the account level. However, it doesn't explicitly state side effects, permissions, or error behavior, leaving some ambiguity.

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 structured with a purpose line, usage guidance, action list, and hints. It is somewhat verbose but every section adds value. The opening 'Operations on account users' is redundant and could be trimmed, but overall it's efficient.

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?

The description covers the key aspects: purpose, usage, actions, parameters, and hints for default account and AI consent. It doesn't explain return values, but an output schema exists and would handle that. Missing details like error conditions or prerequisites are minor for a read/list tool.

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 schema is generic with a single 'args' object, providing no parameter details. The description compensates fully by listing each action's parameters, including types, defaults, and valid ranges (e.g., limit default 10, valid 1-50). This is essential and well-detailed.

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 description states the tool provides read and list operations for accounts, with a use case ('select a account'). It is clear but the opening phrase 'Operations on account users' is slightly confusing and doesn't strongly distinguish from sibling tools like blazemeter_workspaces.

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?

The description explicitly says 'Use this when a user needs to select a account', providing clear usage context. It also offers a hint for getting the default account, but it doesn't mention when NOT to use this tool or explicitly name alternatives.

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

blazemeter_userA
        Operations on user information.
        Actions:
        - read: Read a current user information from BlazeMeter.
        Hints:
        - For default account, workspace and project, use the 'read' action. 
    
ParametersJSON Schema
NameRequiredDescriptionDefault
argsYesDictionary with parameters
actionYesThe action id to execute

Output Schema

ParametersJSON Schema
NameRequiredDescription
infoNoInfo messages
errorNoError message
totalNoTotal available records
resultNoResult
warningNoWarning messages
has_moreNoMore records per page to list

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations, the description carries the full burden. It explicitly states the 'read' action reads current user information, indicating a non-mutating operation. It also hints at the default context scope. This provides adequate transparency for a simple read-only tool, though it does not disclose details like authentication or response format (the output schema likely covers that).

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 concise and structured with sections for actions and hints. It contains no fluff, and each line contributes useful information. The opening 'Operations on user information' is slightly redundant with the tool name but acceptable.

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?

Given the tool's simplicity (2 parameters, output schema present, read-only action), the description is fairly complete. It explains the action and provides a usage hint. It doesn't elaborate on args, but the schema defines it as a dictionary, and the only action 'read' likely doesn't require complex arguments. The output schema covers return values.

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

Parameters4/5

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

Schema coverage is 100%, so parameters are already described. The description adds value by specifying the valid action value 'read', which the schema does not provide via enums. It also gives a hint about using it with default account/workspace/project, adding context to the 'args' parameter, though it doesn't detail specific args.

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 description clearly states the tool operates on user information, with a specific 'read' action that reads current user information from BlazeMeter. This is a specific verb+resource, but it does not explicitly distinguish from sibling tools like blazemeter_account or blazemeter_workspaces, so it misses the top score.

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

Usage Guidelines3/5

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

The description provides a hint to use the 'read' action for default account, workspace, and project, which gives some usage context. However, it does not explicitly say when to use this tool instead of alternatives, nor does it mention exclusive conditions or alternative tools.

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

blazemeter_workspacesA
            Operations on workspaces.
            Actions: 
            - read: Read a workspace. Get the detailed information of a workspace.
                args(dict): Dictionary with the following required parameters:
                    workspace_id (int): The id of the workspace.
            - list: List all workspaces. 
                args(dict): Dictionary with the following required parameters:
                    account_id (int): The id of the account to list the workspaces from
                    limit (int, default=10, valid=[1 to 50]): The number of workspaces to list.
                    offset (int, default=0): Number of workspaces to skip.
            
ParametersJSON Schema
NameRequiredDescriptionDefault
argsYesDictionary with parameters
actionYesThe action id to execute

Output Schema

ParametersJSON Schema
NameRequiredDescription
infoNoInfo messages
errorNoError message
totalNoTotal available records
resultNoResult
warningNoWarning messages
has_moreNoMore records per page to list

TDQS

A3.8/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly indicates these are read/list operations (non-destructive), and provides parameter details. However, it does not describe return formats, pagination behavior beyond the limit/offset parameters, error conditions, or required permissions. The operations are simple reads, so the missing detail is less critical, but still leaves gaps.

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 action labels and parameter details. It is not overly verbose, though the formatting includes some redundant phrasing like 'Dictionary with the following required parameters' which is repeated. The main purpose is front-loaded, and all content is relevant.

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?

The description covers both actions and their parameters adequately. An output schema exists, so return values do not need explanation. The tool is relatively simple, and the description provides enough context to invoke read and list correctly. It could mention account_id behavior for 'list all workspaces' but overall it is complete for the intended use.

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 top-level schema only has generic 'action' and 'args' fields with 'args' being a free-form object. The description enriches this significantly by specifying exact parameters for each action: workspace_id for read; account_id, limit (with default/range), and offset for list. This is crucial for correct invocation and goes well beyond the schema's minimal information.

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 description clearly states 'Operations on workspaces' and lists specific actions 'read' and 'list' with resource scope, making the tool's purpose clear. It does not explicitly differentiate from sibling tools like blazemeter_user or blazemeter_account, but the resource and verbs are specific enough for a baseline understanding.

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

Usage Guidelines3/5

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

The description provides clear guidance on when to use the 'read' action versus the 'list' action, but it gives no guidance on when to use this tool over sibling tools or any exclusion criteria. The usage context is implied by the action descriptions, but there are no explicit alternative mentions or 'when not to use' instructions.

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

virtual_services_actionA
    Operations on actions. 
    Use this when a user needs to create, read or list actions for a transaction.
    Actions:
    - read: Reads a single action of a transaction with full details.
        args(dict):
            workspace_id (int): Mandatory. The id of the workspace.
            transaction_id (int): Mandatory. The id of the transaction.
            action_id (int): Mandatory. The id of the action to read.
    - list: Lists all actions of a transaction (minimal info).
        args(dict):
            workspace_id (int): Mandatory. The id of the workspace.
            transaction_id (int): Mandatory. The id of the transaction.
            sort (str): Optional. Field to sort the actions by.
    - create_http_call: Creates an http call action for transaction. This action is executed synchronously.
        args(dict): Dictionary with the following required parameters:
            action_name (str): Mandatory. The name of the action.
            workspace_id (int): Mandatory. The id of the workspace to list services from.
            transaction_id (int): Mandatory. The id of the transaction.
            action (WebAction): Mandatory. The action definition. See WebAction schema below.
    - create_web_hook: Creates a web hook action for transaction. This action is executed asynchronously.
        args(dict): Dictionary with the following required parameters:
            action_name (str): Mandatory. The name of the action.
            workspace_id (int): Mandatory. The id of the workspace to list services from.
            transaction_id (int): Mandatory. The id of the transaction.
            action (WebAction): Mandatory. The action definition. See WebAction schema below.
    - assign_keystore: Assign keystore asset to the action.
        args(dict):
            id (int): Mandatory. The id of the action.
            transaction_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 action.
        args(dict):
            id (int): Mandatory. The id of the action.
            transaction_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.                      
    Action 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': {'urlValue': {'description': 'Action request url value', 'title': 'Urlvalue', 'type': 'string'}, 'urlMethod': {'description': "Action request HTTP method of the request for the transaction request matching. Uppercase, e.g., 'GET', 'POST'", 'title': 'Urlmethod', 'type': 'string'}, 'bodyContent': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'description': 'Action request body content', 'title': 'Bodycontent'}, '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'}}, 'required': ['urlValue', 'urlMethod', 'bodyContent'], 'title': 'WebAction', 'type': 'object'}
ParametersJSON Schema
NameRequiredDescriptionDefault
argsYes
actionYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
infoNoInfo messages
errorNoError message
totalNoTotal available records
resultNoResult
warningNoWarning messages
has_moreNoMore records per page to list

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations provided, the description carries the burden of behavioral disclosure. It does well by noting synchronous execution for create_http_call, asynchronous for create_web_hook, and distinguishing 'full details' (read) from 'minimal info' (list). It also clarifies the 'assign' operations target keystore/certificate assets. However, it does not explicitly mention side effects, error behavior, or permissions, which would be useful for a mutation-heavy tool.

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 long but well-structured with a clear hierarchy: top-level purpose, then sub-operations each with their own args. It uses bullet-like formatting with consistent parameter listings. Every sentence serves a purpose, but the abundance of detail makes it somewhat dense. Front-loaded with the core purpose and usage statement.

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 multi-operation tool with no annotations, the description provides substantial context: operation semantics, parameter meanings, and even the WebAction schema. It distinguishes synchronous vs asynchronous behavior and read vs list detail levels. The presence of an output schema reduces the need to document return values. Minor gaps include lack of error handling or response format details, but overall it's complete enough for an agent to select and invoke correctly.

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 description coverage is 0%, so the description must fully compensate. It does so comprehensively: each sub-action lists every parameter with mandatory/optional status and a clear description. The embedded WebAction schema provides nested object structure with types, defaults, and field descriptions. This far exceeds the minimal input schema and gives the agent everything needed to construct valid arguments.

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 it handles 'Operations on actions' and specifies 'Use this when a user needs to create, read or list actions for a transaction.' This is a specific verb+resource combination that distinguishes it from sibling tools focused on services, transactions, or assets. The sub-operations are enumerated, making the scope unambiguous.

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 explicitly states when to use the tool: 'Use this when a user needs to create, read or list actions for a transaction.' While it doesn't name alternative tools or provide exclusions, the context of sibling tools and the clear resource focus (actions within transactions) gives sufficient guidance. No misinformation or ambiguity.

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

virtual_services_assetA
    Operations on assets. 
    Use this when a user needs to create an asset from file. Supported file extensions: .jks, .keystore, .key, .crt, 
    .cer, .p7b, .p7c, .p7s, .pem
    Actions:
    - read: Reads an Asset. Get the information of an asset.
        args(dict): Dictionary with the following required parameters:
            workspace_id (int): Mandatory. The id of the workspace to list asset from.
            asset_id (int): Mandatory. The id of the asset.
    - list: List all assets. 
        args(dict): Dictionary with the following required parameters:
            workspace_id (int): Mandatory. The id of the workspace to list services from.
            limit (int, default=10, valid=[1 to 50]): The number of assets to list.
            offset (int, default=0): Number of assets to skip.
    - set_keystore_passwords: Sets keystore password for the keystore asset.
        args(dict): Dictionary with the following required parameters:
            workspace_id (int): Mandatory. The id of the workspace to list asset from.
            asset_id (int): Mandatory. The id of the asset.
            keystore_password (str): Optional. The keystore password.
            key_passwords (dict): Optional. The dictionary of key alias x password.
    - upload: Create a new asset from file.
        Action result contains tracking id to track the create asset process. Use tracking tool to track it.
        Creation of the asset is finished, when tracking status is 'FINISHED'. If creation fails, tracking status is 'FAILED'.
        args(dict): Dictionary with the following required parameters:
            workspace_id (int): Mandatory. The id of the workspace to store the asset.
            file_path (int): Mandatory. The full file path to the file for upload.
    Asset Schema:
    {'properties': {'id': {'description': 'The unique identifier of the asset', 'title': 'Id', 'type': 'integer'}, 'name': {'description': 'The name of the asset', 'title': 'Name', 'type': 'string'}, 'type': {'description': 'The type of the asset', 'title': 'Type', 'type': 'string'}, 'primaryMetadata': {'anyOf': [{'additionalProperties': True, 'type': 'object'}, {'type': 'null'}], 'default': None, 'description': 'The asset metadata', 'title': 'Primarymetadata'}}, 'required': ['id', 'name', 'type'], 'title': 'Asset', 'type': 'object'}
    Asset create action result schema:
    {'properties': {'tracking_id': {'description': 'Action tracking id', 'title': 'Tracking Id', 'type': 'string'}}, 'required': ['tracking_id'], 'title': 'ActionResult', 'type': 'object'}
ParametersJSON Schema
NameRequiredDescriptionDefault
argsYes
actionYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
infoNoInfo messages
errorNoError message
totalNoTotal available records
resultNoResult
warningNoWarning messages
has_moreNoMore records per page to list

TDQS

A3.9/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It adds valuable behavioral context: upload returns a tracking id and the process completes when tracking status is 'FINISHED' or 'FAILED'. It also lists supported file extensions and provides output schemas. However, it doesn't disclose permissions, reversibility, or side effects for mutation actions like set_keystore_passwords, leaving some behavioral gaps.

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?

The description is well-structured with action headers and clear formatting, but it's lengthy. The Asset Schema and ActionResult schema are redundant with the provided output schema, adding bloat without new information. The core action documentation is concise, but overall could be trimmed.

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?

The description covers all four actions, all parameters, file extensions, and the tracking process, making it largely complete for a complex multi-action tool. It falls short on error handling and authorization details, but the provided schemas and per-action docs cover most agent needs.

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) with 0% coverage, so the description is the sole source of parameter semantics. It thoroughly documents each action's args, including types, mandatory/optional status, defaults (limit=10, offset=0), and valid ranges (1-50). This fully compensates for the minimal schema.

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 description clearly states 'Operations on assets' and lists four distinct actions (read, list, set_keystore_passwords, upload), making the resource and verbs specific. However, the initial 'Use this when' focuses only on creating from file, which slightly conflicts with the broader read/list actions, so not a perfect 5.

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 explicitly says 'Use this when a user needs to create an asset from file' and lists supported file extensions as prerequisites. The upload action also advises using the tracking tool, providing an alternative. However, it doesn't explicitly say when not to use other sibling tools, but the resource-specific naming helps.

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

virtual_services_configurationA
    Operations on virtual service configurations. 
    Use this when a user needs to create or update a virtual service configuration.
    Actions:
    - read: Read a Configuration.
        args(dict): Dictionary with the following required parameters:
            workspace_id (int): Mandatory. The id of the workspace to list configurations from.
            configuration_id (int): Mandatory. The id of the configuration to get information.
    - list: List all configurations. 
        args(dict): Dictionary with the following required parameters:
            workspace_id (int): Mandatory. The id of the workspace to list configurations from.
            limit (int, default=10, valid=[1 to 50]): The number of configurations to list.
            offset (int, default=0): Number of configurations to skip.
    - create: Create a new configuration.
        args(dict): Dictionary with the following required parameters:
            workspace_id (int): Mandatory. The ID of the workspace in which to create the configuration.
            configuration_name (str): Mandatory. The name of the configuration to create.
            configuration_map (Dict[str, str]): Mandatory. A map of configuration parameters and their corresponding values.
    - update: Update an existing configuration.
        args(dict): Dictionary with the following required parameters:
            workspace_id (int): Mandatory. The ID of the workspace containing the configuration.
            configuration_id (int): Mandatory. The ID of the configuration to update.
            configuration_name (str): Mandatory. The new or updated name of the configuration.
            configuration_map (Dict[str, str]): Mandatory. A map of configuration parameters and their corresponding values.
    Configuration Schema:
    {'additionalProperties': True, 'properties': {'id': {'anyOf': [{'type': 'integer'}, {'type': 'null'}], 'default': None, 'description': 'Configuration id', 'title': 'Id'}, 'name': {'description': 'Configuration parameter name', 'title': 'Name', 'type': 'string'}, 'description': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'default': None, 'description': 'Configuration parameter name', 'title': 'Description'}, 'configurationMap': {'anyOf': [{'additionalProperties': {'type': 'string'}, 'type': 'object'}, {'type': 'null'}], 'description': 'Configuration map', 'title': 'Configurationmap'}}, 'required': ['name', 'configurationMap'], 'title': 'Configuration', 'type': 'object'}
ParametersJSON Schema
NameRequiredDescriptionDefault
argsYes
actionYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
infoNoInfo messages
errorNoError message
totalNoTotal available records
resultNoResult
warningNoWarning messages
has_moreNoMore records per page to list

TDQS

A4.2/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It discloses the four actions and their parameters, but omits important behavior such as whether updates are full replacements or merges, and possible side effects like overwriting existing configurations. This leaves moderate ambiguity.

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-organized by action. The embedded Configuration Schema is redundant given the likely output schema, but does not detract significantly. Overall, it earns its length through thorough coverage of the tool's complexity.

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 four-action tool with nested arguments, this is nearly complete, documenting all necessary parameters and providing a data schema. It falls short only in not explaining behavioral outcomes (e.g., error conditions), but is still highly actionable.

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 just a generic 'action/args' envelope, but the description details every required parameter per action, including types, mandatory flags, and defaults for limit/offset. This greatly exceeds the schema and gives the agent precise invocation guidance.

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 'Operations on virtual service configurations' and enumerates four explicit actions (read, list, create, update), clearly identifying the tool's scope and distinguishing it from sibling tools focused on other virtual service resources.

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 states 'Use this when a user needs to create or update a virtual service configuration,' giving a direct usage trigger. It doesn't mention alternatives, but the tool's config-specific scope makes the guidance sufficient for selecting it over siblings.

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

virtual_services_http_transactionA
    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'}
ParametersJSON Schema
NameRequiredDescriptionDefault
argsYes
actionYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
infoNoInfo messages
errorNoError message
totalNoTotal available records
resultNoResult
warningNoWarning messages
has_moreNoMore records per page to list

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 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.

virtual_services_locationA
    Operations on locations. 
    Use this when a user needs to read locations information.
    Actions:
    - list: List all locations. 
        args(dict): Dictionary with the following required parameters:
            workspace_id (int): Mandatory. The id of the workspace to list locations from.
    Location Schema:
    {'properties': {'harborId': {'default': None, 'description': 'Location harbor id', 'title': 'Harborid', 'type': 'string'}, 'shipId': {'default': None, 'description': 'Location ship id', 'title': 'Shipid', 'type': 'string'}, 'shipName': {'default': None, 'description': 'Location name', 'title': 'Shipname', 'type': 'string'}, 'portRange': {'default': None, 'description': 'Location port range', 'title': 'Portrange', 'type': 'string'}, 'kubernetes': {'default': None, 'description': 'If true - Kubernetes location, if false - Docker location', 'title': 'Kubernetes', 'type': 'boolean'}}, 'title': 'Location', 'type': 'object'}
ParametersJSON Schema
NameRequiredDescriptionDefault
argsYes
actionYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
infoNoInfo messages
errorNoError message
totalNoTotal available records
resultNoResult
warningNoWarning messages
has_moreNoMore records per page to list

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden. It discloses that the 'list' action returns all locations and requires a workspace_id, which is useful. However, it does not describe any side effects, authorization requirements, pagination behavior, or error handling. For a read-only tool, some of this may be implied, but the description is not thorough.

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?

The description is structured with a clear intro, usage note, and action breakdown, but the inclusion of the full Location Schema as a raw dictionary is verbose and interrupts the flow. It is not overly long, but the schema dump could be considered excessive and is not integrated cleanly. The structure is acceptable but not highly polished.

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

Completeness3/5

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

The tool has a generic input schema with two required parameters, and the description covers only one action ('list'). It provides enough detail to invoke that action, including the mandatory workspace_id, but it does not explain if there are other actions or provide guidance on the 'action' parameter's expected values. The included output schema helps, but the overall picture is incomplete for a tool that supports multiple potential actions.

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

Parameters3/5

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

The input schema is generic with only 'action' and 'args' and 0% schema description coverage. The description compensates by explaining the 'list' action and the required workspace_id parameter, as well as providing a location schema for the output. However, it does not clarify the possible values for 'action' beyond a single example, nor does it describe any other potential arguments. This is partial compensation but leaves ambiguity.

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 description clearly states the tool handles operations on locations and explicitly says to use it for reading location information. The 'list' action is described with a specific purpose, distinguishing it from sibling tools that focus on other resources like services or configurations. However, it is not fully specific about all possible operations, as it only lists one action despite saying 'Operations'.

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?

The description provides explicit guidance: 'Use this when a user needs to read locations information.' This clearly indicates the primary use case. It does not mention when not to use the tool or alternatives, but the guidance is clear and direct. A score of 4 is appropriate since it gives a clear context without exclusions.

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

virtual_services_messaging_transactionA
    Operations on JMS Messaging transactions. 
    Use this when a user needs to create or select a JMS messaging transaction.
    DSL type field is mandatory and must be set to "MESSAGING".
  1. General Rules:
        - Supported JMS header names: 'MQ9_MQMD_VERSION', 'MQ9_MQMD_REPORT', 'MQ9_MQMD_MESSAGE_TYPE', 
            'MQ9_MQMD_EXPIRY', 'MQ9_MQMD_FEEDBACK', 'MQ9_MQMD_ENCODING', 'MQ9_MQMD_CHARACTER_SET', 
            'MQ9_MQMD_PRIORITY', 'MQ9_MQMD_PERSISTENCE', 'MQ9_MQMD_MESSAGE_ID', 'MQ9_MQMD_CORRELATION_ID', 
            'MQ9_MQMD_BACKOUT_COUNT', 'MQ9_MQMD_USER_ID', 'MQ9_MQMD_ACCOUNTING_TOKEN', 'MQ9_MQMD_APPLICATION_ID', 
            'MQ9_PUT_APPLICATION_TYPE', 'MQ9_PUT_APPLICATION_NAME', 'MQ9_PUT_DATE_TIME', 
            'MQ9_MQMD_APPLICATION_ORIGIN_DATA', 'MQ9_MQMD_GROUP_ID', 'MQ9_MQMD_SEQUENCE_NUMBER', 
            'MQ9_MQMD_OFFSET', 'MQ9_MQMD_FLAGS', 'MQ9_MQMD_ORIGINAL_LENGTH', 'JMS_MESSAGE_ID', 
            'JMS_CORRELATION_ID', 'JMS_TIMESTAMP', 'JMS_DELIVERY_MODE', 'JMS_REDELIVERED', 
            'JMS_EXPIRATION', 'JMS_PRIORITY'
        - 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.
        - Conditional helpers ({{#eq}}, {{#neq}}, {{#gt}}, {{#lt}}, etc.) must use variable names directly without quotes.
        - Use {{else}} only once per conditional; do not use {{#else}} or {{/else}}.
        - Avoid repeating the same condition in multiple nested blocks.
        - Templates must be valid JSON and readable.
        2. Explicit Helper Syntax:
        - Opening a block helper: {{#helperName [arguments]}}
          Example: {{#assign "userId"}} or {{#eq userId "0"}}
        - Closing a block helper: {{/helperName}}
          Example: {{/assign}} or {{/eq}}
        - Else clause: {{else}} (no #, no /)
          Example:
            {{#eq userId "0"}}
              { "error": "User not found" }
            {{else}}
              { "id": {{userId}}, "name": "John Doe" }
            {{/eq}}
        - Variable interpolation inside JSON: {{variableName}} only for values
        - JSON objects stay outside helpers.
        3. Fields that support templates:
        - ResponseDsl.content: Base64 encoded response body that can include templates using {{}} syntax.
        4. Available helpers (WireMock + Blazemeter custom helpers) — all use {{}} style:
        5. LLM-Specific Best Practices:
        - Produce one helper per line.
        - Do not combine multiple logic operations in a single line.
        - Use sequential conditionals for multiple branches instead of deeply nested {{#eq}} blocks.
        - Keep templates simple, granular, and maintainable.
        - Always follow the explicit helper syntax rules above to prevent extra braces or invalid {{#else}} usage.
        6. Example Templates:
        # --- Assigning and Joining Values ---
        {{#assign 'operation'}}{{join request.method request.url ' '}}{{/assign}}
        Result: {{operation}}
        
        # --- Headers ---
        All headers: {{request.headers}}
        Single header: {{request.headers.JMS_CORRELATION_ID}}
        Iterate headers:
        {{#each request.headers as |hdr|}}
        {{hdr.name}}: {{hdr.value}}
        {{/each}}
        
        # --- Body and Body Parsing ---
        Raw body: {{request.body}}
        Body as JSON: {{jsonPath request.body '$'}}
        Body as XML: {{xpath request.body '//element'}}
        Extract value using JSONPath:
        {{#assign 'price'}}{{jsonPath request.body '$.price'}}{{/assign}}
        Extracted price: {{price}}
        Extract value using XPath:
        {{#assign 'id'}}{{xpath request.body '//order/id/text()'}}{{/assign}}
        Extracted ID: {{id}}
        
        # --- Conditional Logic ---
        {{#eq request.headers.JMS_CORRELATION_ID '1234'}}
        Order is pending
        {{else}}
        Order status: {{request.headers.STATUS}}
        {{/eq}}
        
        # --- Arrays and Ranges ---
        {{#assign 'a'}}{{array 'A' 'B' 'C'}}{{/assign}}
        Joined: {{arrayJoin ',' a}}
        {{#assign 'b'}}{{arrayAdd a 'D' position=1}}{{/assign}}
        Added: {{arrayJoin ',' b}}
        {{#assign 'c'}}{{arrayRemove b position=2}}{{/assign}}
        Removed: {{arrayJoin ',' c}}
        
        {{#each (range 1 3) as |i|}}
        Item {{i}}
        {{/each}}
        
        # --- String Helpers ---
        {{join 'Order' request.path.1 'confirmed'}}
        {{replace 'foo-bar' '-' '_'}}
        {{upper request.method}}
        {{lower user.role}}
        {{capitalize 'hello world'}}
        {{capitalizeFirst 'wiremock templates'}}
        {{defaultIfEmpty request.headers.comment 'none'}}
        {{cut 'a,b,c' ','}}
        {{slugify 'Hello World!'}}
        {{stripTags '<b>bold</b>'}}
        {{substring 'abcdef' 2 5}}
        {{ljust 'hi' size=5 pad='*'}}
        {{rjust 'ok' size=5 pad='-'}}
        
        # --- Date and Time ---
        Requested at: {{now}}
        Formatted date: {{dateFormat now 'yyyy-MM-dd HH:mm:ss'}}
        
        # --- Math and Size ---
        {{#assign 'qty'}}{{jsonPath request.body '$.quantity'}}{{/assign}}
        {{#assign 'total'}}{{math price '*' qty}}{{/assign}}
        Total: {{total}}
        Item count: {{size request.headers.items}}
        
        # --- Regex Extraction ---
        {{#assign 'num'}}{{regexExtract request.path.1 '([0-9]+)'}}{{/assign}}
        Extracted number: {{num}}
        
        # --- Using "with" Context ---
        {{#with request.headers}}
        User-Agent: {{User-Agent}}
        {{/with}}
        
        # --- Available Request Parts Summary ---
        request.headers → Map of headers
        request.headers.NAME → Header value(s)
        request.properties → Map of headers
        request.properties.NAME → Header value(s)
        request.body → Raw request body (string)
        # --- Available Http Call Action Templates ---
        httpcalls.actionName.response.body → Response body of the http call action named "actionName"
        httpcalls.actionName.response.statuscode → Status code of the http call action named "actionName"
        httpcalls.actionName.request.url → Request URL of the http call action named "actionName"
        httpcalls.actionName.request.method → Request method of the http call action named "actionName
        httpcalls.actionName.request.headers → Request headers of the http call action named "actionName"
        httpcalls.actionName.request.body → Request body of the http call action named "actionName
         # --- Available Virtual Service Configuration Templates ---
        config.var1 → Value of the virtual service configuration parameter named "var1"
        
        # --- Error Handling Notes ---
        If the response returns raw unparsed template text (for example, showing {{request.body}} instead of the actual value), it means the template syntax is **invalid or malformed** and WireMock skipped template parsing.  
        If the response returns **HTTP 500** with an exception in the WireMock logs, it means the syntax was **parsed correctly but failed during runtime execution** (for example, referencing a non-existent variable, invalid JSONPath, or invalid helper argument).
        # --- Important Notes ---
        Each helper must always be opened and closed when block form is used (e.g. {{#assign ...}}{{/assign}}, {{#eq ...}}{{/eq}}, {{#each ...}}{{/each}}).  
        Inline helpers like {{join ...}}, {{replace ...}}, {{upper ...}}, {{jsonPath ...}} do not require closing tags.
    Actions:
    - read: Read a 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 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. Filter by virtual service (messaging service mock) id.
            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: Validates template used in transaction definition.
        args:
            template (str): Mandatory. The handlebars template to validate.
    - 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: Create a new 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.
            type (str): Mandatory. The type of the transaction.
            dsl (MessagingDsl): Mandatory. The DSL definition of the transaction.
            workspace_id (int): Mandatory. The id of the workspace.
            delay (int): Optional. Response delay in milliseconds.
            description (str): Optional.
            tags (list[str]): Optional.
            priority (int): Optional. Matching priority 1–2147483647, default 10.
            messagingTransactionMappings (dict): Optional. {sourceName, sourceType, destinations: [{destinationName, destinationType}]}.
            sampleBody (str): Optional. Example request body for documentation.
    - 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.
            type (str): Mandatory. The type of the transaction.
            dsl (MessagingDsl): Mandatory. The DSL definition of the transaction.
            workspace_id (int): Mandatory. The id of the workspace.
            delay (int): Optional. Response delay in milliseconds.
            description (str): Optional.
            tags (list[str]): Optional.
            priority (int): Optional. Matching priority 1–2147483647, default 10.
            messagingTransactionMappings (dict): Optional. {sourceName, sourceType, destinations: [{destinationName, destinationType}]}.
            sampleBody (str): Optional. Example request body for documentation.
    - 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 MessagingDsl with MessagingRequestDsl and MessagingResponseDsl):
    {'$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'}, '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'}, 'MessagingDestination': {'properties': {'destinationName': {'description': 'Destination name', 'title': 'Destinationname', 'type': 'string'}, 'destinationType': {'description': 'Destination type: QUEUE, TOPIC, or SUBSCRIPTION', 'title': 'Destinationtype', 'type': 'string'}}, 'required': ['destinationName', 'destinationType'], 'title': 'MessagingDestination', 'type': 'object'}, 'MessagingDsl': {'additionalProperties': True, 'properties': {'requestDsl': {'$ref': '#/$defs/MessagingRequestDsl', 'description': 'DSL for the incoming JMS message matching'}, 'responseDsl': {'$ref': '#/$defs/MessagingResponseDsl', 'description': 'DSL for the outgoing JMS message'}, 'type': {'default': 'MESSAGING', 'description': "The type of the transaction. Supported value is 'MESSAGING'.", 'title': 'Type', 'type': 'string'}}, 'required': ['requestDsl', 'responseDsl'], 'title': 'MessagingDsl', 'type': 'object'}, 'MessagingProperty': {'additionalProperties': True, 'properties': {'name': {'description': 'JMS property name', 'title': 'Name', 'type': 'string'}, 'value': {'description': 'JMS property value', 'title': 'Value', 'type': 'string'}, 'type': {'description': "JMS property type. Supported types are 'BOOLEAN', 'BYTE', 'SHORT', 'INT', 'LONG', 'FLOAT', 'DOUBLE' and 'STRING'.", 'title': 'Type', 'type': 'string'}}, 'required': ['name', 'value', 'type'], 'title': 'MessagingProperty', 'type': 'object'}, 'MessagingRequestDsl': {'additionalProperties': True, 'properties': {'headers': {'anyOf': [{'items': {'$ref': '#/$defs/MatcherDsl'}, 'type': 'array'}, {'type': 'null'}], 'default': [], 'description': 'List of matchers for the jms headers of the incoming message', 'title': 'Headers'}, 'properties': {'anyOf': [{'items': {'$ref': '#/$defs/MatcherDsl'}, 'type': 'array'}, {'type': 'null'}], 'default': [], 'description': 'List of matchers for the jms properties of the incoming message', 'title': 'Properties'}, 'body': {'anyOf': [{'items': {'$ref': '#/$defs/MatcherDsl'}, 'type': 'array'}, {'type': 'null'}], 'default': [], 'description': 'List of matchers for the jms message body', 'title': 'Body'}}, 'title': 'MessagingRequestDsl', 'type': 'object'}, 'MessagingResponseDsl': {'additionalProperties': True, 'properties': {'messageType': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'default': None, 'description': 'JMS message type of the response. One of: TEXT_MESSAGE, BYTES_MESSAGE, MAP_MESSAGE, STREAM_MESSAGE, OBJECT_MESSAGE.', 'title': 'Messagetype'}, 'content': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'default': '', 'description': 'Response body payload. Provide as plain text (e.g. \'{"status":"ok"}\') or as a valid base64 string. Plain text and invalid base64 are auto-encoded by the tool.', 'title': 'Content'}, 'charset': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'default': 'UTF-8', 'description': 'Character set for the response content (default UTF-8)', 'title': 'Charset'}, 'failoverEnabled': {'anyOf': [{'type': 'boolean'}, {'type': 'null'}], 'default': None, 'description': 'Whether failover is enabled for this response', 'title': 'Failoverenabled'}, 'headers': {'anyOf': [{'items': {'$ref': '#/$defs/HttpHeader'}, 'type': 'array'}, {'type': 'null'}], 'default': [], 'description': 'JMS headers of the outgoing message', 'title': 'Headers'}, 'properties': {'anyOf': [{'items': {'$ref': '#/$defs/MessagingProperty'}, 'type': 'array'}, {'type': 'null'}], 'default': [], 'description': 'JMS properties of the outgoing message', 'title': 'Properties'}, 'responseDelay': {'anyOf': [{'$ref': '#/$defs/ResponseDelay'}, {'type': 'null'}], 'default': None, 'description': 'Delay configuration applied to this response'}}, 'title': 'MessagingResponseDsl', 'type': 'object'}, 'MessagingTransactionMapping': {'additionalProperties': True, 'properties': {'sourceName': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'default': None, 'description': 'Transaction source name', 'title': 'Sourcename'}, 'sourceType': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'default': None, 'description': 'Source type: QUEUE, TOPIC, or SUBSCRIPTION', 'title': 'Sourcetype'}, 'destinations': {'default': [], 'description': 'Transaction destinations', 'items': {'$ref': '#/$defs/MessagingDestination'}, 'title': 'Destinations', 'type': 'array'}}, 'title': 'MessagingTransactionMapping', 'type': 'object'}, 'ResponseDelay': {'additionalProperties': True, 'properties': {'type': {'default': 'FIXED', 'description': 'Delay type: FIXED, LOGNORMAL, or UNIFORM', 'title': 'Type', 'type': 'string'}, 'fixedDelay': {'anyOf': [{'type': 'integer'}, {'type': 'null'}], 'default': None, 'description': 'Fixed delay in ms (FIXED type)', 'title': 'Fixeddelay'}, 'median': {'anyOf': [{'type': 'number'}, {'type': 'null'}], 'default': None, 'description': 'Median for LOGNORMAL distribution', 'title': 'Median'}, 'sigma': {'anyOf': [{'type': 'number'}, {'type': 'null'}], 'default': None, 'description': 'Sigma for LOGNORMAL distribution', 'title': 'Sigma'}, 'lower': {'anyOf': [{'type': 'number'}, {'type': 'null'}], 'default': None, 'description': 'Lower bound for UNIFORM distribution', 'title': 'Lower'}, 'upper': {'anyOf': [{'type': 'number'}, {'type': 'null'}], 'default': None, 'description': 'Upper bound for UNIFORM distribution', 'title': 'Upper'}}, 'title': 'ResponseDelay', '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': {'anyOf': [{'type': 'integer'}, {'type': 'null'}], 'default': None, 'description': 'The unique identifier of the transaction', 'title': 'Id'}, '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'}, 'description': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'default': None, 'description': 'Human-readable description', 'title': 'Description'}, 'tags': {'anyOf': [{'items': {'type': 'string'}, 'type': 'array'}, {'type': 'null'}], 'default': [], 'description': 'Tags for filtering and organization', 'title': 'Tags'}, 'priority': {'anyOf': [{'type': 'integer'}, {'type': 'null'}], 'default': 10, 'description': 'Matching priority (1–2147483647, default 10)', 'title': 'Priority'}, 'dsl': {'$ref': '#/$defs/MessagingDsl', 'description': 'Transaction DSL'}, 'messagingTransactionMappings': {'anyOf': [{'$ref': '#/$defs/MessagingTransactionMapping'}, {'type': 'null'}], 'default': None, 'description': 'Binds this transaction to a source queue/topic/subscription and specifies where responses are sent.'}, 'sampleBody': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'default': None, 'description': 'Example request body for documentation and testing', 'title': 'Samplebody'}, 'assets': {'anyOf': [{'items': {'$ref': '#/$defs/AssignedAsset'}, 'type': 'array'}, {'type': 'null'}], 'default': None, 'description': 'List of assets', 'title': 'Assets'}}, 'required': ['name', 'dsl'], 'title': 'MessagingTransaction', 'type': 'object'}
ParametersJSON Schema
NameRequiredDescriptionDefault
argsYes
actionYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
infoNoInfo messages
errorNoError message
totalNoTotal available records
resultNoResult
warningNoWarning messages
has_moreNoMore records per page to list

TDQS

A3.8/5.0
Behavior4/5

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

Without annotations, the description takes on transparency duty. It discloses important behaviors: content auto-base64 encoding when plain text is provided, the mandatory DSL type field, error handling notes distinguishing invalid template syntax from runtime failures, and the requirement to validate/convert templates before create/update. It does not describe permissions or side effects of asset assignment, but the provided error semantics are valuable.

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

Conciseness2/5

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

The description is excessively long, with dozens of lines explaining Handlebars template syntax, supported headers, and helper rules that are not directly needed to invoke the tool. Essential action details appear only after the template tutorial. This is not appropriately sized and does not front-load the most useful information.

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?

Given the tool's complexity—multiple actions, a nested MessagingDsl schema, and template validation—the description is thorough. It includes the full Transaction schema, action parameters, and error-handling notes. It lacks explicit description of return values for validate_template and convert_template, and assign actions, but overall covers the domain well.

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

Parameters4/5

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

The input schema is a generic action/args container with 0% parameter coverage, so the description must define all parameters. It does so for each action, listing required and optional fields with types and defaults (e.g., limit=10, offset=0, priority=1–2147483647). The full Transaction schema is embedded, adding rich semantics. However, the format is prose, not structured, which may reduce clarity.

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 description opens with 'Operations on JMS Messaging transactions' and enumerates specific actions (read, list, validate_template, create, update, etc.), clearly distinguishing it from HTTP transaction tools. However, the massive template tutorial buries the core purpose; the first sentence is generic, but the action list makes it clear.

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?

The description states 'Use this when a user needs to create or select a JMS messaging transaction,' providing a clear trigger condition. It also gives workflow guidance for create/update (validate and convert template first). It does not mention alternatives, but sibling tools are for different domains (e.g., HTTP transactions), so the usage context is sufficient.

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

virtual_services_messaging_virtual_serviceA
    Operations on messaging virtual services.
    Use this when a user needs to create, update, deploy, or manage a messaging virtual service.

    Actions:
    - read: Get full details of a virtual service.
        args:
            workspace_id (int): Mandatory.
            id (int): Mandatory.
    - list: List messaging virtual services.
        args:
            workspace_id (int): Mandatory.
            serviceId (int): Optional. Filter by service.
            limit (int, default=10): Max results (1–50).
            offset (int, default=0): Pagination offset.
    - create: Create a messaging virtual service for any supported protocol.
        args:
            workspace_id (int): Mandatory.
            name (str): Mandatory.
            serviceId (int): Mandatory.
            harborId (str): Mandatory. Location harbor ID.
            shipId (str): Mandatory. Location ship ID.
            messagingProtocol (str): Mandatory. One of: IBM_MQ9_JMS, IBM_MQ9_NATIVE,
                ACTIVE_MQ_CLASSIC, ACTIVE_MQ_ARTEMIS, KAFKA.
            brokerConfig (dict): Mandatory. Protocol-specific connection config.

Protocol-to-BrokerConfig field matrix: IBM_MQ9_JMS / IBM_MQ9_NATIVE: hostname, port (default "1414"), channel, queueManager, username, password, sslAuthentication, sslCipherSuite, queues, topics, subscriptions, flowConfigurations. ACTIVE_MQ_CLASSIC / ACTIVE_MQ_ARTEMIS: hostname, port (default "61616"), username, password, embeddedBroker, sslAuthentication, queues, topics, subscriptions, flowConfigurations. KAFKA: hostname, port (e.g. "broker1:9092,broker2:9092"), username (optional), password (optional), autoOffsetReset (earliest|latest|none), numPartitions, topics, flowConfigurations.

            mockServiceTransactions (list): Optional. Transaction references [{txnId, priority, ...}].
            mockServiceRecordings (list): Optional. Recording references [{recordingId, runtimeConfig}].
            recorderConfig (dict): Optional. Live recording config {maxMessagesCount, maxMessagesPerSecondCount, mappings}.
            priorityMode (str): Optional. DEFAULT or UNIQUE_PRIORITY.
            responseDelay (dict): Optional. {type, fixedDelay} or {type, median, sigma} etc.
            messagingRunnerEnabled (bool): Optional. Default true.
    - update: Update an existing messaging virtual service (partial — only provided fields change).
        args:
            workspace_id (int): Mandatory.
            id (int): Mandatory.
            name (str): Optional.
            serviceId (int): Optional.
            harborId (str): Optional.
            shipId (str): Optional.
            messagingProtocol (str): Optional. Changing protocol requires a new brokerConfig.
            brokerConfig (dict): Optional.
            mockServiceTransactions (list): Optional.
            mockServiceRecordings (list): Optional.
            recorderConfig (dict): Optional.
            priorityMode (str): Optional.
            responseDelay (dict): Optional.
            messagingRunnerEnabled (bool): Optional.
    - create-mq9: (Legacy) Create an IBM MQ9 virtual service using named fields.
        args:
            workspace_id (int): Mandatory.
            name (str): Mandatory.
            serviceId (int): Mandatory.
            harborId (str): Mandatory.
            shipId (str): Mandatory.
            mq9_broker_hostname (str): Mandatory.
            mq9_broker_port (int): Mandatory.
            mq9_broker_channel (str): Mandatory.
            mq9_queue_manager (str): Mandatory.
            mq9_queue_username (str): Mandatory.
            mq9_queue_password (str): Mandatory.
    - update-mq9: (Legacy) Update IBM MQ9 virtual service using named fields.
        args: Same as create-mq9 but all optional except workspace_id and vs_id (int).
    - deploy: Deploy a virtual service.
        Action result contains trackingId. Use tracking tool to poll until FINISHED or FAILED.
        args:
            workspace_id (int): Mandatory.
            id (int): Mandatory.
    - stop: Stop a running virtual service.
        Action result contains trackingId.
        args:
            workspace_id (int): Mandatory.
            id (int): Mandatory.
    - configure: Hot-reload transactions into a running virtual service.
        Action result contains trackingId.
        args:
            workspace_id (int): Mandatory.
            id (int): Mandatory.
    - assign_transactions: Assign transactions to a messaging virtual service.
        When the broker config uses flow configurations, pass flow_configuration so the
        server can copy the named flow's routing (sourceName, sourceType, destinations)
        onto every newly added transaction.
        args:
            workspace_id (int): Mandatory.
            id (int): Mandatory.
            transaction_ids (list[int]): Mandatory.
            flow_configuration (str): Optional. Name of a flow in brokerConfig.flowConfigurations[].name.
                Required when the VS uses flow-based routing — omitting it leaves transactions with
                an empty MessagingTransactionMapping (no routing).
    - unassign_transactions: Unassign transactions from a virtual service.
        args:
            workspace_id (int): Mandatory.
            id (int): Mandatory.
            transaction_ids (list[int]): Mandatory.
    - assign_recordings: Assign recordings to a messaging virtual service.
        args:
            workspace_id (int): Mandatory.
            id (int): Mandatory.
            recording_ids (list[int]): Mandatory. IDs of recordings to assign.
    - unassign_recordings: Unassign recordings from a messaging virtual service.
        args:
            workspace_id (int): Mandatory.
            id (int): Mandatory.
            recording_ids (list[int]): Mandatory. IDs of recordings to unassign.
    - assign_configuration: Assign a configuration to a virtual service.
        args:
            workspace_id (int): Mandatory.
            id (int): Mandatory.
            configuration_id (int): Mandatory. Pass null to unassign.
    - set_proxy: Set proxy configuration.
        args:
            workspace_id (int): Mandatory.
            id (int): Mandatory.
            proxyUrl (str): Mandatory.
            nonProxyHosts (str): Optional.
            username (str): Optional.
            password (str): Optional.
            certificate_id (int): Optional.
    - unset_proxy: Remove proxy configuration.
        args:
            workspace_id (int): Mandatory.
            id (int): Mandatory.
    - assign_queue: Assign a queue to the virtual service.
        args:
            workspace_id (int): Mandatory.
            id (int): Mandatory.
            queue_name (str): Mandatory.
    - assign_topic: Assign a topic to the virtual service.
        args:
            workspace_id (int): Mandatory.
            id (int): Mandatory.
            topic_name (str): Mandatory.

    VirtualService schema:
    {'$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'}, 'BrokerConfiguration': {'additionalProperties': True, 'properties': {'hostname': {'anyOf': [{'type': 'string'}, {'type': 'integer'}, {'type': 'null'}], 'default': None, 'description': 'Broker hostname', 'title': 'Hostname'}, 'port': {'anyOf': [{'type': 'string'}, {'type': 'integer'}, {'type': 'null'}], 'default': None, 'description': "Broker port (string). Use 'host:port,host:port' for Kafka multi-broker lists.", 'title': 'Port'}, 'channel': {'anyOf': [{'type': 'string'}, {'type': 'integer'}, {'type': 'null'}], 'default': None, 'description': 'IBM MQ channel name, e.g. SYSTEM.DEF.SVRCONN', 'title': 'Channel'}, 'queueManager': {'anyOf': [{'type': 'string'}, {'type': 'integer'}, {'type': 'null'}], 'default': None, 'description': 'IBM MQ queue manager name', 'title': 'Queuemanager'}, 'username': {'anyOf': [{'type': 'string'}, {'type': 'integer'}, {'type': 'null'}], 'default': None, 'description': 'Broker username', 'title': 'Username'}, 'password': {'anyOf': [{'type': 'string'}, {'type': 'integer'}, {'type': 'null'}], 'default': None, 'description': 'Broker password', 'title': 'Password'}, 'sslAuthentication': {'anyOf': [{'type': 'boolean'}, {'type': 'null'}], 'default': None, 'description': 'Enable SSL/TLS authentication', 'title': 'Sslauthentication'}, 'sslCipherSuite': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'default': None, 'description': 'SSL cipher suite (IBM MQ only), e.g. TLS_RSA_WITH_AES_256_CBC_SHA256', 'title': 'Sslciphersuite'}, 'embeddedBroker': {'anyOf': [{'type': 'boolean'}, {'type': 'null'}], 'default': None, 'description': 'Start an embedded broker — ACTIVE_MQ_CLASSIC and ARTEMIS only', 'title': 'Embeddedbroker'}, 'autoOffsetReset': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'default': None, 'description': 'Kafka offset reset strategy: earliest, latest, or none', 'title': 'Autooffsetreset'}, 'numPartitions': {'anyOf': [{'type': 'integer'}, {'type': 'null'}], 'default': None, 'description': 'Kafka number of partitions (default 1)', 'title': 'Numpartitions'}, 'queues': {'anyOf': [{'items': {'$ref': '#/$defs/BrokerQueue'}, 'type': 'array'}, {'type': 'null'}], 'default': [], 'description': 'List of queues', 'title': 'Queues'}, 'topics': {'anyOf': [{'items': {'$ref': '#/$defs/BrokerTopic'}, 'type': 'array'}, {'type': 'null'}], 'default': [], 'description': 'List of topics', 'title': 'Topics'}, 'subscriptions': {'anyOf': [{'items': {'$ref': '#/$defs/BrokerSubscription'}, 'type': 'array'}, {'type': 'null'}], 'default': [], 'description': 'List of subscriptions', 'title': 'Subscriptions'}, 'flowConfigurations': {'anyOf': [{'items': {'$ref': '#/$defs/FlowConfiguration'}, 'type': 'array'}, {'type': 'null'}], 'default': [], 'description': 'Broker-level flow routing configurations', 'title': 'Flowconfigurations'}}, 'title': 'BrokerConfiguration', 'type': 'object'}, 'BrokerQueue': {'properties': {'name': {'description': 'Queue name', 'title': 'Name', 'type': 'string'}}, 'required': ['name'], 'title': 'BrokerQueue', 'type': 'object'}, 'BrokerSubscription': {'properties': {'name': {'description': 'Subscription name', 'title': 'Name', 'type': 'string'}}, 'required': ['name'], 'title': 'BrokerSubscription', 'type': 'object'}, 'BrokerTopic': {'properties': {'name': {'description': 'Topic name', 'title': 'Name', 'type': 'string'}, 'isDurable': {'anyOf': [{'type': 'boolean'}, {'type': 'null'}], 'default': None, 'description': 'Whether the subscription is durable', 'title': 'Isdurable'}, 'durableSubscriptionName': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'default': None, 'description': 'Durable subscription name — required when isDurable=True', 'title': 'Durablesubscriptionname'}}, 'required': ['name'], 'title': 'BrokerTopic', 'type': 'object'}, 'Endpoint': {'properties': {'endpoint': {'description': 'Endpoint URL', 'title': 'Endpoint', 'type': 'string'}}, 'required': ['endpoint'], 'title': 'Endpoint', 'type': 'object'}, 'FlowConfiguration': {'properties': {'name': {'description': 'Flow configuration name', 'title': 'Name', 'type': 'string'}, 'transactionMapping': {'$ref': '#/$defs/FlowTransactionMapping', 'description': 'Source-to-destination routing for this flow'}}, 'required': ['name', 'transactionMapping'], 'title': 'FlowConfiguration', 'type': 'object'}, 'FlowTransactionMapping': {'properties': {'sourceName': {'description': 'Source queue/topic/subscription name', 'title': 'Sourcename', 'type': 'string'}, 'sourceType': {'description': 'Source type: QUEUE, TOPIC, or SUBSCRIPTION', 'title': 'Sourcetype', 'type': 'string'}, 'destinations': {'default': [], 'description': 'Destination list', 'items': {'$ref': '#/$defs/MessagingDestination'}, 'title': 'Destinations', 'type': 'array'}}, 'required': ['sourceName', 'sourceType'], 'title': 'FlowTransactionMapping', 'type': 'object'}, 'MessagingDestination': {'properties': {'destinationName': {'description': 'Destination name', 'title': 'Destinationname', 'type': 'string'}, 'destinationType': {'description': 'Destination type: QUEUE, TOPIC, or SUBSCRIPTION', 'title': 'Destinationtype', 'type': 'string'}}, 'required': ['destinationName', 'destinationType'], 'title': 'MessagingDestination', 'type': 'object'}, 'MockServiceRecording': {'properties': {'recordingId': {'description': 'ID of the recording to include in this virtual service', 'title': 'Recordingid', 'type': 'integer'}, 'runtimeConfig': {'anyOf': [{'$ref': '#/$defs/ReplayConfig'}, {'type': 'null'}], 'default': None, 'description': 'Replay configuration for this recording'}}, 'required': ['recordingId'], 'title': 'MockServiceRecording', 'type': 'object'}, 'MockServiceTransaction': {'properties': {'txnId': {'description': 'Transaction id.', 'title': 'Txnid', 'type': 'integer'}, 'priority': {'default': 10, 'description': 'Transaction Priority. If not specified, defaults to 10.', 'title': 'Priority', 'type': 'integer'}, 'destinations': {'anyOf': [{'items': {'$ref': '#/$defs/MessagingDestination'}, 'type': 'array'}, {'type': 'null'}], 'default': [], 'description': 'List of messaging destinations.', 'title': 'Destinations'}}, 'required': ['txnId'], 'title': 'MockServiceTransaction', 'type': 'object'}, 'ProxyConfiguration': {'additionalProperties': True, 'properties': {'proxyUrl': {'description': 'Proxy url', 'title': 'Proxyurl', 'type': 'string'}, 'nonProxyHosts': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'default': None, 'description': 'Non proxy hosts, | separated', 'title': 'Nonproxyhosts'}, 'username': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'description': 'Proxy username', 'title': 'Username'}, 'password': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'description': 'Proxy password', 'title': 'Password'}, 'certificateId': {'anyOf': [{'type': 'integer'}, {'type': 'null'}], 'default': None, 'description': 'Certificate asset identifier', 'title': 'Certificateid'}}, 'required': ['proxyUrl', 'username', 'password'], 'title': 'ProxyConfiguration', 'type': 'object'}, 'RecorderConfig': {'additionalProperties': True, 'properties': {'maxMessagesCount': {'anyOf': [{'type': 'integer'}, {'type': 'null'}], 'default': None, 'description': 'Maximum number of messages to capture per recording session', 'title': 'Maxmessagescount'}, 'maxMessagesPerSecondCount': {'anyOf': [{'type': 'integer'}, {'type': 'null'}], 'default': None, 'description': 'Rate limit for capturing messages per second', 'title': 'Maxmessagespersecondcount'}, 'mappings': {'anyOf': [{'items': {'$ref': '#/$defs/RecorderMapping'}, 'type': 'array'}, {'type': 'null'}], 'default': [], 'description': 'Inbound/outbound destination mappings for recording', 'title': 'Mappings'}}, 'title': 'RecorderConfig', 'type': 'object'}, 'RecorderMapping': {'properties': {'inboundDestination': {'description': 'Source destination to record from', 'title': 'Inbounddestination', 'type': 'string'}, 'outboundDestination': {'description': 'Destination to replay captured messages to', 'title': 'Outbounddestination', 'type': 'string'}, 'originType': {'description': 'Origin type: QUEUE, TOPIC, or SUBSCRIPTION', 'title': 'Origintype', 'type': 'string'}}, 'required': ['inboundDestination', 'outboundDestination', 'originType'], 'title': 'RecorderMapping', 'type': 'object'}, 'ReplayConfig': {'additionalProperties': True, 'properties': {'replayCount': {'anyOf': [{'type': 'integer'}, {'type': 'null'}], 'default': 1, 'description': 'Number of times to replay the recording', 'title': 'Replaycount'}, 'delayBetweenReplays': {'anyOf': [{'type': 'integer'}, {'type': 'null'}], 'default': 0, 'description': 'Delay in ms between replays', 'title': 'Delaybetweenreplays'}, 'initialDelay': {'anyOf': [{'type': 'integer'}, {'type': 'null'}], 'default': 0, 'description': 'Initial delay in ms before the first replay', 'title': 'Initialdelay'}}, 'title': 'ReplayConfig', 'type': 'object'}, 'ResponseDelay': {'additionalProperties': True, 'properties': {'type': {'default': 'FIXED', 'description': 'Delay type: FIXED, LOGNORMAL, or UNIFORM', 'title': 'Type', 'type': 'string'}, 'fixedDelay': {'anyOf': [{'type': 'integer'}, {'type': 'null'}], 'default': None, 'description': 'Fixed delay in ms (FIXED type)', 'title': 'Fixeddelay'}, 'median': {'anyOf': [{'type': 'number'}, {'type': 'null'}], 'default': None, 'description': 'Median for LOGNORMAL distribution', 'title': 'Median'}, 'sigma': {'anyOf': [{'type': 'number'}, {'type': 'null'}], 'default': None, 'description': 'Sigma for LOGNORMAL distribution', 'title': 'Sigma'}, 'lower': {'anyOf': [{'type': 'number'}, {'type': 'null'}], 'default': None, 'description': 'Lower bound for UNIFORM distribution', 'title': 'Lower'}, 'upper': {'anyOf': [{'type': 'number'}, {'type': 'null'}], 'default': None, 'description': 'Upper bound for UNIFORM distribution', 'title': 'Upper'}}, 'title': 'ResponseDelay', 'type': 'object'}}, 'properties': {'id': {'description': 'The unique identifier of the virtual service', 'title': 'Id', 'type': 'integer'}, 'name': {'description': 'The name of the virtual service', 'title': 'Name', 'type': 'string'}, 'status': {'default': '', 'description': 'The status of the virtual service', 'title': 'Status', 'type': 'string'}, 'serviceId': {'description': 'The unique identifier of the service where the virtual service belongs', 'title': 'Serviceid', 'type': 'integer'}, 'type': {'description': "Type of the virtual service. Possible values are 'TRANSACTIONAL' and 'MESSAGING'. Transactional virtual services are used for simulating user interactions with web applications, while messaging virtual services are used for simulating message-based interactions.", 'title': 'Type', 'type': 'string'}, 'harborId': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'default': None, 'description': 'Location harbor identifier', 'title': 'Harborid'}, 'shipId': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'default': None, 'description': 'Location ship identifier', 'title': 'Shipid'}, 'configurationId': {'anyOf': [{'type': 'integer'}, {'type': 'null'}], 'default': None, 'description': 'Configuration identifier', 'title': 'Configurationid'}, 'noMatchingRequestPreference': {'description': "For transactional virtual services, defines the behavior when no matching request is found. Possible values are 'return404' and 'bypasslive'.", 'title': 'Nomatchingrequestpreference', 'type': 'string'}, 'endpointPreference': {'description': "For transactional virtual services, defines endpoint schema. Possible values are 'HTTP' and 'HTTPS'.", 'title': 'Endpointpreference', 'type': 'string'}, 'replicas': {'default': 1, 'description': 'The number of replicas for the virtual service. Always set to 1.', 'title': 'Replicas', 'type': 'integer'}, 'mockServiceTransactions': {'anyOf': [{'items': {'$ref': '#/$defs/MockServiceTransaction'}, 'type': 'array'}, {'type': 'null'}], 'default': [], 'description': 'List of transaction definitions associated with the virtual service', 'title': 'Mockservicetransactions'}, 'mockServiceRecordings': {'anyOf': [{'items': {'$ref': '#/$defs/MockServiceRecording'}, 'type': 'array'}, {'type': 'null'}], 'default': [], 'description': 'List of recording references associated with the virtual service', 'title': 'Mockservicerecordings'}, 'endpoints': {'anyOf': [{'items': {'$ref': '#/$defs/Endpoint'}, 'type': 'array'}, {'type': 'null'}], 'default': [], 'description': 'List of virtual service endpoints. Available after deployment only.', 'title': 'Endpoints'}, 'httpRunnerEnabled': {'default': True, 'description': "Http runner enabled flag, must be enabled for virtual services with 'TRANSACTIONAL' type.", 'title': 'Httprunnerenabled', 'type': 'boolean'}, 'messagingRunnerEnabled': {'anyOf': [{'type': 'boolean'}, {'type': 'null'}], 'default': None, 'description': "Messaging runner enabled flag for 'MESSAGING' type virtual services.", 'title': 'Messagingrunnerenabled'}, 'messagingProtocol': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'default': None, 'description': 'Messaging broker protocol. One of: IBM_MQ9_JMS, IBM_MQ9_NATIVE, ACTIVE_MQ_CLASSIC, ACTIVE_MQ_ARTEMIS, KAFKA.', 'title': 'Messagingprotocol'}, 'priorityMode': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'default': None, 'description': 'Transaction selection mode: DEFAULT or UNIQUE_PRIORITY.', 'title': 'Prioritymode'}, 'responseDelay': {'anyOf': [{'$ref': '#/$defs/ResponseDelay'}, {'type': 'null'}], 'default': None, 'description': 'Global response delay applied to all transactions in this virtual service.'}, 'recorderConfig': {'anyOf': [{'$ref': '#/$defs/RecorderConfig'}, {'type': 'null'}], 'default': None, 'description': 'Configuration for recording live broker traffic.'}, 'classPathJars': {'anyOf': [{'additionalProperties': True, 'type': 'object'}, {'type': 'null'}], 'default': None, 'description': 'Custom broker JAR paths, e.g. {"paths": ["string"]}.', 'title': 'Classpathjars'}, 'proxy': {'anyOf': [{'$ref': '#/$defs/ProxyConfiguration'}, {'type': 'null'}], 'default': None, 'description': 'Proxy configuration for the virtual service'}, 'brokerConfig': {'anyOf': [{'$ref': '#/$defs/BrokerConfiguration'}, {'type': 'null'}], 'default': None, 'description': 'Messaging broker connection configuration'}, 'assets': {'anyOf': [{'items': {'$ref': '#/$defs/AssignedAsset'}, 'type': 'array'}, {'type': 'null'}], 'default': None, 'description': 'List of assets', 'title': 'Assets'}}, 'required': ['id', 'name', 'serviceId', 'type', 'noMatchingRequestPreference', 'endpointPreference'], 'title': 'VirtualService', 'type': 'object'}
    Action result schema:
    {'properties': {'tracking_id': {'description': 'Action tracking id', 'title': 'Tracking Id', 'type': 'string'}}, 'required': ['tracking_id'], 'title': 'ActionResult', 'type': 'object'}
ParametersJSON Schema
NameRequiredDescriptionDefault
argsYes
actionYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
infoNoInfo messages
errorNoError message
totalNoTotal available records
resultNoResult
warningNoWarning messages
has_moreNoMore records per page to list

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It does well by explaining that deploy/stop/configure return trackingId and require polling, that update is partial, that flow_configuration is required for flow-based routing (with the consequence of empty mappings if omitted), and includes validation details. It could go further by stating permission requirements or side effects of unassign, but it provides substantial behavioral context.

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?

The description is extremely long and includes a massive JSON schema dump at the end. While the action list is well-structured and the length is partly justified by the large number of actions, the embedded VirtualService schema is raw JSON that bloats the text and could be better referenced or placed in an output schema. It is not concise, though it is organized with clear headings and the key guidance is front-loaded.

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 tool with 18 actions, an impoverished input schema, and no annotations, the description covers the essential operational details: all actions, parameters, defaults, protocol specifics, tracking behavior, and the response schema. It also provides the full VirtualService schema for understanding return values. Gaps remain around auth, error handling, and rate limits, but given the complexity, this is highly complete.

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 just `action` and freeform `args`, so the description is the only source of parameter meaning. It thoroughly documents each action's args, marks mandatory vs optional, provides defaults (e.g., limit=10, offset=0), enumerates protocol choices, and gives a detailed protocol-to-brokerConfig matrix. This fully compensates for the 0% schema coverage.

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 description clearly states 'Operations on messaging virtual services' and 'Use this when a user needs to create, update, deploy, or manage a messaging virtual service.' This provides a specific verb and resource, distinguishing it from transaction-focused siblings like virtual_services_messaging_transaction. However, it does not explicitly contrast with the generic virtual_services_virtual_service tool, so it loses a point for not fully differentiating.

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 explicit usage guidance: 'Use this when a user needs to create, update, deploy, or manage a messaging virtual service.' This is clear context for when to invoke this tool. It does not mention when NOT to use it or name alternatives, so it falls short of a 5 but is well above vague guidance.

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

virtual_services_recordingA
    Operations on recordings and recorded messages within recordings.
    Recordings capture live broker traffic and can be replayed by a messaging virtual service.

    ## Recording actions

    - list_recordings: List recordings in a workspace.
        args:
            workspace_id (int): Mandatory.
            serviceId (int): Optional. Filter by parent service.
            serviceMockId (int): Optional. Filter by virtual service (messaging service mock).
            limit (int, default=50): Max results.
            offset (int, default=0): Pagination offset.
            fetchMessages (bool, default=false): Include inline messages in response.
    - read_recording: Get full details of a recording.
        args:
            workspace_id (int): Mandatory.
            id (int): Mandatory. Recording ID.
    - create_recording: Create a new recording.
        args:
            workspace_id (int): Mandatory.
            name (str): Mandatory.
            serviceId (int): Optional.
            description (str): Optional.
            tags (list[str]): Optional.
            messages (list): Optional. Inline RecordedMessage objects for seed data.
            runtimeConfig (dict): Optional. {replayCount, delayBetweenReplays, initialDelay}.
    - update_recording: Full replacement of a recording.
        args:
            workspace_id (int): Mandatory.
            id (int): Mandatory.
            name (str): Mandatory.
            serviceId (int): Optional.
            description (str): Optional.
            tags (list[str]): Optional.
            messages (list): Optional.
            runtimeConfig (dict): Optional.
    - patch_recording: Partial update — only provided fields are changed.
        args:
            workspace_id (int): Mandatory.
            id (int): Mandatory.
            name (str): Optional.
            serviceId (int): Optional.
            description (str): Optional.
            tags (list[str]): Optional.
            messages (list): Optional.
            runtimeConfig (dict): Optional. {replayCount, delayBetweenReplays, initialDelay}.

    ## Recorded message actions

    content fields are always base64-encoded. Assign sequential index values to control
    playback order; if omitted the server assigns order by insertion sequence.

    Notable JMS headers (use in headers[].name):
      JMS_MESSAGE_ID, JMS_CORRELATION_ID, JMS_TIMESTAMP, JMS_DELIVERY_MODE,
      JMS_REDELIVERED, JMS_EXPIRATION, JMS_PRIORITY
    IBM MQ MQMD headers (IBM MQ protocols only):
      MQ9_MQMD_MsgId, MQ9_MQMD_CorrelId, MQ9_MQMD_Format, MQ9_MQMD_ReplyToQ,
      MQ9_MQMD_ReplyToQMgr, MQ9_MQMD_Persistence, MQ9_MQMD_Priority, MQ9_MQMD_Expiry

    - list_messages: List messages within a recording (sorted by index).
        args:
            workspace_id (int): Mandatory.
            recording_id (int): Mandatory.
            limit (int, default=50): Max results.
            offset (int, default=0): Pagination offset.
    - create_message: Add a recorded message to a recording.
        args:
            workspace_id (int): Mandatory.
            recording_id (int): Mandatory.
            messageType (str): Mandatory. TEXT_MESSAGE | BYTES_MESSAGE | MAP_MESSAGE | STREAM_MESSAGE | OBJECT_MESSAGE.
            content (str): Mandatory. Base64-encoded payload.
            destination (str): Mandatory. Target queue/topic/subscription name.
            destinationType (str): Mandatory. QUEUE | TOPIC | SUBSCRIPTION.
            name (str): Optional.
            index (int): Optional. Sequence position (auto-assigned if omitted).
            delay (int): Optional. Inter-message delay in ms.
            correlationId (str): Optional.
            headers (list): Optional. [{name, value}] JMS/MQMD headers.
            properties (list): Optional. [{name, value, type}] JMS properties.
            recordedAt (str): Optional. ISO-8601 timestamp.
    - update_message: Full replacement of a recorded message.
        args: Same as create_message plus message_id (int): Mandatory.
    - patch_message: Partial update of a recorded message — only provided fields change.
        args:
            workspace_id (int): Mandatory.
            recording_id (int): Mandatory.
            message_id (int): Mandatory.
            messageType (str): Optional.
            content (str): Optional. Base64-encoded.
            destination (str): Optional.
            destinationType (str): Optional.
            name (str): Optional.
            index (int): Optional.
            delay (int): Optional.
            correlationId (str): Optional.
            headers (list): Optional.
            properties (list): Optional.
            recordedAt (str): Optional. ISO-8601 timestamp.

    Recording 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'}, 'MessagingProperty': {'additionalProperties': True, 'properties': {'name': {'description': 'JMS property name', 'title': 'Name', 'type': 'string'}, 'value': {'description': 'JMS property value', 'title': 'Value', 'type': 'string'}, 'type': {'description': "JMS property type. Supported types are 'BOOLEAN', 'BYTE', 'SHORT', 'INT', 'LONG', 'FLOAT', 'DOUBLE' and 'STRING'.", 'title': 'Type', 'type': 'string'}}, 'required': ['name', 'value', 'type'], 'title': 'MessagingProperty', 'type': 'object'}, 'RecordedMessage': {'properties': {'id': {'anyOf': [{'type': 'integer'}, {'type': 'null'}], 'default': None, 'description': 'Unique identifier of the recorded message', 'title': 'Id'}, 'name': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'default': None, 'description': 'Message name', 'title': 'Name'}, 'messageType': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'default': None, 'description': 'JMS message type. One of: TEXT_MESSAGE, BYTES_MESSAGE, MAP_MESSAGE, STREAM_MESSAGE, OBJECT_MESSAGE.', 'title': 'Messagetype'}, 'content': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'default': None, 'description': 'Base64-encoded message payload', 'title': 'Content'}, 'destination': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'default': None, 'description': 'Target queue/topic/subscription name', 'title': 'Destination'}, 'destinationType': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'default': None, 'description': 'Destination type: QUEUE, TOPIC, or SUBSCRIPTION', 'title': 'Destinationtype'}, 'index': {'anyOf': [{'type': 'integer'}, {'type': 'null'}], 'default': None, 'description': 'Sequence position within the recording (controls playback order)', 'title': 'Index'}, 'delay': {'anyOf': [{'type': 'integer'}, {'type': 'null'}], 'default': None, 'description': 'Inter-message delay in ms', 'title': 'Delay'}, 'correlationId': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'default': None, 'description': 'JMS correlation ID', 'title': 'Correlationid'}, 'headers': {'anyOf': [{'items': {'$ref': '#/$defs/HttpHeader'}, 'type': 'array'}, {'type': 'null'}], 'default': [], 'description': 'JMS / MQMD headers', 'title': 'Headers'}, 'properties': {'anyOf': [{'items': {'$ref': '#/$defs/MessagingProperty'}, 'type': 'array'}, {'type': 'null'}], 'default': [], 'description': 'JMS properties', 'title': 'Properties'}, 'recordedAt': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'default': None, 'description': 'ISO-8601 timestamp when message was recorded', 'title': 'Recordedat'}}, 'title': 'RecordedMessage', 'type': 'object'}, 'ReplayConfig': {'additionalProperties': True, 'properties': {'replayCount': {'anyOf': [{'type': 'integer'}, {'type': 'null'}], 'default': 1, 'description': 'Number of times to replay the recording', 'title': 'Replaycount'}, 'delayBetweenReplays': {'anyOf': [{'type': 'integer'}, {'type': 'null'}], 'default': 0, 'description': 'Delay in ms between replays', 'title': 'Delaybetweenreplays'}, 'initialDelay': {'anyOf': [{'type': 'integer'}, {'type': 'null'}], 'default': 0, 'description': 'Initial delay in ms before the first replay', 'title': 'Initialdelay'}}, 'title': 'ReplayConfig', 'type': 'object'}}, 'properties': {'id': {'anyOf': [{'type': 'integer'}, {'type': 'null'}], 'default': None, 'description': 'Unique identifier of the recording', 'title': 'Id'}, 'name': {'description': 'Recording name', 'title': 'Name', 'type': 'string'}, 'serviceId': {'anyOf': [{'type': 'integer'}, {'type': 'null'}], 'default': None, 'description': 'ID of the parent service this recording belongs to', 'title': 'Serviceid'}, 'description': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'default': None, 'description': 'Human-readable description', 'title': 'Description'}, 'tags': {'anyOf': [{'items': {'type': 'string'}, 'type': 'array'}, {'type': 'null'}], 'default': [], 'description': 'Tags for filtering', 'title': 'Tags'}, 'messages': {'anyOf': [{'items': {'$ref': '#/$defs/RecordedMessage'}, 'type': 'array'}, {'type': 'null'}], 'default': [], 'description': 'Recorded messages (inline on create or fetch with fetchMessages=true)', 'title': 'Messages'}, 'runtimeConfig': {'anyOf': [{'$ref': '#/$defs/ReplayConfig'}, {'type': 'null'}], 'default': None, 'description': 'Replay configuration for this recording'}}, 'required': ['name'], 'title': 'Recording', 'type': 'object'}
    RecordedMessage 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'}, 'MessagingProperty': {'additionalProperties': True, 'properties': {'name': {'description': 'JMS property name', 'title': 'Name', 'type': 'string'}, 'value': {'description': 'JMS property value', 'title': 'Value', 'type': 'string'}, 'type': {'description': "JMS property type. Supported types are 'BOOLEAN', 'BYTE', 'SHORT', 'INT', 'LONG', 'FLOAT', 'DOUBLE' and 'STRING'.", 'title': 'Type', 'type': 'string'}}, 'required': ['name', 'value', 'type'], 'title': 'MessagingProperty', 'type': 'object'}}, 'properties': {'id': {'anyOf': [{'type': 'integer'}, {'type': 'null'}], 'default': None, 'description': 'Unique identifier of the recorded message', 'title': 'Id'}, 'name': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'default': None, 'description': 'Message name', 'title': 'Name'}, 'messageType': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'default': None, 'description': 'JMS message type. One of: TEXT_MESSAGE, BYTES_MESSAGE, MAP_MESSAGE, STREAM_MESSAGE, OBJECT_MESSAGE.', 'title': 'Messagetype'}, 'content': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'default': None, 'description': 'Base64-encoded message payload', 'title': 'Content'}, 'destination': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'default': None, 'description': 'Target queue/topic/subscription name', 'title': 'Destination'}, 'destinationType': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'default': None, 'description': 'Destination type: QUEUE, TOPIC, or SUBSCRIPTION', 'title': 'Destinationtype'}, 'index': {'anyOf': [{'type': 'integer'}, {'type': 'null'}], 'default': None, 'description': 'Sequence position within the recording (controls playback order)', 'title': 'Index'}, 'delay': {'anyOf': [{'type': 'integer'}, {'type': 'null'}], 'default': None, 'description': 'Inter-message delay in ms', 'title': 'Delay'}, 'correlationId': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'default': None, 'description': 'JMS correlation ID', 'title': 'Correlationid'}, 'headers': {'anyOf': [{'items': {'$ref': '#/$defs/HttpHeader'}, 'type': 'array'}, {'type': 'null'}], 'default': [], 'description': 'JMS / MQMD headers', 'title': 'Headers'}, 'properties': {'anyOf': [{'items': {'$ref': '#/$defs/MessagingProperty'}, 'type': 'array'}, {'type': 'null'}], 'default': [], 'description': 'JMS properties', 'title': 'Properties'}, 'recordedAt': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'default': None, 'description': 'ISO-8601 timestamp when message was recorded', 'title': 'Recordedat'}}, 'title': 'RecordedMessage', 'type': 'object'}
ParametersJSON Schema
NameRequiredDescriptionDefault
argsYes
actionYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
infoNoInfo messages
errorNoError message
totalNoTotal available records
resultNoResult
warningNoWarning messages
has_moreNoMore records per page to list

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure and does so extensively. It discloses base64 encoding of content fields, sequential index ordering for playback control, server-side auto-assignment when index omitted, the distinction between full replacement (update_recording/update_message) and partial update (patch_recording/patch_message), default values, and allowed JMS/MQMD header names. This goes well beyond what a generic schema would convey.

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-organized with a concise opening, sections for recording and message actions, bulleted parameter lists, and code blocks for schemas. However, it is somewhat verbose because the same JSON schema for Recording and RecordedMessage is duplicated almost verbatim twice. Despite this redundancy, the structure is clear and front-loaded with the most important purpose statement.

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 complex tool with nine sub-actions and nested object parameters, the description is remarkably complete. It covers all available actions, their arguments, behavioral details, allowed enums, and default settings. Since an output schema exists, the lack of explicit return-value explanations is acceptable per the rubric, and the description fully compensates for the sparse input schema.

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 a minimal dispatcher ({action, args}) with zero parameter descriptions, so the description is the only source of parameter semantics. It thoroughly documents mandatory vs optional args, types, defaults, and meaning for every sub-action, and includes full Recording and RecordedMessage schemas. This is essential for correct invocation and far exceeds the structured information available.

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's purpose: 'Operations on recordings and recorded messages within recordings' with a contextual explanation of what recordings are and how they're used (replayable by messaging virtual services). It distinguishes itself from sibling tools by focusing specifically on recording lifecycle management, and lists all nine sub-actions explicitly, making the scope unambiguous.

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?

The description provides clear context on what the tool manages and details each sub-action with parameters, but it does not explicitly state when to use this tool versus alternatives or mention exclusions. Since the tool name is specific and the description starts with the resource it operates on, the usage context is implied rather than explicitly contrasted with sibling tools.

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

virtual_services_sandboxA
    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'}
ParametersJSON Schema
NameRequiredDescriptionDefault
argsYes
actionYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
infoNoInfo messages
errorNoError message
totalNoTotal available records
resultNoResult
warningNoWarning messages
has_moreNoMore records per page to list

TDQS

A4.9/5.0
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.

virtual_services_serviceA
    Operations on services.
    Use this when a user needs to create, read, update, list, or select a service.
    Actions:
    - read: Read a Service. Get the information of a service.
        args(dict): Dictionary with the following required parameters:
            workspace_id (int): Mandatory. The id of the workspace to list services from.
            service_id (int): Mandatory. The id of the service to get information.
    - list: List all services. 
        args(dict): Dictionary with the following required parameters:
            workspace_id (int): Mandatory. The id of the workspace to list services from.
            limit (int, default=10, valid=[1 to 50]): The number of services to list.
            offset (int, default=0): Number of services to skip.
    - create: Create a new service.
        args(dict): Dictionary with the following required parameters:
            service_name (str): Mandatory. The required name of the service to create.
            workspace_id (int): Mandatory. The id of the workspace to create service in.
    - update: Update service.
        args(dict): Dictionary with the following required parameters:
            workspace_id (int): Mandatory. The id of the workspace to update service in.
            id (int): Mandatory. The id of the service for update.
            service_name (str): Mandatory. The new name of the service.
    Service Schema:
    {'properties': {'id': {'description': 'The unique identifier of the service', 'title': 'Id', 'type': 'integer'}, 'name': {'description': 'The name of the service', 'title': 'Name', 'type': 'string'}}, 'required': ['id', 'name'], 'title': 'Service', 'type': 'object'}
ParametersJSON Schema
NameRequiredDescriptionDefault
argsYes
actionYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
infoNoInfo messages
errorNoError message
totalNoTotal available records
resultNoResult
warningNoWarning messages
has_moreNoMore records per page to list

TDQS

A3.5/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden. It does include the output schema (Service Schema), which is useful, but it does not disclose side effects (e.g., whether update mutates data), permissions required, error behavior, or response format for create/update. For a CRUD tool with mutation operations, this lack of behavioral context is a significant gap.

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 actions broken into read, list, create, and update, each with args. It front-loads the purpose and uses a consistent format. However, it is somewhat repetitive with 'Mandatory' repeated and includes the full Service Schema inline, which could be trimmed if already available as an output schema. Still, it earns a 4 for clarity and organization.

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

Completeness3/5

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

The description covers all actions and parameter semantics, and includes the output schema, which is good. However, it lacks guidance on when to use this tool versus sibling tools, does not mention the absence of a delete action (or any destructive operations), and provides no details on returns or errors. Given the tool's complexity (4 actions), it is adequate but has clear gaps in behavioral and comparative 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 has an open 'args' object with 0% coverage, so the description fully compensates. Each action lists required parameters with types, defaults, and valid ranges (e.g., limit default=10, valid=[1 to 50]). It clearly maps parameters to actions, providing meaning far beyond the schema. Minor flaw: it labels optional parameters as 'required', but the information itself is detailed and helpful.

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 description clearly states the tool's purpose: 'Operations on services. Use this when a user needs to create, read, update, list, or select a service.' It lists specific verbs (create, read, update, list) and identifies the resource (service). However, it does not differentiate from sibling tools that also mention services (e.g., virtual_services_virtual_service), so it misses the explicit sibling differentiation that would earn a 5.

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

Usage Guidelines3/5

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

It provides a clear 'when to use' statement ('Use this when a user needs to create, read, update, list, or select a service'), but it does not mention when not to use it or name alternative sibling tools. The action-specific args give context for each operation, but there is no explicit guidance on choosing this tool over similar service-related tools, so it falls short of a 4.

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

virtual_services_test_dataA
    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): matcherName "equals_json" (variables embedded as JSON values e.g. {"id": "${id}"})
        or "matches_json" with equalTo() helper e.g. [[$.field, equalTo(${id})]]
      - Body (XML): matcherName "equals_xml" or "matches_xml" with matching() helper
      - 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'}
ParametersJSON Schema
NameRequiredDescriptionDefault
argsYes
actionYes

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden of disclosure and does so thoroughly. It reveals that matcher names must follow exact rules or matching fails, repeated variables must resolve to the same value, undefined variables are treated as literals, and update_from_csv only updates the data-model JSON unless upload_csv=true. These are critical behavioral traits that affect correct usage.

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 extremely well-structured: it starts with a high-level overview, then matcher rules, additional rules, and each action with arg details. It front-loads the most critical constraints (matcher naming, variable resolution) before diving into actions. Some redundant phrases like 'Mandatory' appear in every list, but overall every sentence provides necessary operational detail.

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 tool's high complexity (six actions, intricate matcher rules, free-form args), the description is remarkably complete. It documents all actions, parameters, defaults, caveats, and even includes the TdmAsset response schema inline. Since there is no output schema, this is a significant bonus for understanding return values.

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 minimal, with only action and args as a free-form object, so schema coverage is 0%. The description compensates by documenting each action's parameters with types, mandatory flags, defaults (e.g., repeat default=1000, limit=50), and examples such as field_mappings entries with {name, csv_column}. This is far beyond what the schema provides.

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's purpose: 'Operations on TDM (Test Data Manager) datasets for virtual services.' It enumerates six distinct actions (create_from_schema, create_from_csv, list, read, update, update_from_csv), which distinguishes it from sibling tools that handle HTTP transactions, messaging, or asset management.

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?

The description provides explicit guidance on when to use specific actions based on dataset creation method, e.g., 'Use this when the dataset was created with create_from_schema' for update and 'Use this when the dataset was created with create_from_csv' for update_from_csv. It also clarifies that Handlebars is separate, but it does not explicitly compare this tool against sibling tools.

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

virtual_services_trackingA
    Operations on tracking objects.
    Use this tool to read or poll tracking status by tracking ID (UUID).
    Call this whenever you have a tracking ID and need to know the status or result of an async operation.
    Actions:
    - read: Read a Tracking. Get status and result of a virtual service deploy/stop/configure operation.
        args(dict): Dictionary with the following required parameters:
            tracking_id (str): Mandatory. The tracking UUID to read.
    - read_asset_tracking: Read an Asset Tracking. Get the status and result of an asset upload operation.
        Use this action — NOT `read` — when the tracking ID came from an asset upload (e.g. "read asset tracking info <uuid>").
        args(dict): Dictionary with the following required parameters:
            tracking_id (str): Mandatory. The tracking UUID to read.
    Tracking Schema:
    {'$defs': {'DeploymentTracking': {'properties': {'trackingId': {'default': None, 'description': 'Tracking id. Must be valid UUID string.', 'title': 'Trackingid', 'type': 'string'}, 'status': {'default': None, 'description': "Tracking status. Must be one of the values: 'PENDING', 'RUNNING', 'FINISHED'.", 'title': 'Status', 'type': 'string'}, 'errors': {'anyOf': [{'items': {'type': 'string'}, 'type': 'array'}, {'type': 'null'}], 'default': None, 'description': 'List of errors.', 'title': 'Errors'}, 'warnings': {'anyOf': [{'items': {'type': 'string'}, 'type': 'array'}, {'type': 'null'}], 'default': None, 'description': 'List of warnings.', 'title': 'Warnings'}, 'data': {'anyOf': [{'$ref': '#/$defs/DeploymentTrackingData'}, {'type': 'null'}], 'default': None, 'description': 'Deployment Tracking data.'}}, 'title': 'DeploymentTracking', 'type': 'object'}, 'DeploymentTrackingData': {'properties': {'dataType': {'default': 'DEPLOYMENT', 'description': "Tracking data type. Constant value: 'DEPLOYMENT'.", 'title': 'Datatype', 'type': 'string'}, 'serviceMockId': {'default': None, 'description': 'Virtual service id.', 'title': 'Servicemockid', 'type': 'integer'}, 'stage': {'default': None, 'description': 'Current stage of the tracked job.', 'title': 'Stage', 'type': 'string'}, 'started': {'default': None, 'description': 'Unix timestamp of the stage start moment.', 'title': 'Started', 'type': 'integer'}}, 'title': 'DeploymentTrackingData', 'type': 'object'}, 'MasterTrackingData': {'properties': {'dataType': {'default': 'MASTER_TRACKING', 'description': "Tracking data type. Constant value: 'MASTER_TRACKING'.", 'title': 'Datatype', 'type': 'string'}, 'serviceMockTrackingDtos': {'anyOf': [{'items': {'$ref': '#/$defs/ServiceMockTrackingDto'}, 'type': 'array'}, {'type': 'null'}], 'default': None, 'description': 'List of subtrackings of the Virtual services related to the job.', 'title': 'Servicemocktrackingdtos'}}, 'title': 'MasterTrackingData', 'type': 'object'}, 'ServiceMockTrackingDto': {'properties': {'serviceMockId': {'default': None, 'description': 'Virtual service id.', 'title': 'Servicemockid', 'type': 'integer'}, 'serviceMockName': {'default': None, 'description': 'Virtual service name.', 'title': 'Servicemockname', 'type': 'string'}, 'started': {'default': None, 'description': 'Unix timestamp of the stage start moment.', 'title': 'Started', 'type': 'integer'}, 'trackingDto': {'anyOf': [{'$ref': '#/$defs/DeploymentTracking'}, {'type': 'null'}], 'default': None, 'description': 'Deployment Tracking object.'}}, 'title': 'ServiceMockTrackingDto', 'type': 'object'}}, 'properties': {'trackingId': {'default': None, 'description': 'Tracking id. Must be valid UUID string.', 'title': 'Trackingid', 'type': 'string'}, 'status': {'default': None, 'description': "Tracking status. Must be one of the values: 'PENDING', 'RUNNING', 'FINISHED'.", 'title': 'Status', 'type': 'string'}, 'errors': {'anyOf': [{'items': {'type': 'string'}, 'type': 'array'}, {'type': 'null'}], 'default': None, 'description': 'List of errors.', 'title': 'Errors'}, 'warnings': {'anyOf': [{'items': {'type': 'string'}, 'type': 'array'}, {'type': 'null'}], 'default': None, 'description': 'List of warnings.', 'title': 'Warnings'}, 'data': {'anyOf': [{'$ref': '#/$defs/MasterTrackingData'}, {'type': 'null'}], 'default': None, 'description': 'Deployment Tracking data.'}}, 'title': 'MasterTracking', 'type': 'object'}
ParametersJSON Schema
NameRequiredDescriptionDefault
argsYes
actionYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
infoNoInfo messages
errorNoError message
totalNoTotal available records
resultNoResult
warningNoWarning messages
has_moreNoMore records per page to list

TDQS

A5/5.0
Behavior5/5

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

With no annotations, the description carries full responsibility for disclosing behavior. It details what each action returns (status, result, errors, warnings), the possible tracking statuses ('PENDING', 'RUNNING', 'FINISHED'), and the structure of the tracking data. This transparency helps the agent predict outcomes without additional heuristics.

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

Conciseness5/5

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

The description is well-structured, starting with a clear one-line purpose, then breaking down actions and parameters, and finally providing the detailed tracking schema. While long, every part contributes value and is organized logically. The front-loaded summary makes it easy to grasp the tool's core purpose quickly.

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?

The description fully covers the tool's scope: two distinct actions, their use cases, required parameters, and the full response schema (including nested objects like DeploymentTracking and MasterTracking). This is complete enough for an agent to use the tool correctly without needing additional context from siblings or external documentation.

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 minimal (action and args), but the description fully compensates by defining both actions' required parameter 'tracking_id' as a mandatory UUID string. It also embeds the full tracking schema, giving meaning to the generic 'args' field. This is a complete parameter description beyond the structured schema.

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 immediately states the tool's function: 'Operations on tracking objects' and specifies 'read or poll tracking status by tracking ID (UUID).' It clearly distinguishes between the two sub-actions ('read' for virtual service operations, 'read_asset_tracking' for asset uploads), making it easy to select the correct action.

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?

The description provides explicit guidance: 'Call this whenever you have a tracking ID and need to know the status or result of an async operation.' It also warns against using 'read' for asset tracking, directing users to 'read_asset_tracking' instead. This goes beyond simple context and gives clear when-to-use instructions.

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

virtual_services_virtual_serviceA
    Operations on virtual services. 
    Use this when a user needs to create or select a virtual service.
    Actions:
    - read: Read a virtual service. Get the information of a virtual service.
        args(dict): Dictionary with the following required parameters:
            workspace_id (int): Mandatory. The id of the workspace to list virtual services from.
            id (int): Mandatory. The id of the virtual service to get information.
    - list: List all virtual services. 
        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 virtual services from. Without this it will list all virtual services in the workspace.
            limit (int, default=10, valid=[1 to 50]): The number of virtual services to list.
            offset (int, default=0): Number of virtual services to skip.
    - create: Create a new virtual service.
        args(VirtualService): A virtual service object with the following fields:
            workspace_id (int): Mandatory. The id of the workspace.
            name (str): Mandatory. The name of the virtual service.
            serviceId (int): Mandatory. The id of the service to create the virtual service in.
            harborId (str): Mandatory. The location harbor id. ALWAYS call virtual_services_location list first to get the correct harborId for the requested location.
            shipId (str): Mandatory. The location ship id. ALWAYS call virtual_services_location list first to get the correct shipId for the requested location.
            endpointPreference (str): Mandatory. Use 'HTTP' or 'HTTPS' as specified by the user.
            noMatchingRequestPreference (str): Mandatory. If not specified use 'return404'.
    - update: Update an existing new virtual service.
        args(VirtualService): A virtual service object with the following fields:
            workspace_id (int): Mandatory. The id of the workspace.
            vs_id (int): Mandatory. The id of the virtual service.
            name (str): Optional. The name of the virtual service.
            serviceId (int): Optional. The id of the service to create the virtual service in.
            harborId (str): Optional. The location harbor id. Use virtual_services_location list to find the correct value.
            shipId (str): Optional. The location ship id. Use virtual_services_location list to find the correct value.
            endpointPreference (str): Optional. 'HTTP' or 'HTTPS' as specified by the user.
            noMatchingRequestPreference (str): Optional. If not specified use 'return404'.
    - deploy: Deploy a virtual service. Deploys the virtual service to the specified harbor and ship.
        Action result contains tracking id to track the deployment. Use tracking tool to track the deployment.
        Deployment is finished, when tracking status is 'FINISHED'. If deployment fails, tracking status is 'FAILED'. 
        After tracking status is 'FINISHED' or 'FAILED' you can read the virtual service to get the endpoint and return to user.
        args(dict): Dictionary with the following required parameters:
            workspace_id (int): Mandatory. The id of the workspace the virtual service belongs to.
            id (int): Mandatory. The id of the virtual service to deploy.
    - stop: Stop a virtual service. Stops the virtual service.
        Action result contains tracking id to track the stop action. Use tracking tool to track the stop action.
        Stop action is finished, when tracking status is 'FINISHED'. If stop action fails, tracking status is 'FAILED'. 
        args(dict): Dictionary with the following required parameters:
            workspace_id (int): Mandatory. The id of the workspace the virtual service belongs to.
            id (int): Mandatory. The id of the virtual service to stop.
    - configure: Configures a virtual service. Only available if Virtual service is running.
        Updates transactions loaded into the virtual service.
        Action result contains tracking id to track the update action. Use tracking tool to track the update action.
        Update action is finished, when tracking status is 'FINISHED'. If update action fails, tracking status is 'FAILED'. 
        args(VirtualService): A virtual service object with the following fields:
            workspace_id (int): Mandatory. The id of the virtual service.
            id (int): Mandatory. The id of the virtual service to update.
    - assign_transactions: Assigns the transactions to the virtual service. Transactions should belong to the same service as the virtual service.
        args(dict): Dictionary with the following required parameters:
            workspace_id (int): Mandatory. The id of the workspace the virtual service belongs to.
            id (int): Mandatory. The id of the virtual service to assign the transaction to.
            transaction_ids (list[int]): Mandatory. The ids of the transactions to assign to the virtual service.
    - unassign_transactions: Unassigns the transactions from the virtual service.
        args(dict): Dictionary with the following required parameters:
            workspace_id (int): Mandatory. The id of the workspace the virtual service belongs to.
            id (int): Mandatory. The id of the virtual service to assign the transaction to.
            transaction_ids (list[int]): Mandatory. The ids of the transactions to unassign from the virtual service.
    - assign_configuration: Assigns the configuration to the virtual service. To unassign configuration, assign configuration with id None.
        args(dict): Dictionary with the following required parameters:
            workspace_id (int): Mandatory. The id of the workspace the virtual service belongs to.
            id (int): Mandatory. The id of the virtual service to assign the transaction to.
            configuration_id (list[int]): Mandatory. The id of the configuration to assign to the virtual service.
    - set_proxy: Sets proxy server configuration for the virtual service.
        args(dict): Dictionary with the following required parameters:
            workspace_id (int): Mandatory. The id of the workspace the virtual service belongs to.
            id (int): Mandatory. The id of the virtual service to set proxy.
            proxyUrl (str): Mandatory. Proxy server address.
            nonProxyHosts (str): Optional. Non-proxy hosts, | separated.
            username (str): Optional. Proxy server username.
            password (str): Optional. Proxy server password.
            certificate_id (int): Optional. The id of the proxy certificate asset if required.
    - unset_proxy: Removes proxy server configuration from the virtual service.
        args(dict): Dictionary with the following required parameters:
            workspace_id (int): Mandatory. The id of the workspace the virtual service belongs to.
            id (int): Mandatory. The id of the virtual service to remove proxy.     
    - apply_template: Applies virtual service template settings to the virtual service.
        Result contains tracking id to track the update action. Use tracking tool to track the update action.
        args(dict): Dictionary with the following required parameters:
            workspace_id (int): Mandatory. The id of the workspace the virtual service belongs to.
            id (int): Mandatory. The id of the virtual service to remove proxy.
            template_id (int): Mandatory. The id of the virtual service template.
    - assign_keystore: Assign Keystore asset to the Virtual Service.
        args(dict):
            id (int): Mandatory. The id of the Virtual Service.
            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_keystore_truststore: Assign Keystore asset to the Virtual Service. Asset will be used as both Keystore and Truststore.
            Use this action for 2way ssl setup.
        args(dict):
            id (int): Mandatory. The id of the Virtual Service.
            asset_id (int): Mandatory. The id of the certificate asset to assign.
            alias (str): Mandatory. The certificate alias to use.
            workspace_id (int): Mandatory. The id of the workspace.       
    VirtualService Schema (including full MockServiceTransaction):
    {'$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'}, 'BrokerConfiguration': {'additionalProperties': True, 'properties': {'hostname': {'anyOf': [{'type': 'string'}, {'type': 'integer'}, {'type': 'null'}], 'default': None, 'description': 'Broker hostname', 'title': 'Hostname'}, 'port': {'anyOf': [{'type': 'string'}, {'type': 'integer'}, {'type': 'null'}], 'default': None, 'description': "Broker port (string). Use 'host:port,host:port' for Kafka multi-broker lists.", 'title': 'Port'}, 'channel': {'anyOf': [{'type': 'string'}, {'type': 'integer'}, {'type': 'null'}], 'default': None, 'description': 'IBM MQ channel name, e.g. SYSTEM.DEF.SVRCONN', 'title': 'Channel'}, 'queueManager': {'anyOf': [{'type': 'string'}, {'type': 'integer'}, {'type': 'null'}], 'default': None, 'description': 'IBM MQ queue manager name', 'title': 'Queuemanager'}, 'username': {'anyOf': [{'type': 'string'}, {'type': 'integer'}, {'type': 'null'}], 'default': None, 'description': 'Broker username', 'title': 'Username'}, 'password': {'anyOf': [{'type': 'string'}, {'type': 'integer'}, {'type': 'null'}], 'default': None, 'description': 'Broker password', 'title': 'Password'}, 'sslAuthentication': {'anyOf': [{'type': 'boolean'}, {'type': 'null'}], 'default': None, 'description': 'Enable SSL/TLS authentication', 'title': 'Sslauthentication'}, 'sslCipherSuite': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'default': None, 'description': 'SSL cipher suite (IBM MQ only), e.g. TLS_RSA_WITH_AES_256_CBC_SHA256', 'title': 'Sslciphersuite'}, 'embeddedBroker': {'anyOf': [{'type': 'boolean'}, {'type': 'null'}], 'default': None, 'description': 'Start an embedded broker — ACTIVE_MQ_CLASSIC and ARTEMIS only', 'title': 'Embeddedbroker'}, 'autoOffsetReset': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'default': None, 'description': 'Kafka offset reset strategy: earliest, latest, or none', 'title': 'Autooffsetreset'}, 'numPartitions': {'anyOf': [{'type': 'integer'}, {'type': 'null'}], 'default': None, 'description': 'Kafka number of partitions (default 1)', 'title': 'Numpartitions'}, 'queues': {'anyOf': [{'items': {'$ref': '#/$defs/BrokerQueue'}, 'type': 'array'}, {'type': 'null'}], 'default': [], 'description': 'List of queues', 'title': 'Queues'}, 'topics': {'anyOf': [{'items': {'$ref': '#/$defs/BrokerTopic'}, 'type': 'array'}, {'type': 'null'}], 'default': [], 'description': 'List of topics', 'title': 'Topics'}, 'subscriptions': {'anyOf': [{'items': {'$ref': '#/$defs/BrokerSubscription'}, 'type': 'array'}, {'type': 'null'}], 'default': [], 'description': 'List of subscriptions', 'title': 'Subscriptions'}, 'flowConfigurations': {'anyOf': [{'items': {'$ref': '#/$defs/FlowConfiguration'}, 'type': 'array'}, {'type': 'null'}], 'default': [], 'description': 'Broker-level flow routing configurations', 'title': 'Flowconfigurations'}}, 'title': 'BrokerConfiguration', 'type': 'object'}, 'BrokerQueue': {'properties': {'name': {'description': 'Queue name', 'title': 'Name', 'type': 'string'}}, 'required': ['name'], 'title': 'BrokerQueue', 'type': 'object'}, 'BrokerSubscription': {'properties': {'name': {'description': 'Subscription name', 'title': 'Name', 'type': 'string'}}, 'required': ['name'], 'title': 'BrokerSubscription', 'type': 'object'}, 'BrokerTopic': {'properties': {'name': {'description': 'Topic name', 'title': 'Name', 'type': 'string'}, 'isDurable': {'anyOf': [{'type': 'boolean'}, {'type': 'null'}], 'default': None, 'description': 'Whether the subscription is durable', 'title': 'Isdurable'}, 'durableSubscriptionName': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'default': None, 'description': 'Durable subscription name — required when isDurable=True', 'title': 'Durablesubscriptionname'}}, 'required': ['name'], 'title': 'BrokerTopic', 'type': 'object'}, 'Endpoint': {'properties': {'endpoint': {'description': 'Endpoint URL', 'title': 'Endpoint', 'type': 'string'}}, 'required': ['endpoint'], 'title': 'Endpoint', 'type': 'object'}, 'FlowConfiguration': {'properties': {'name': {'description': 'Flow configuration name', 'title': 'Name', 'type': 'string'}, 'transactionMapping': {'$ref': '#/$defs/FlowTransactionMapping', 'description': 'Source-to-destination routing for this flow'}}, 'required': ['name', 'transactionMapping'], 'title': 'FlowConfiguration', 'type': 'object'}, 'FlowTransactionMapping': {'properties': {'sourceName': {'description': 'Source queue/topic/subscription name', 'title': 'Sourcename', 'type': 'string'}, 'sourceType': {'description': 'Source type: QUEUE, TOPIC, or SUBSCRIPTION', 'title': 'Sourcetype', 'type': 'string'}, 'destinations': {'default': [], 'description': 'Destination list', 'items': {'$ref': '#/$defs/MessagingDestination'}, 'title': 'Destinations', 'type': 'array'}}, 'required': ['sourceName', 'sourceType'], 'title': 'FlowTransactionMapping', 'type': 'object'}, 'MessagingDestination': {'properties': {'destinationName': {'description': 'Destination name', 'title': 'Destinationname', 'type': 'string'}, 'destinationType': {'description': 'Destination type: QUEUE, TOPIC, or SUBSCRIPTION', 'title': 'Destinationtype', 'type': 'string'}}, 'required': ['destinationName', 'destinationType'], 'title': 'MessagingDestination', 'type': 'object'}, 'MockServiceRecording': {'properties': {'recordingId': {'description': 'ID of the recording to include in this virtual service', 'title': 'Recordingid', 'type': 'integer'}, 'runtimeConfig': {'anyOf': [{'$ref': '#/$defs/ReplayConfig'}, {'type': 'null'}], 'default': None, 'description': 'Replay configuration for this recording'}}, 'required': ['recordingId'], 'title': 'MockServiceRecording', 'type': 'object'}, 'MockServiceTransaction': {'properties': {'txnId': {'description': 'Transaction id.', 'title': 'Txnid', 'type': 'integer'}, 'priority': {'default': 10, 'description': 'Transaction Priority. If not specified, defaults to 10.', 'title': 'Priority', 'type': 'integer'}, 'destinations': {'anyOf': [{'items': {'$ref': '#/$defs/MessagingDestination'}, 'type': 'array'}, {'type': 'null'}], 'default': [], 'description': 'List of messaging destinations.', 'title': 'Destinations'}}, 'required': ['txnId'], 'title': 'MockServiceTransaction', 'type': 'object'}, 'ProxyConfiguration': {'additionalProperties': True, 'properties': {'proxyUrl': {'description': 'Proxy url', 'title': 'Proxyurl', 'type': 'string'}, 'nonProxyHosts': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'default': None, 'description': 'Non proxy hosts, | separated', 'title': 'Nonproxyhosts'}, 'username': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'description': 'Proxy username', 'title': 'Username'}, 'password': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'description': 'Proxy password', 'title': 'Password'}, 'certificateId': {'anyOf': [{'type': 'integer'}, {'type': 'null'}], 'default': None, 'description': 'Certificate asset identifier', 'title': 'Certificateid'}}, 'required': ['proxyUrl', 'username', 'password'], 'title': 'ProxyConfiguration', 'type': 'object'}, 'RecorderConfig': {'additionalProperties': True, 'properties': {'maxMessagesCount': {'anyOf': [{'type': 'integer'}, {'type': 'null'}], 'default': None, 'description': 'Maximum number of messages to capture per recording session', 'title': 'Maxmessagescount'}, 'maxMessagesPerSecondCount': {'anyOf': [{'type': 'integer'}, {'type': 'null'}], 'default': None, 'description': 'Rate limit for capturing messages per second', 'title': 'Maxmessagespersecondcount'}, 'mappings': {'anyOf': [{'items': {'$ref': '#/$defs/RecorderMapping'}, 'type': 'array'}, {'type': 'null'}], 'default': [], 'description': 'Inbound/outbound destination mappings for recording', 'title': 'Mappings'}}, 'title': 'RecorderConfig', 'type': 'object'}, 'RecorderMapping': {'properties': {'inboundDestination': {'description': 'Source destination to record from', 'title': 'Inbounddestination', 'type': 'string'}, 'outboundDestination': {'description': 'Destination to replay captured messages to', 'title': 'Outbounddestination', 'type': 'string'}, 'originType': {'description': 'Origin type: QUEUE, TOPIC, or SUBSCRIPTION', 'title': 'Origintype', 'type': 'string'}}, 'required': ['inboundDestination', 'outboundDestination', 'originType'], 'title': 'RecorderMapping', 'type': 'object'}, 'ReplayConfig': {'additionalProperties': True, 'properties': {'replayCount': {'anyOf': [{'type': 'integer'}, {'type': 'null'}], 'default': 1, 'description': 'Number of times to replay the recording', 'title': 'Replaycount'}, 'delayBetweenReplays': {'anyOf': [{'type': 'integer'}, {'type': 'null'}], 'default': 0, 'description': 'Delay in ms between replays', 'title': 'Delaybetweenreplays'}, 'initialDelay': {'anyOf': [{'type': 'integer'}, {'type': 'null'}], 'default': 0, 'description': 'Initial delay in ms before the first replay', 'title': 'Initialdelay'}}, 'title': 'ReplayConfig', 'type': 'object'}, 'ResponseDelay': {'additionalProperties': True, 'properties': {'type': {'default': 'FIXED', 'description': 'Delay type: FIXED, LOGNORMAL, or UNIFORM', 'title': 'Type', 'type': 'string'}, 'fixedDelay': {'anyOf': [{'type': 'integer'}, {'type': 'null'}], 'default': None, 'description': 'Fixed delay in ms (FIXED type)', 'title': 'Fixeddelay'}, 'median': {'anyOf': [{'type': 'number'}, {'type': 'null'}], 'default': None, 'description': 'Median for LOGNORMAL distribution', 'title': 'Median'}, 'sigma': {'anyOf': [{'type': 'number'}, {'type': 'null'}], 'default': None, 'description': 'Sigma for LOGNORMAL distribution', 'title': 'Sigma'}, 'lower': {'anyOf': [{'type': 'number'}, {'type': 'null'}], 'default': None, 'description': 'Lower bound for UNIFORM distribution', 'title': 'Lower'}, 'upper': {'anyOf': [{'type': 'number'}, {'type': 'null'}], 'default': None, 'description': 'Upper bound for UNIFORM distribution', 'title': 'Upper'}}, 'title': 'ResponseDelay', 'type': 'object'}}, 'properties': {'id': {'description': 'The unique identifier of the virtual service', 'title': 'Id', 'type': 'integer'}, 'name': {'description': 'The name of the virtual service', 'title': 'Name', 'type': 'string'}, 'status': {'default': '', 'description': 'The status of the virtual service', 'title': 'Status', 'type': 'string'}, 'serviceId': {'description': 'The unique identifier of the service where the virtual service belongs', 'title': 'Serviceid', 'type': 'integer'}, 'type': {'description': "Type of the virtual service. Possible values are 'TRANSACTIONAL' and 'MESSAGING'. Transactional virtual services are used for simulating user interactions with web applications, while messaging virtual services are used for simulating message-based interactions.", 'title': 'Type', 'type': 'string'}, 'harborId': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'default': None, 'description': 'Location harbor identifier', 'title': 'Harborid'}, 'shipId': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'default': None, 'description': 'Location ship identifier', 'title': 'Shipid'}, 'configurationId': {'anyOf': [{'type': 'integer'}, {'type': 'null'}], 'default': None, 'description': 'Configuration identifier', 'title': 'Configurationid'}, 'noMatchingRequestPreference': {'description': "For transactional virtual services, defines the behavior when no matching request is found. Possible values are 'return404' and 'bypasslive'.", 'title': 'Nomatchingrequestpreference', 'type': 'string'}, 'endpointPreference': {'description': "For transactional virtual services, defines endpoint schema. Possible values are 'HTTP' and 'HTTPS'.", 'title': 'Endpointpreference', 'type': 'string'}, 'replicas': {'default': 1, 'description': 'The number of replicas for the virtual service. Always set to 1.', 'title': 'Replicas', 'type': 'integer'}, 'mockServiceTransactions': {'anyOf': [{'items': {'$ref': '#/$defs/MockServiceTransaction'}, 'type': 'array'}, {'type': 'null'}], 'default': [], 'description': 'List of transaction definitions associated with the virtual service', 'title': 'Mockservicetransactions'}, 'mockServiceRecordings': {'anyOf': [{'items': {'$ref': '#/$defs/MockServiceRecording'}, 'type': 'array'}, {'type': 'null'}], 'default': [], 'description': 'List of recording references associated with the virtual service', 'title': 'Mockservicerecordings'}, 'endpoints': {'anyOf': [{'items': {'$ref': '#/$defs/Endpoint'}, 'type': 'array'}, {'type': 'null'}], 'default': [], 'description': 'List of virtual service endpoints. Available after deployment only.', 'title': 'Endpoints'}, 'httpRunnerEnabled': {'default': True, 'description': "Http runner enabled flag, must be enabled for virtual services with 'TRANSACTIONAL' type.", 'title': 'Httprunnerenabled', 'type': 'boolean'}, 'messagingRunnerEnabled': {'anyOf': [{'type': 'boolean'}, {'type': 'null'}], 'default': None, 'description': "Messaging runner enabled flag for 'MESSAGING' type virtual services.", 'title': 'Messagingrunnerenabled'}, 'messagingProtocol': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'default': None, 'description': 'Messaging broker protocol. One of: IBM_MQ9_JMS, IBM_MQ9_NATIVE, ACTIVE_MQ_CLASSIC, ACTIVE_MQ_ARTEMIS, KAFKA.', 'title': 'Messagingprotocol'}, 'priorityMode': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'default': None, 'description': 'Transaction selection mode: DEFAULT or UNIQUE_PRIORITY.', 'title': 'Prioritymode'}, 'responseDelay': {'anyOf': [{'$ref': '#/$defs/ResponseDelay'}, {'type': 'null'}], 'default': None, 'description': 'Global response delay applied to all transactions in this virtual service.'}, 'recorderConfig': {'anyOf': [{'$ref': '#/$defs/RecorderConfig'}, {'type': 'null'}], 'default': None, 'description': 'Configuration for recording live broker traffic.'}, 'classPathJars': {'anyOf': [{'additionalProperties': True, 'type': 'object'}, {'type': 'null'}], 'default': None, 'description': 'Custom broker JAR paths, e.g. {"paths": ["string"]}.', 'title': 'Classpathjars'}, 'proxy': {'anyOf': [{'$ref': '#/$defs/ProxyConfiguration'}, {'type': 'null'}], 'default': None, 'description': 'Proxy configuration for the virtual service'}, 'brokerConfig': {'anyOf': [{'$ref': '#/$defs/BrokerConfiguration'}, {'type': 'null'}], 'default': None, 'description': 'Messaging broker connection configuration'}, 'assets': {'anyOf': [{'items': {'$ref': '#/$defs/AssignedAsset'}, 'type': 'array'}, {'type': 'null'}], 'default': None, 'description': 'List of assets', 'title': 'Assets'}}, 'required': ['id', 'name', 'serviceId', 'type', 'noMatchingRequestPreference', 'endpointPreference'], 'title': 'VirtualService', 'type': 'object'}
    Virtual service deploy/stop/update/delete actions result schema:
    {'properties': {'tracking_id': {'description': 'Action tracking id', 'title': 'Tracking Id', 'type': 'string'}}, 'required': ['tracking_id'], 'title': 'ActionResult', 'type': 'object'}
ParametersJSON Schema
NameRequiredDescriptionDefault
argsYes
actionYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
infoNoInfo messages
errorNoError message
totalNoTotal available records
resultNoResult
warningNoWarning messages
has_moreNoMore records per page to list

TDQS

A4.2/5.0
Behavior4/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 well: it discloses that deploy/stop/configure/apply_template return tracking_ids requiring polling, states that configure only works on running virtual services, and explains the 'id None' trick for unassigning configuration. Minor copy-paste errors (e.g., 'assign' in unassign_transactions) slightly reduce clarity but do not undermine overall transparency.

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?

The description is well-structured with clear action headers and per-action argument lists, but it is extremely long due to including the entire nested VirtualService schema and all its $defs. While this content is valuable, it could be trimmed or presented as a reference rather than inline text, making it less concise than ideal.

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?

Despite the length, the description is remarkably complete: it covers all 14 actions, their arguments, prerequisites, async tracking behavior, result schema, and the full VirtualService object schema. It even includes notes about deployment status checks and when to read the endpoint back. Minor text errors do not meaningfully reduce completeness for an agent using the tool.

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 description coverage is 0%, so the description must compensate, and it does extensively. Each action lists required/optional parameters with types, defaults, valid ranges (e.g., limit 1-50), and the embedded VirtualService schema provides detailed descriptions for every field. This gives the agent everything needed to construct arguments correctly.

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 description clearly states 'Operations on virtual services' and enumerates all supported actions (read, list, create, update, deploy, etc.), giving a specific verb+resource picture. It does not explicitly differentiate from sibling tools like virtual_services_messaging_virtual_service, but the scope is evident from the action list and the opening 'Use this when a user needs to create or select a virtual service.'

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?

The description provides explicit usage context ('Use this when a user needs to create or select a virtual service') and important prerequisites (e.g., 'ALWAYS call virtual_services_location list first' for harbor/ship IDs). It does not mention when NOT to use this tool or name alternative tools for specific cases, so it stops short of a 5.

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

virtual_services_virtual_service_templateA
    Operations on virtual service templates.
    Virtual service templates can only be used for the HTTP virtual services.
    Actions:
    - read: Get a SPECIFIC virtual service template by its id. Use this when you already have a template id.
        Do NOT use `list` when you have a specific id — use `read` instead.
        args(dict): Dictionary with the following required parameters:
            workspace_id (int): Mandatory. The id of the workspace.
            id (int): Mandatory. The id of the virtual service template to read.
    - list: List virtual service templates in a workspace. Use this to browse or discover templates.
        Do NOT use `list` when you need a specific template by id — use `read` instead.
        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 virtual service templates from.
            Without this it will list all virtual service templates in the workspace.
            limit (int, default=10, valid=[1 to 50]): The number of virtual service templates to list.
            offset (int, default=0): Number of virtual service templates to skip.
    - create: Create a new virtual service template.
        args(VirtualService): A virtual service template object with the following fields:
            workspace_id (int): Mandatory. The id of the workspace.
            name (str): Mandatory. The name of the virtual service template.
            serviceId (int): Mandatory. The id of the service to create the virtual service template in.
            noMatchingRequestPreference (str): Mandatory. If not specified use 'return404'.
    - update: Update an existing new virtual service template.
        args(VirtualService): A virtual service template object with the following fields:
            workspace_id (int): Mandatory. The id of the workspace.
            template_id (int): Mandatory. The id of the virtual service template.
            name (str): Optional. The name of the virtual service template.
            serviceId (int): Optional. The id of the service to create the virtual service template in.
            noMatchingRequestPreference (str): Optional. If not specified use 'return404'.
    - assign_transactions: Assigns the transactions to the virtual service template. 
            Transactions should belong to the same service as the virtual service template.
        args(dict): Dictionary with the following required parameters:
            workspace_id (int): Mandatory. The id of the workspace the virtual service template belongs to.
            id (int): Mandatory. The id of the virtual service template to assign the transaction to.
            transaction_ids (list[int]): Mandatory. The ids of the transactions to assign to the virtual service template.
    - unassign_transactions: Unassigns the transactions from the virtual service template.
        args(dict): Dictionary with the following required parameters:
            workspace_id (int): Mandatory. The id of the workspace the virtual service template belongs to.
            id (int): Mandatory. The id of the virtual service template to assign the transaction to.
            transaction_ids (list[int]): Mandatory. The ids of the transactions to unassign from the virtual service template.
    - assign_configuration: Assigns the configuration to the virtual service template. To unassign configuration, assign configuration with id None.
        args(dict): Dictionary with the following required parameters:
            workspace_id (int): Mandatory. The id of the workspace the virtual service template belongs to.
            id (int): Mandatory. The id of the virtual service template to assign the transaction to.
            configuration_id (list[int]): Mandatory. The id of the configuration to assign to the virtual service template.
    - assign_keystore: Assign Keystore asset to the Virtual Service Template.
        args(dict):
            id (int): Mandatory. The id of the Virtual Service Template.
            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_keystore_truststore: Assign Keystore asset to the Virtual Service Template. Asset will be used as both Keystore and Truststore.
            Use this action for 2way ssl setup.
        args(dict):
            id (int): Mandatory. The id of the Virtual Service Template.
            asset_id (int): Mandatory. The id of the certificate asset to assign.
            alias (str): Mandatory. The certificate alias to use.
            workspace_id (int): Mandatory. The id of the workspace.
    VirtualServiceTemplate Schema (including full MockServiceTransaction):
    {'$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'}, 'MessagingDestination': {'properties': {'destinationName': {'description': 'Destination name', 'title': 'Destinationname', 'type': 'string'}, 'destinationType': {'description': 'Destination type: QUEUE, TOPIC, or SUBSCRIPTION', 'title': 'Destinationtype', 'type': 'string'}}, 'required': ['destinationName', 'destinationType'], 'title': 'MessagingDestination', 'type': 'object'}, 'MockServiceTransaction': {'properties': {'txnId': {'description': 'Transaction id.', 'title': 'Txnid', 'type': 'integer'}, 'priority': {'default': 10, 'description': 'Transaction Priority. If not specified, defaults to 10.', 'title': 'Priority', 'type': 'integer'}, 'destinations': {'anyOf': [{'items': {'$ref': '#/$defs/MessagingDestination'}, 'type': 'array'}, {'type': 'null'}], 'default': [], 'description': 'List of messaging destinations.', 'title': 'Destinations'}}, 'required': ['txnId'], 'title': 'MockServiceTransaction', 'type': 'object'}}, 'properties': {'id': {'description': 'The unique identifier of the virtual service template', 'title': 'Id', 'type': 'integer'}, 'name': {'description': 'The name of the virtual service template', 'title': 'Name', 'type': 'string'}, 'serviceId': {'description': 'The unique identifier of the service where the virtual service template belongs', 'title': 'Serviceid', 'type': 'integer'}, 'configurationId': {'anyOf': [{'type': 'integer'}, {'type': 'null'}], 'default': None, 'description': 'Configuration identifier', 'title': 'Configurationid'}, 'noMatchingRequestPreference': {'description': "Defines the behavior when no matching request is found. Possible values are 'return404' and 'bypasslive'.", 'title': 'Nomatchingrequestpreference', 'type': 'string'}, 'replicas': {'default': 1, 'description': 'The number of replicas for the virtual service template. Always set to 1 for all virtual service templates.', 'title': 'Replicas', 'type': 'integer'}, 'mockServiceTransactions': {'anyOf': [{'items': {'$ref': '#/$defs/MockServiceTransaction'}, 'type': 'array'}, {'type': 'null'}], 'default': [], 'description': 'List of transaction definitions associated with the virtual service template', 'title': 'Mockservicetransactions'}, 'httpRunnerEnabled': {'default': True, 'description': 'Http runner enabled flag, must be enabled for virtual service template', 'title': 'Httprunnerenabled', 'type': 'boolean'}, 'assets': {'anyOf': [{'items': {'$ref': '#/$defs/AssignedAsset'}, 'type': 'array'}, {'type': 'null'}], 'default': None, 'description': 'List of assets', 'title': 'Assets'}}, 'required': ['id', 'name', 'serviceId', 'noMatchingRequestPreference'], 'title': 'VirtualServiceTemplate', 'type': 'object'}
ParametersJSON Schema
NameRequiredDescriptionDefault
argsYes
actionYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
infoNoInfo messages
errorNoError message
totalNoTotal available records
resultNoResult
warningNoWarning messages
has_moreNoMore records per page to list

TDQS

A4.5/5.0
Behavior3/5

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

With no annotations provided, the description bears full responsibility for behavioral disclosure. It does reveal some constraints (HTTP-only usage, transactions must belong to the same service, assigning configuration with id None unassigns) but does not discuss side effects, reversibility, permissions, or failure modes for mutation actions. The action names imply effects, but a more explicit behavioral profile is missing.

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: an overview, per-action subsections, and an appendix with the schema. It is quite verbose, with repeated phrasing like 'Mandatory. The id of...' and a large embedded schema, but this is largely justified by the tool's complexity (8 actions and nested objects). It remains front-loaded and readable.

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?

Despite the high complexity, the description covers all actions, their inputs, constraints, and important nuances (HTTP-only, transaction assignment constraints, noMatchingRequestPreference defaults, keystore for 2-way SSL). An output schema is present, so return value details are unnecessary. This is a thoroughly complete description for AI agent use.

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), providing 0% schema coverage. The description compensates fully by listing every action's parameters with types, mandatory/optional indicators, defaults (e.g., limit default=10, valid 1-50; noMatchingRequestPreference default='return404'), and valid ranges. It even embeds the full VirtualServiceTemplate schema with field descriptions, making parameter semantics exceptionally clear.

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 identifies the resource (virtual service templates) and specifies distinct action verbs: read, list, create, update, assign_transactions, etc. It also adds a distinguishing constraint ('Virtual service templates can only be used for the HTTP virtual services') and explicitly differentiates read from list usage, making the tool's purpose unambiguous.

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?

The description provides explicit when-to-use guidance: 'Use this when you already have a template id' for read, and 'Use this to browse or discover templates' for list. It also gives a direct exclusion: 'Do NOT use `list` when you need a specific template by id — use `read` instead.' Additionally, it specifies 'Use this action for 2way ssl setup' for assign_keystore_truststore. This meets the standard of explicit when/when-not guidance.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 17 tool updatesv1.0.10
    • First observedblazemeter_account
    • First observedblazemeter_user
    • First observedblazemeter_workspaces
    • First observedvirtual_services_action
    • First observedvirtual_services_asset
    • First observedvirtual_services_configuration
    • First observedvirtual_services_http_transaction
    • First observedvirtual_services_location
    • First observedvirtual_services_messaging_transaction
    • First observedvirtual_services_messaging_virtual_service
    • First observedvirtual_services_recording
    • First observedvirtual_services_sandbox
    • First observedvirtual_services_service
    • First observedvirtual_services_test_data
    • First observedvirtual_services_tracking
    • First observedvirtual_services_virtual_service
    • First observedvirtual_services_virtual_service_template

TDQS

A3.6/5.0

Scored across 17 tools

Disambiguation2/5

Multiple tools have overlapping boundaries, particularly virtual_services_virtual_service and virtual_services_messaging_virtual_service, which share nearly identical action sets (deploy, stop, configure, assign_transactions, set_proxy, etc.) and the generic VS schema includes messaging fields. Additionally, blazemeter_account and blazemeter_user both deal with account/user information, creating potential confusion for an agent.

Naming Consistency4/5

Most tools follow a consistent '{domain}_{resource}' pattern with verb-based actions in snake_case (e.g., virtual_services_http_transaction.create, blazemeter_workspaces.list). Minor deviations include action names 'create-mq9' and 'update-mq9' using hyphens instead of underscores, and inconsistency in singular/plural resource names (blazemeter_account vs blazemeter_workspaces). Overall the pattern is predictable.

Tool Count4/5

With 17 tools covering both BlazeMeter platform entities (accounts, workspaces, user) and the service virtualization domain (services, transactions, virtual services, templates, configurations, assets, test data, recordings, sandbox, tracking, locations), the count is on the heavier side but appropriate for the broad scope. Each tool has a distinct resource focus, though some could be consolidated.

Completeness2/5

Significant gaps in lifecycle coverage: most entities (transactions, virtual services, templates, configurations, assets, recordings) lack delete operations, and actions can only be read/listed/created with no update/delete. Messaging virtual services also lack keystore/truststore assignment that the generic virtual service has. These gaps will cause agent failures when attempting full lifecycle management.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • F
    license
    Not graded
    quality
    C
    maintenance
    Integrates Apache JMeter with AI assistants to run and manage load tests through natural language. It enables users to execute test plans, parse results, inspect test structures, and compare performance metrics across different runs.
    -
  • A
    license
    A
    quality
    D
    maintenance
    Exposes Specmatic's API contract testing, resiliency testing, and mocking capabilities to AI coding agents via natural language, enabling automated validation and simulation of API behaviors.
    3
    11 npm
    12
    MIT