BlazeMeter Service Virtualization MCP Server
OfficialProvides tools for managing BlazeMeter Service Virtualization, including service, transaction, action, asset, sandbox, configuration, virtual service, messaging virtual service, recording, virtual service template, and test data management.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@BlazeMeter Service Virtualization MCP ServerCreate a virtual service from the template 'REST API' and deploy it."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
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.
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 |
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 --mcpOverride the destination — CLI argument (binary / uvx):
sv-mcp --mcp --otel-endpoint http://localhost:4317The 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 athttp://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-telemetryEach 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 |
|
Standalone binary | ✅ Yes |
|
uvx | ✅ Yes |
|
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-mcpuvx:
uvx --from "git+https://github.com/Blazemeter/sv-mcp.git" sv-mcp \
--otel-endpoint http://your-collector:4317The server never crashes if the endpoint is unreachable or the SDK is not installed.
MCP Client Configuration using uvx (Recommended)
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.4Branch:
git+https://github.com/Blazemeter/sv-mcp.git@main
MCP Client Configuration for Local testing using VS Code or Claude Desktop
Run main.py with --mcp flag
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"
]
}
}
}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
In order to obtain theAPI_KEY_ID andAPI_KEY_SECRET refere to BlazeMeter API keys
Available Tools
17 toolsblazemeter_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.
| Name | Required | Description | Default |
|---|---|---|---|
| args | Yes | ||
| action | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| info | No | Info messages |
| error | No | Error message |
| total | No | Total available records |
| result | No | Result |
| warning | No | Warning messages |
| has_more | No | More records per page to list |
TDQS
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| args | Yes | Dictionary with parameters | |
| action | Yes | The action id to execute |
Output Schema
| Name | Required | Description |
|---|---|---|
| info | No | Info messages |
| error | No | Error message |
| total | No | Total available records |
| result | No | Result |
| warning | No | Warning messages |
| has_more | No | More records per page to list |
TDQS
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| args | Yes | Dictionary with parameters | |
| action | Yes | The action id to execute |
Output Schema
| Name | Required | Description |
|---|---|---|
| info | No | Info messages |
| error | No | Error message |
| total | No | Total available records |
| result | No | Result |
| warning | No | Warning messages |
| has_more | No | More records per page to list |
TDQS
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.
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.
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.
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.
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.
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'}| Name | Required | Description | Default |
|---|---|---|---|
| args | Yes | ||
| action | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| info | No | Info messages |
| error | No | Error message |
| total | No | Total available records |
| result | No | Result |
| warning | No | Warning messages |
| has_more | No | More records per page to list |
TDQS
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.
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.
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.
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.
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.
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'}| Name | Required | Description | Default |
|---|---|---|---|
| args | Yes | ||
| action | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| info | No | Info messages |
| error | No | Error message |
| total | No | Total available records |
| result | No | Result |
| warning | No | Warning messages |
| has_more | No | More records per page to list |
TDQS
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.
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.
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.
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.
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.
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'}| Name | Required | Description | Default |
|---|---|---|---|
| args | Yes | ||
| action | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| info | No | Info messages |
| error | No | Error message |
| total | No | Total available records |
| result | No | Result |
| warning | No | Warning messages |
| has_more | No | More records per page to list |
TDQS
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.
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.
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.
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.
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.
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.
- A helper's output is inserted as raw text, so inside JSON wrap string values in quotes,
e.g. {"id": "{{jsonPath request.body '$.id'}}"} - without the quotes the response is invalid JSON.
- 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.
${fieldName} is not a wildcard and does not capture request values: without a dataset it is
matched as literal text. To accept any value for a field use a path matcher with matching(.+),
e.g. [[$.id, matching(.+)]]; to put a request value into the response use 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: "equals_json" (embed as value e.g. {"id": "${id}"}) and "equals_xml" are the
ONLY body matchers that get an auto-populated sampleBody (backend mirrors matchingValue into it).
"matches_json" with equalTo() e.g. [[$.field, equalTo(${id})]] does NOT get a sampleBody.
If a request payload is referenced anywhere in the prompt, default to "equals_json"/"equals_xml"
for that body matcher unless there is a specific reason to use a JSONPath-style matcher —
sample bodies on transactions are important to preserve.
* Body XML: matcherName "equals_xml" or "matches_xml" with matching() helper
* Path matchers ("matches_json" JSONPath, "matches_xml" XPath): the value must be exactly ONE pair
[[<path>, fn(arg)]], where fn is equalTo(value) (exact string match) or matching(regex).
No other function is accepted (not contains, containsString, matches, ...).
Write the argument WITHOUT quotes: quotes are not stripped and would be matched literally.
Example: [[$.messages[0].content, matching(You are a friendly AI assistant.*)]]
For "anything after X" use matching(X.*).
To check several paths, create one matcher per path: extra pairs inside a single matcher
are NOT evaluated.
* matchingValue for body matchers is supplied as plain text; the tool base64-encodes it
automatically on create/update and decodes it back on read/list — never pre-encode it yourself.
* sampleBody (on a body matcher) is optional and settable directly as plain text if you want a
display value different from matchingValue; it is likewise base64-encoded/decoded by the tool.
* 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.
Same sampleBody placement and plain-text/no-pre-encoding rules as `create` apply here — see `create`.
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),
body (str, optional): the request body as plain text - the tool base64-encodes it;
never pre-encode it.
sampleBody (str): Optional. Fallback only — prefer setting sampleBody on the body matcher itself.
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.
IMPORTANT — sampleBody placement: put it INSIDE the body matcher object, not as a
top-level sibling of name/dsl/workspace_id.
Correct shape:
dsl.requestDsl.body = [
{"key": "body", "matcherName": "equals_json",
"matchingValue": "{\"foo\": \"bar\"}",
"sampleBody": "{\"foo\": \"bar\"}"}
]
matchingValue and sampleBody are ALWAYS supplied as plain text. Do NOT base64-encode
them yourself before calling this tool (e.g. do not run a manual base64 command on the
payload first) — this tool base64-encodes them on create/update and decodes them back
on read/list automatically. Pre-encoding yourself causes a double-encoded value.
A top-level `sampleBody` arg is also accepted as a defensive fallback: it is applied to
any body matcher missing its own sampleBody, and if there is no body matcher at all to
attach it to, the response comes back with a warning saying so. The per-matcher
placement above is still the correct, primary way; do not rely on the fallback.
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.
sampleBody (str): Optional. Fallback only — prefer setting sampleBody on the body matcher itself.
- 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.
Same sampleBody placement and plain-text/no-pre-encoding rules as `create` apply here.
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.
sampleBody (str): Optional. Fallback only — prefer setting sampleBody on the body matcher itself.
- 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'}, 'sampleBody': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'default': None, 'description': "Human-readable request body shown for display purposes on a body matcher. The backend auto-populates this from matchingValue for 'equals_json'/'equals_xml' body matchers. It can also be set explicitly on other body matchers, e.g. 'matches_json' (verified against the live backend).", 'title': 'Samplebody'}}, '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': 'Body of the response. Plain text is accepted and base64-encoded by the tool; values that are already base64 (e.g. convert_template output) are kept as-is.', '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'}}, 'additionalProperties': True, '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'}| Name | Required | Description | Default |
|---|---|---|---|
| args | Yes | ||
| action | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| info | No | Info messages |
| error | No | Error message |
| total | No | Total available records |
| result | No | Result |
| warning | No | Warning messages |
| has_more | No | More records per page to list |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does so extensively: it discloses failure semantics for create_and_test (all-fail vs partial-fail, transaction still exists), base64 encode/decode behavior, sampleBody auto-population, matcher constraints, and how undefined dataset variables behave. This is far more than the schema or annotations would provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The content is relevant, but it is a very large wall of text with repeated sampleBody and base64 warnings across create, update, and create_and_test. The action list is buried after a long set of general DSL rules, so it is complete but not front-loaded and contains redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex multi-action tool with a generic input schema and an output schema, the description supplies the action surface, argument semantics, DSL rules, validation workflow, and failure behavior needed to call it correctly. Return-value detail is additionally present for create_and_test, even though the output schema could carry some of that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 0% and the generic action/args schema gives almost no semantics, so the description must compensate and does: it lists every action, documents each action's args, and specifies required/optional fields, defaults, constraints, and important formats. It also defines DSL field behavior that the raw schema does not convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific resource and verb: 'Operations on HTTP transactions' and 'Use this when a user needs to create or select a HTTP transaction.' The enumerated actions and the HTTP-specific naming distinguish it from the messaging-transaction sibling, though it never explicitly says 'not for messaging transactions.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear when-to-use context ('create or select a HTTP transaction') and strong internal alternatives, especially create_and_test instead of create when the DSL contains Handlebars templates, plus validate_template/convert_template before use. It lacks an explicit when-not-to-use statement against sibling tools, but the action-level guidance is unusually specific.
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'}| Name | Required | Description | Default |
|---|---|---|---|
| args | Yes | ||
| action | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| info | No | Info messages |
| error | No | Error message |
| total | No | Total available records |
| result | No | Result |
| warning | No | Warning messages |
| has_more | No | More records per page to list |
TDQS
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.
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.
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.
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.
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.
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.
Body matcher matchingValue/sampleBody (dsl.requestDsl.body[].matchingValue /
dsl.requestDsl.body[].sampleBody) are supplied as plain text; the tool base64-encodes
them automatically on create/update and decodes them back on read/list — never
pre-encode them yourself.
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.
Same body matcher matchingValue/sampleBody plain-text/no-pre-encoding rules as
`create` apply here.
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'}, 'sampleBody': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'default': None, 'description': "Human-readable request body shown for display purposes on a body matcher. The backend auto-populates this from matchingValue for 'equals_json'/'equals_xml' body matchers. It can also be set explicitly on other body matchers, e.g. 'matches_json' (verified against the live backend).", 'title': 'Samplebody'}}, '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'}| Name | Required | Description | Default |
|---|---|---|---|
| args | Yes | ||
| action | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| info | No | Info messages |
| error | No | Error message |
| total | No | Total available records |
| result | No | Result |
| warning | No | Warning messages |
| has_more | No | More records per page to list |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does disclose useful non-obvious behavior: matchingValue/sampleBody are auto-base64-encoded on create/update and decoded on read/list, and templates should be validated/converted before use. However, it does not describe permissions/auth requirements, side effects of destructive actions like update or assign_keystore/assign_certificate, or what happens to unspecified fields on update.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely long and dominated by a generic Handlebars template manual (helper syntax, dozens of examples, error-handling notes) that is largely irrelevant to selecting or invoking the tool. The actual action list and argument semantics are buried far below the template reference, so the content is neither front-loaded nor appropriately sized for tool selection.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex multi-action tool with an output schema, the description covers all actions, their arguments, and the full transaction DSL schema. It is mostly complete for calling the tool correctly, though it omits some operational context such as auth, side effects, and update semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the input schema has 0% description coverage and only generic action/args parameters, the description heavily compensates by listing each action's arguments with types, optionality, defaults, and constraints, plus a full Transaction/MessagingDsl schema. This gives the agent everything needed to construct correct calls for each action.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens by naming the resource ('JMS Messaging transactions') and later enumerates the supported actions (read, list, create, update, validate_template, convert_template, assign_keystore, assign_certificate), which makes the tool's role concrete. It implicitly distinguishes itself from virtual_services_http_transaction by specifying JMS/Messaging, but does not explicitly call out that sibling or state when to use this versus it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a clear triggering condition ('Use this when a user needs to create or select a JMS messaging transaction') and provides workflow guidance for create/update ('validate it and convert it first using validate_template and convert_template actions'). It does not name alternative tools or state when not to use this tool, which keeps it below 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_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'}| Name | Required | Description | Default |
|---|---|---|---|
| args | Yes | ||
| action | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| info | No | Info messages |
| error | No | Error message |
| total | No | Total available records |
| result | No | Result |
| warning | No | Warning messages |
| has_more | No | More records per page to list |
TDQS
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.
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.
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.
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.
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.
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'}| Name | Required | Description | Default |
|---|---|---|---|
| args | Yes | ||
| action | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| info | No | Info messages |
| error | No | Error message |
| total | No | Total available records |
| result | No | Result |
| warning | No | Warning messages |
| has_more | No | More records per page to list |
TDQS
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.
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.
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.
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.
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.
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'}, 'body': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'default': None, 'description': "Plain-text request body to send in the sandbox test. Do not base64-encode it yourself - the tool encodes it automatically before sending it to the backend, which expects a field named 'body' (not 'content') containing base64.", 'title': 'Body'}}, 'required': ['method', 'path', 'name'], 'title': 'SandboxRequest', 'type': 'object'}
Sandbox test_request response schema:
{'$defs': {'HttpHeader': {'additionalProperties': True, 'properties': {'name': {'description': 'HTTP header name', 'title': 'Name', 'type': 'string'}, 'value': {'description': 'HTTP header value', 'title': 'Value', 'type': 'string'}}, 'required': ['name', 'value'], 'title': 'HttpHeader', 'type': 'object'}, 'MatchingLogEntry': {'additionalProperties': True, 'properties': {'t': {'default': None, 'description': 'Timestamp of when the message was logged (in milliseconds since epoch)', 'title': 'T', 'type': 'integer'}, 'm': {'default': None, 'description': 'Log message', 'title': 'M', 'type': 'string'}}, 'title': 'MatchingLogEntry', 'type': 'object'}}, 'properties': {'status': {'description': 'HTTP status code of the response for the transaction response matching. E.g., 200, 404.', 'title': 'Status', 'type': 'integer'}, 'statusMessage': {'description': 'HTTP status message of the response', 'title': 'Statusmessage', 'type': 'string'}, 'headers': {'anyOf': [{'items': {'$ref': '#/$defs/HttpHeader'}, 'type': 'array'}, {'type': 'null'}], 'default': [], 'description': 'List of response headers', 'title': 'Headers'}, 'body': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'default': None, 'description': 'Decoded response body (plain text or JSON). Empty when no transaction matched.', 'title': 'Body'}, 'matchingLog': {'anyOf': [{'items': {'$ref': '#/$defs/MatchingLogEntry'}, 'type': 'array'}, {'type': 'null'}], 'default': [], 'description': 'Raw matching log entries from WireMock, used for debugging.', 'title': 'Matchinglog'}, 'matched': {'default': False, 'description': 'True when the request was matched by a transaction (matchingLog is empty). False means no transaction matched — check mismatch_reasons.', 'title': 'Matched', 'type': 'boolean'}, 'mismatch_reasons': {'description': 'Plain-text reasons why the request did not match any transaction. Populated from matchingLog when matched=False.', 'items': {'type': 'string'}, 'title': 'Mismatch Reasons', 'type': 'array'}}, 'required': ['status', 'statusMessage'], 'title': 'SandboxResponse', 'type': 'object'}| Name | Required | Description | Default |
|---|---|---|---|
| args | Yes | ||
| action | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| info | No | Info messages |
| error | No | Error message |
| total | No | Total available records |
| result | No | Result |
| warning | No | Warning messages |
| has_more | No | More records per page to list |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does so thoroughly. It discloses the mandatory two-step workflow, what each action does, that calling init alone does not test anything, how matched and mismatch_reasons should be interpreted, and that body is encoded automatically.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and the critical two-step workflow, and its action-by-action structure is helpful. It is somewhat long and repeats full nested schema blocks, but much of that detail is justified because the top-level schema provides almost no parameter documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex multi-action workflow and nested request/response objects, the description is complete enough for an agent to invoke the tool correctly. It explains the required call order, the arguments for each action, and how to interpret the response, including matched and mismatch_reasons.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description compensates by documenting the action values and their required args, including workspace_id, transaction_id, and the SandboxRequest fields. It also adds meaning to the nested request and response structures beyond what the generic schema communicates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: testing HTTP transactions in a sandbox. It explicitly distinguishes this tool from messaging-related siblings by saying MESSAGING transactions are not supported, which is important given the sibling set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear usage guidance: use for HTTP transaction verification or re-testing after an update, and it explicitly excludes MESSAGING transactions. It also mandates the two-call sequence init then test_request, though it does not name sibling alternatives for managing HTTP transactions outside the sandbox.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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'}| Name | Required | Description | Default |
|---|---|---|---|
| args | Yes | ||
| action | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| info | No | Info messages |
| error | No | Error message |
| total | No | Total available records |
| result | No | Result |
| warning | No | Warning messages |
| has_more | No | More records per page to list |
TDQS
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.
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.
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.
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.
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.
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): "equals_json" (variables embedded as JSON values e.g. {"id": "${id}"}) and
"equals_xml" are the ONLY body matchers that get an auto-populated sampleBody. "matches_json"
with equalTo() helper e.g. [[$.field, equalTo(${id})]] does NOT get a sampleBody — prefer
equals_json/equals_xml when a request payload should be preserved as the sample body.
- Body (XML): matcherName "equals_xml" or "matches_xml" with matching() helper
- Path matchers (matches_json/matches_xml): ONE [[path, fn(arg)]] pair per matcher, where fn is
equalTo(value) or matching(regex) and the argument is written WITHOUT quotes (quotes are matched
literally). To check several paths, use one matcher per path.
- matchingValue/sampleBody on body matchers are supplied as plain text — the
virtual_services_http_transaction tool base64-encodes/decodes them automatically on
create/update/read/list. Do NOT base64-encode them yourself before calling that tool.
- Response content: base64-encoded string containing ${fieldName} — variables resolve at runtime.
Additional rules:
- If the same variable appears multiple times in one transaction (e.g. /test/${id}/${id}?q=${id}),
ALL occurrences must match the SAME value in the incoming request.
- Variables not defined in the dataset are treated as literal strings — the request must contain
the exact text "${varName}" to match.
Note: Handlebars ({{...}}) is separate — it is for dynamic response templating, not dataset substitution.
Actions:
- create_from_schema: Create a dataset by defining entities with field names and generator
expressions. Supported generators include sequenceGenerator(start), randInt(min,max),
randText(minLen,maxLen), randDate(min,max), guid(), regExp(pattern), and 80+ others.
See https://help.blazemeter.com/docs/guide/test-data-generator-functions.html
args(dict):
workspace_id (int): Mandatory.
service_id (int): Mandatory.
service_name (str): Mandatory. Used in package/asset naming.
entities (list): Mandatory. Each entry:
name (str): entity name.
fields (list): each {name: str, generator: str}.
repeat (int, default=1000): rows to generate.
global_variables (dict, optional): flat str→str map of global variables.
- create_from_csv: Create a dataset from a local CSV file. Column headers become field names;
the entity name is derived as "{stem}_csv" (e.g. accounts.csv → entity "accounts_csv").
Generators use valueOfCSV("{filename}", "{field}") — values are sampled from CSV rows at runtime.
args(dict):
workspace_id (int): Mandatory.
service_id (int): Mandatory.
service_name (str): Mandatory.
csv_file_path (str): Mandatory. Absolute local path to the CSV file.
global_variables (dict, optional): flat str→str map of global variables.
- list: List data-model assets in a workspace (TDM assets endpoint, type=data-model).
args(dict):
workspace_id (int): Mandatory.
limit (int, default=50): max results.
offset (int, default=0): skip count.
- read: Read a data-model asset by service. Fetches with full content (withData=true).
args(dict):
workspace_id (int): Mandatory.
service_id (int): Mandatory.
service_name (str): Mandatory.
- update: Update an existing schema-based data-model by replacing its entities/fields. Use this
when the dataset was created with create_from_schema.
args(dict):
workspace_id (int): Mandatory.
service_id (int): Mandatory.
service_name (str): Mandatory.
entities (list): Mandatory. Full new entity list (same format as create_from_schema).
global_variables (dict, optional): flat str→str map of global variables.
- update_from_csv: Update an existing CSV-based data-model from a local CSV file. Use this
when the dataset was created with create_from_csv. Rebuilds the entity with valueOfCSV
generators. Optionally renames entity fields via field_mappings (e.g. when the entity field
name should differ from the CSV column name).
By default only the data-model JSON is updated (field rename / mapping change).
Set upload_csv=true only when the CSV file content itself has changed.
args(dict):
workspace_id (int): Mandatory.
service_id (int): Mandatory.
service_name (str): Mandatory.
csv_file_path (str): Mandatory. Absolute local path to the CSV file (used for headers).
field_mappings (list, optional): rename CSV columns to different entity field names.
Each entry: {name: str (entity field name), csv_column: str (CSV column name)}.
Example: [{"name": "account_name2", "csv_column": "account_name"}]
upload_csv (bool, default=false): set true to re-upload the CSV file content.
global_variables (dict, optional): flat str→str map of global variables.
TdmAsset Schema:
{'additionalProperties': True, 'properties': {'id': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'default': None, 'description': 'Asset id (UUID)', 'title': 'Id'}, 'name': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'default': None, 'description': 'Asset name', 'title': 'Name'}, 'displayName': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'default': None, 'description': 'Asset display name', 'title': 'Displayname'}, 'type': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'default': None, 'description': 'Asset type: data-model, mock-svc, global-entity', 'title': 'Type'}, 'packageId': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'default': None, 'description': 'Package id this asset belongs to', 'title': 'Packageid'}, 'content': {'anyOf': [{}, {'type': 'null'}], 'default': None, 'description': 'Parsed data-model content (present when withData=true)', 'title': 'Content'}}, 'title': 'TdmAsset', 'type': 'object'}| Name | Required | Description | Default |
|---|---|---|---|
| args | Yes | ||
| action | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well: it discloses that update replaces the entire entity list, that update_from_csv by default only rewrites the data-model JSON unless upload_csv=true, that read fetches full content via withData=true, that base64 encoding is handled automatically by the sibling tool, and that violating matcher naming rules causes matching to fail. These are non-obvious side effects and failure modes an agent could not infer from structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and action list are front-loaded, but the large matcher-rules block precedes the actions and reads as reference documentation for the transaction DSL rather than for this tool, consuming roughly half the text. The content is accurate and relevant to dataset variables, yet the ordering buries the actionable per-action contracts deeper than necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex multi-action tool with no output schema and no annotations, the description covers action semantics, args, generator syntax, and even embeds the TdmAsset shape so return values of read/list are inferable. Minor gaps remain: no statement of permissions/auth requirements or error behavior for failing creates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% — the schema only declares a free-form args object — so the description must compensate, and it does: every action's args are enumerated with mandatory/optional status, types, defaults (limit 50, offset 0, repeat 1000, upload_csv false), formats (entities as {name, fields}, field_mappings entries), and worked examples. This is substantially more than the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening line names a specific resource (TDM datasets for virtual services) and the six operations (create_from_schema, create_from_csv, list, read, update, update_from_csv) are spelled out explicitly. It is distinguishable from siblings like virtual_services_http_transaction, though that differentiation appears only incidentally in the base64 note rather than as an explicit statement of scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Per-action routing guidance is present and useful: 'Use this when the dataset was created with create_from_schema' for update, and the same for update_from_csv, plus 'Set upload_csv=true only when the CSV file content itself has changed.' What is missing is guidance on when to use this tool at all versus related virtual-service tools, or prerequisites (e.g. whether a service must exist first).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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'}| Name | Required | Description | Default |
|---|---|---|---|
| args | Yes | ||
| action | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| info | No | Info messages |
| error | No | Error message |
| total | No | Total available records |
| result | No | Result |
| warning | No | Warning messages |
| has_more | No | More records per page to list |
TDQS
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.
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.
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.
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.
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.
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'}| Name | Required | Description | Default |
|---|---|---|---|
| args | Yes | ||
| action | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| info | No | Info messages |
| error | No | Error message |
| total | No | Total available records |
| result | No | Result |
| warning | No | Warning messages |
| has_more | No | More records per page to list |
TDQS
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.
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.
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.
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.
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.
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'}| Name | Required | Description | Default |
|---|---|---|---|
| args | Yes | ||
| action | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| info | No | Info messages |
| error | No | Error message |
| total | No | Total available records |
| result | No | Result |
| warning | No | Warning messages |
| has_more | No | More records per page to list |
TDQS
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.
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.
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.
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.
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.
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.
17 tool updates
v1.0.10- First observed
blazemeter_account - First observed
blazemeter_user - First observed
blazemeter_workspaces - First observed
virtual_services_action - First observed
virtual_services_asset - First observed
virtual_services_configuration - First observed
virtual_services_http_transaction - First observed
virtual_services_location - First observed
virtual_services_messaging_transaction - First observed
virtual_services_messaging_virtual_service - First observed
virtual_services_recording - First observed
virtual_services_sandbox - First observed
virtual_services_service - First observed
virtual_services_test_data - First observed
virtual_services_tracking - First observed
virtual_services_virtual_service - First observed
virtual_services_virtual_service_template
TDQS
Scored across 17 tools
Most tools target a clearly distinct resource (transactions, services, locations, configurations, assets, recordings, tracking, sandbox), and the descriptions spell out when to use each. The main soft spots are the generic-looking `virtual_services_virtual_service` (transactional only) sitting next to `virtual_services_messaging_virtual_service` — both answer to "virtual service" — and `virtual_services_sandbox` overlapping with the `create_and_test` action inside the HTTP transaction tool. These are resolvable from the descriptions but require careful reading.
Tool names follow a predictable `<prefix>_<resource>` snake_case pattern (virtual_services_* for the domain tools, blazemeter_* for the account/identity tools), so the set is easy to scan. Minor deviations exist: singular/plural mixing (`blazemeter_user`, `blazemeter_account` vs `blazemeter_workspaces`, `virtual_services_location` vs others), and the action vocabulary inside tools mixes underscores with hyphens (`create-mq9`, `update-mq9`).
17 tools is on the heavy side, but each maps to a genuine, distinct entity in the service-virtualization domain (transactions, virtual services, templates, TDM datasets, recordings, assets, configurations, tracking, sandbox, plus account/workspace scaffolding). Some surface is duplicated between the transactional and messaging virtual service tools (deploy/stop/configure/set_proxy/assign_*), which inflates the count, but nothing feels arbitrary.
Read/list/create/update coverage is strong across nearly every resource, and lifecycle actions (deploy, stop, configure, assign/unassign, sandbox testing, tracking) are well covered. However, there is no delete operation anywhere in the surface — not for transactions, services, virtual services, templates, configurations, assets, or recordings — and `virtual_services_action` offers no update/delete for actions, leaving agents with dead ends when cleanup is required. Messaging transactions also have no sandbox path (documented, but still an asymmetry with HTTP).
Maintenance
Related MCP Connectors
AI-callable tools for API mocking, testing, monitoring, security, and automation.
Drive OctoPerf load testing from any AI agent: import, edit, validate, run scenarios, read metrics.
Build, validate, and manage API simulations in WireMock Cloud from MCP-compatible AI agents.
MCP server for AI access to SmartBear tools, including BugSnag, Reflect, Swagger, PactFlow, QTM4J.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceConnects AI tools to Verblaze localization projects, enabling management of translations, languages, screens, and project resources through natural language interactions.8 npmMIT
- FlicenseNot gradedqualityCmaintenanceIntegrates 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.-

BlazeMeter MCP Serverofficial
AlicenseNot gradedqualityCmaintenanceEnables AI agents to manage performance testing workflows on BlazeMeter's cloud platform through natural language interactions.26Apache 2.0
Specmatic MCP Serverofficial
AlicenseAqualityDmaintenanceExposes 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.320 npm12MIT