Server Quality Checklist

Tool Scores

• virtual_services_locationA
  3.5/5.0
  Behavior3/5

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

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

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

  Conciseness3/5

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

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

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

  Completeness3/5

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

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

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

  Parameters3/5

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

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

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

  Purpose4/5

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

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

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

  Usage Guidelines4/5

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

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

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

• virtual_services_serviceA
  3.5/5.0
  Behavior2/5

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

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

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

  Conciseness4/5

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

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

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

  Completeness3/5

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

  The description covers all actions and parameter semantics, and includes the output schema, which is good. However, it lacks guidance on when to use this tool versus sibling tools, does not mention the absence of a delete action (or any destructive operations), and provides no details on returns or errors. Given the tool's complexity (4 actions), it is adequate but has clear gaps in behavioral and comparative context.

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

  Parameters5/5

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

  The input schema has an open 'args' object with 0% coverage, so the description fully compensates. Each action lists required parameters with types, defaults, and valid ranges (e.g., limit default=10, valid=[1 to 50]). It clearly maps parameters to actions, providing meaning far beyond the schema. Minor flaw: it labels optional parameters as 'required', but the information itself is detailed and helpful.

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

  Purpose4/5

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

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

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

  Usage Guidelines3/5

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

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

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

• blazemeter_userA
  3.8/5.0
  Behavior4/5

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

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

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

  Conciseness4/5

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

  The description is concise and structured with sections for actions and hints. It contains no fluff, and each line contributes useful information. The opening 'Operations on user information' is slightly redundant with the tool name but acceptable.

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

  Completeness4/5

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

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

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

  Parameters4/5

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

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

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

  Purpose4/5

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

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

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

  Usage Guidelines3/5

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

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

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

• blazemeter_workspacesA
  3.8/5.0
  Behavior3/5

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

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

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

  Conciseness4/5

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

  The description is well-structured with clear action labels and parameter details. It is not overly verbose, though the formatting includes some redundant phrasing like 'Dictionary with the following required parameters' which is repeated. The main purpose is front-loaded, and all content is relevant.

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

  Completeness4/5

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

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

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

  Parameters5/5

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

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

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

  Purpose4/5

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

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

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

  Usage Guidelines3/5

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

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

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

• virtual_services_messaging_transactionA
  3.8/5.0
  Behavior4/5

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

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

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

  Conciseness2/5

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

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

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

  Completeness4/5

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

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

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

  Parameters4/5

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

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

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

  Purpose4/5

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

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

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

  Usage Guidelines4/5

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

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

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

• virtual_services_assetA
  3.9/5.0
  Behavior3/5

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

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

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

  Conciseness3/5

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

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

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

  Completeness4/5

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

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

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

  Parameters5/5

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

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

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

  Purpose4/5

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

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

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

  Usage Guidelines4/5

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

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

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

• blazemeter_accountA
  4/5.0
  Behavior3/5

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

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

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

  Conciseness4/5

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

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

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

  Completeness4/5

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

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

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

  Parameters5/5

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

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

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

  Purpose4/5

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

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

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

  Usage Guidelines4/5

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

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

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

• virtual_services_messaging_virtual_serviceA
  4.1/5.0
  Behavior4/5

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

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

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

  Conciseness3/5

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

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

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

  Completeness4/5

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

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

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

  Parameters5/5

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

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

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

  Purpose4/5

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

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

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

  Usage Guidelines4/5

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

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

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

• virtual_services_configurationA
  4.2/5.0
  Behavior3/5

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

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

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

  Conciseness4/5

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

  The description is lengthy but well-organized by action. The embedded Configuration Schema is redundant given the likely output schema, but does not detract significantly. Overall, it earns its length through thorough coverage of the tool's complexity.

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

  Completeness4/5

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

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

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

  Parameters5/5

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

  The input schema is just a generic 'action/args' envelope, but the description details every required parameter per action, including types, mandatory flags, and defaults for limit/offset. This greatly exceeds the schema and gives the agent precise invocation guidance.

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

  Purpose5/5

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

  The description opens with 'Operations on virtual service configurations' and enumerates four explicit actions (read, list, create, update), clearly identifying the tool's scope and distinguishing it from sibling tools focused on other virtual service resources.

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

  Usage Guidelines4/5

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

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

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

• virtual_services_virtual_serviceA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden and does well: it discloses that deploy/stop/configure/apply_template return tracking_ids requiring polling, states that configure only works on running virtual services, and explains the 'id None' trick for unassigning configuration. Minor copy-paste errors (e.g., 'assign' in unassign_transactions) slightly reduce clarity but do not undermine overall transparency.

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

  Conciseness3/5

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

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

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

  Completeness5/5

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

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

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

  Parameters5/5

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

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

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

  Purpose4/5

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

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

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

  Usage Guidelines4/5

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

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

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

• virtual_services_actionA
  4.4/5.0
  Behavior4/5

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

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

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

  Conciseness4/5

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

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

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

  Completeness4/5

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

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

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

  Parameters5/5

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

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

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

  Purpose5/5

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

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

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

  Usage Guidelines4/5

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

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

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

• virtual_services_virtual_service_templateA
  4.5/5.0
  Behavior3/5

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

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

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

  Conciseness4/5

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

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

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

  Completeness5/5

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

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

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

  Parameters5/5

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

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

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

  Purpose5/5

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

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

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

  Usage Guidelines5/5

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

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

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

• virtual_services_http_transactionA
  4.7/5.0
  Behavior5/5

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

  With no annotations, the description carries the full burden and excels. It details error behavior (e.g., create_and_test failures leave the transaction existing, requiring update and sandbox re-init), return formats, and side effects. It also explains matcher rules and dataset variable handling, providing deep behavioral insight.

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

  Conciseness4/5

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

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

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

  Completeness5/5

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

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

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

  Parameters5/5

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

  The input schema is generic (action/args), so the description provides all parameter meaning. It documents each action's args with required/optional status, defaults, valid ranges, and the full GenericDsl structure with field descriptions. This fully compensates for 0% schema coverage.

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

  Purpose5/5

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

  The description clearly states the tool performs 'Operations on HTTP transactions' and explicitly says 'Use this when a user needs to create or select a HTTP transaction.' The name and content distinguish it from sibling tools like virtual_services_messaging_transaction.

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

  Usage Guidelines4/5

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

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

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

• virtual_services_recordingA
  4.7/5.0
  Behavior5/5

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

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

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

  Conciseness4/5

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

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

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

  Completeness5/5

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

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

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

  Parameters5/5

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

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

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

  Purpose5/5

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

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

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

  Usage Guidelines4/5

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

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

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

• virtual_services_test_dataA
  4.7/5.0
  Behavior5/5

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

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

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

  Conciseness4/5

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

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

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

  Completeness5/5

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

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

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

  Parameters5/5

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

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

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

  Purpose5/5

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

  The description clearly states the tool's purpose: 'Operations on TDM (Test Data Manager) datasets for virtual services.' It enumerates six distinct actions (create_from_schema, create_from_csv, list, read, update, update_from_csv), which distinguishes it from sibling tools that handle HTTP transactions, messaging, or asset management.

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

  Usage Guidelines4/5

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

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

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

• virtual_services_sandboxA
  4.9/5.0
  Behavior5/5

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

  With no annotations, the description carries full burden. It discloses the required sequential behavior of init and test_request, explains that matched=false indicates no match and to read mismatch_reasons, and describes response fields and their meanings. There is no contradiction.

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

  Conciseness4/5

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

  The description is lengthy but well-structured with sections for actions, sandbox request schema, and response schema. It includes both natural-language explanations and JSON schemas, which is somewhat redundant but valuable for a complex tool. Every major point is covered, though a bit verbose.

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

  Completeness5/5

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

  Given the complex two-action flow and sparse schema, the description is exceptionally complete. It explains when to use it, the exact sequence of calls, all parameter formats, how to interpret responses (matched, mismatch_reasons), and limitations (no messaging). No gaps remain.

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

  Parameters5/5

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

  The input schema is generic (only action and args) with 0% coverage. The description fully compensates by listing the two actions with their required args (workspace_id, transaction_id, request) and embedding the complete SandboxRequest schema with field descriptions and required properties, giving the agent all necessary parameter details.

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

  Purpose5/5

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

  The description opens with 'Testing HTTP transactions in sandbox,' clearly naming the resource (HTTP transactions) and the action (testing in sandbox). It also states 'Use this for HTTP transaction verification, or to re-test an existing transaction after update,' and explicitly excludes MESSAGING transactions, distinguishing it from sibling tools like virtual_services_messaging_transaction.

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

  Usage Guidelines5/5

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

  It provides explicit usage guidance: 'Use this for HTTP transaction verification, or to re-test an existing transaction after update,' and warns that MESSAGING transactions are not supported. It details the mandatory two-step process (init then test_request) and clarifies that calling only init does nothing, preventing common errors.

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

• virtual_services_trackingA
  5/5.0
  Behavior5/5

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

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

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

  Conciseness5/5

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

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

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

  Completeness5/5

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

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

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

  Parameters5/5

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

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

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

  Purpose5/5

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

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

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

  Usage Guidelines5/5

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

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

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