OctoPerf

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

The description goes beyond annotations by detailing bulk-creation, structural deduplication (skipping existing rules), return of only created rules, and the fact that rules are not wired into Virtual Users. This adds valuable behavioral context that annotations do not cover.

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 a single dense paragraph with no redundant information. It front-loads the key action and follows with important details (dedup, return, next step). Every sentence is essential.

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 complexity (bulk-creation, dedup, follow-up action) and the presence of an output schema, the description fully covers the behavior, return value, and next steps. It is complete for an agent to use 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?

Both parameters are fully described in the schema, so baseline is 3. The description adds value by specifying that frameworkId refers to frameworks from 'list_correlation_frameworks', and context about presets. This enriches parameter understanding beyond the 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 the specific verb 'Add' and resource 'correlation framework to project', lists the presets, and distinguishes it from sibling tools like 'apply_correlations_to_virtual_user' and 'create_correlation_rule' by explaining the bulk creation and dedup behavior. It fully clarifies what the tool does.

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 for when to use this tool (to add a framework preset) and includes a direct instruction to call 'apply_correlations_to_virtual_user' next. However, it does not explicitly mention when not to use it or list alternatives, though the sibling context implies alternatives exist.

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

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

Discloses async nature, immediate taskId return, need to poll, and that it modifies the virtual user (destructive). Annotations already mark destructiveHint=true, but description adds valuable 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?

Four sentences, well-structured, front-loaded with purpose, no unnecessary words.

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 async complexity and output schema presence, description covers necessary actions (submitting and polling) and expected side effects.

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?

Only one parameter with full schema coverage. Description adds minimal extra meaning beyond schema, but baseline 3 is appropriate.

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 submits an async correlation task that re-walks the virtual user's action tree and applies correlation rules, which distinguishes it from creating rules.

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 context that it's for making correlation rules effective after creation, and instructs to poll get_task_result. Does not explicitly mention when not to use.

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

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

The description details non-destructive behavior (original untouched), what is copied (full action tree) and not copied (recorded request/response bodies), tagging with 'backup' and optional label, and the return values. This goes beyond annotations, which only provide readOnlyHint and destructiveHint flags. No contradictions.

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 a well-structured single paragraph: purpose first, then details of what is copied, tagging, non-destructive nature, usage timing, and return values. Every sentence is informative with no wasted words.

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 has 2 parameters, an output schema, and the description explains return values (id, name, tags, timestamps, url), the description is complete for an agent to understand how to use and what to expect.

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%, but the description adds context: label is an optional reason/marker, virtualUserId creates the copy in the same project. This adds meaning beyond the schema descriptions.

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 creates a backup of an OctoPerf Virtual User before hard-to-reverse changes, specifying the verb 'backup' and resource 'Virtual User'. It distinguishes from siblings like delete_virtual_user or update_virtual_user by focusing on duplication and tagging.

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 to run this BEFORE applying correlation rules or editing the tree, and notes that OctoPerf has no built-in versioning, providing a clear use case. It does not explicitly state when not to use, but the guidance is strong.

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

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

Annotations already indicate non-destructive creation. Description adds that the same value is always returned, and returns metadata. No contradictions.

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?

Three sentences front-loaded with purpose, behavior, and use cases. No filler, each sentence adds unique information.

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 low complexity and existing output schema, description covers creation behavior and return value. Lacks explicit prerequisite mention but schema requires projectId.

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 covers all parameters with descriptions. Description only repeats the naming convention (${name}) already in schema. Adds minimal extra value beyond 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?

Clearly states verb 'Create' and resource 'Constant variable', distinguishes from sibling variable types (counter, csv, random, secret) by specifying constant behavior. Provides concrete use cases (tokens, hosts, URLs).

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?

Describes typical use cases (static parameters) but does not explicitly mention when to avoid or compare with other variable types. Agent must infer from sibling context.

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

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

Annotations already indicate the tool is not read-only (readOnlyHint=false) and not destructive (destructiveHint=false), so the description is not burdened with those disclosures. It adds value by explaining the injection semantics (PART_OF_VALUE, substring replacement) and the binding of captured values to a variable. No contradictions with annotations are present.

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 a single, well-organized paragraph that front-loads the core purpose and then provides workflow context. It is appropriately sized for the tool's complexity (7 parameters) and does not include fluff. Minor suggestion: could be slightly more concise by trimming some workflow repetition, but overall 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?

Given the tool's complexity and the existence of an output schema, the description covers all necessary aspects: purpose, workflow integration, behavioral details, and parameter semantics. It explains when and how to use the tool in a realistic scenario (auto-correlation after validation failure), making it complete for an AI agent.

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 100% description coverage, so the description's parameter details are supplementary. The description reinforces the regex's first capture group, the variable binding, and the injection target semantics (PART_OF_VALUE), adding context beyond the schema. This enhances understanding, but the schema already covers the basics.

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 creates a regex-based correlation rule in an OctoPerf design project, specifying that it captures a value from the response body or headers via a regex capture group and reinjects it into subsequent requests. It distinguishes itself from sibling tools like delete_correlation_rule or list_correlation_rules by detailing its role in an auto-correlation workflow, making its 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 explicitly places the tool within an auto-correlation workflow, instructing to use it after a failed `validate_virtual_user` and before `apply_correlations_to_virtual_user`. It mentions inspecting failure details and spotting dynamic values, providing clear context. However, it does not explicitly state when not to use this tool or list alternatives beyond the workflow steps, though the intent is well conveyed.

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

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

The description explains the read behavior and return value. Annotations already indicate non-destructive, readOnlyHint=false. No contradictions. Adds context about counter state management during test execution.

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?

Three concise, front-loaded sentences with no waste. First sentence states purpose, second explains behavior, third gives use case and return value.

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 9 parameters and an output schema, the description is complete enough. It covers the core behavior and purpose. While it omits details like per-user, reset, format, those are in the schema. Slightly more differentiation from other variable types would improve completeness.

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 each parameter has a description in the input schema. The tool description ties parameters into a coherent narrative (e.g., range [start, end] and increment) but does not add substantial new meaning beyond the 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 the tool creates a counter variable, specifies its behavior (each read returns next value in [start, end] stepped by increment), and provides a use case (generating unique IDs). It distinguishes itself from sibling variable creation tools by name and behavior.

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 mentions the use case (unique IDs across iterations or VUs), giving some guidance on when to use. However, it does not explicitly compare to alternatives like constant or random variables, which would help agents choose correctly.

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

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

The description adds behavioral context beyond annotations by explaining the row-by-row pulling and the substitution mechanism where column names become runtime variables. It does not disclose error conditions or file-not-found behavior, but annotations already indicate non-destructive and non-read-only nature.

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 three sentences long, front-loaded with the core purpose, and every sentence adds value. No redundant or wasteful wording.

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 rich schema descriptions (100% coverage) and the presence of an output schema, the description adequately explains the core concept and key differentiation (column name substitution). It links to related tools (upload_project_file) but could briefly mention scope or encoding options for completeness.

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 100%, so baseline is 3. The description reinforces the parameter semantics by explaining the display-only nature of 'name' and the substitution of column names, but this adds only marginal value over the already detailed schema descriptions.

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 creates a CSV variable in OctoPerf, specifying the source from a CSV file and explaining column substitution. It distinguishes from sibling variable creation tools by focusing on CSV-based data parameterization and clarifying the role of the 'name' parameter.

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 prerequisite (CSV file must be uploaded via upload_project_file) but does not explicitly state when to use this tool versus alternatives like constant or random variable creation. Usage guidance is implicit rather than explicit.

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

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

Annotations already indicate mutation (readOnlyHint=false) and non-destructive (destructiveHint=false). Description adds that it returns a deep-link URL, enriching behavioral context beyond annotations.

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?

Two sentences: first states purpose, second explains grouping and return info. No extraneous words, front-loaded, every sentence earns its place.

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 an output schema exists, the description fully covers creation scope, return structure (id, workspaceId, name, description, url), and project grouping, making it 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?

Schema coverage is 100% with descriptions for all parameters. Description adds that the name appears as in the UI, description is optional, and workspaceId is the OctoPerf workspace id, providing extra clarity.

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?

Description specifies the verb 'Create', the resource 'OctoPerf DESIGN project', and the scope 'in a workspace'. It clearly distinguishes from sibling tools like 'update_project' by focusing on creation.

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?

Usage is implied by the creation verb, and sibling tools indicate alternatives (e.g., update). However, no explicit 'when not to use' or direct comparison to alternatives is provided.

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

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

Description explains that each read yields a uniformly-random integer, optionally formatted, and returns metadata. Annotations already indicate non-read-only, and description adds meaningful behavioral context beyond 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?

Two sentences, no wasted words. First sentence states purpose, second covers behavior and return. Front-loaded and concise.

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 presence of an output schema and 6 parameters, the description covers creation, read behavior, formatting, and return. It could mention that an existing project is required, but the projectId parameter implies 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?

Schema coverage is 100%, but description adds extra context such as the printf-style format example and the fact that name is referenced via ${name}. This adds value beyond the schema descriptions.

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?

Description clearly states it creates a random variable in OctoPerf, with specific detail about uniform integer distribution and optional formatting. This distinguishes it from sibling tools like create_constant_variable.

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?

Description implies usage for needing a random integer but does not explicitly compare to other variable types (constant, counter, CSV, secret) or specify when to choose this tool over them.

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

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

Annotations are non-destructive and non-read-only, which matches the creation action. Description adds context on engine selection and return values. No contradictions, but no mention of idempotency or overwriting.

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?

Description is a single focused paragraph with no wasted words. Front-loaded with purpose, then details, then alternatives. Efficient and well-structured.

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 9 parameters, high complexity, and presence of output schema, the description covers all key aspects: ramp-up shape, round-robin, engine mapping, and return value. No missing critical information.

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%, but description adds significant meaning: explains round-robin, total users calculation, and engine defaulting per VU type. Adds value beyond 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?

Clearly states it creates a scenario with a RAMP-UP load shape. Verb 'create', resource 'Scenario', and specific load shape are explicit. Mentions sibling tools for richer shapes.

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?

Explicitly tells when to use this tool vs alternatives (ramp_up_down, stairs). Describes edge case rampUpSec=0. Explains round-robin assignment and engine defaulting.

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

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

Annotations already indicate this is not read-only (readOnlyHint=false). The description adds behavioral details like the load shape, per-VU semantics, and return value (id and url deep-link), which goes beyond the annotations.

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 two sentences, each serving a distinct purpose: defining the tool's action and providing usage context. No redundant information, perfectly 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?

With an output schema present, the description sufficiently explains the return value. It covers the load shape, parameter semantics, and cross-references a sibling tool. A minor gap could be explicit mention of the output format, but it's adequate.

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 baseline is 3. However, the description adds meaningful context for key parameters (e.g., 'users' applies per VU, 'virtualUserIds' creates one profile per VU) and references sibling semantics, providing extra clarity.

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 creates a scenario with a specific ramp-up-then-ramp-down load shape. It distinguishes itself from the sibling 'create_scenario_ramp_up' by explicitly mentioning the ramp-down phase, making the 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?

It provides a clear use case ('soak tests with a controlled wind-down') and references an alternative tool for similar semantics. While it does not explicitly state when not to use, the context is sufficient for selection.

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

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

Annotations are minimal (non-readOnly, non-destructive); the description adds behavioral details: the ramp-in-steps algorithm, plateau, same semantics as ramp-up, and return of id and URL. It transparently covers the creation behavior.

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 brief (several sentences) and front-loaded with the main purpose. It efficiently covers the load shape, use case, sibling reference, and return value without excess.

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 10 parameters, 100% schema coverage, and likely output schema, the description adequately covers the tool's purpose, load shape mechanics, and return. It does not mention error conditions or prerequisites, but the schema already documents required parameters.

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%; the description adds significant meaning by explaining how 'users', 'rampUpSec', 'stepCount', and 'holdForSec' interact (e.g., each step adds users/stepCount users). It also clarifies 'users' applies per VU and locations are round-robin.

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 verb 'Create', the resource 'Scenario', and the specific load shape 'ASCENDING STAIRS'. It distinguishes from siblings by naming the shape and referencing 'create_scenario_ramp_up' for semantic comparison.

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 clear use case ('capacity-finding tests to observe SUT behavior at each step') and references a sibling for semantics, but does not explicitly list when not to use or alternative tools.

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

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

The description discloses that the value is encrypted at rest and that list_variables returns only ciphertext. Annotations are present (readOnlyHint=false, destructiveHint=false) and consistent; the description adds valuable behavioral context beyond the annotations.

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?

Three concise, front-loaded sentences. Each sentence serves a distinct purpose: purpose, security/retrieval behavior, and usage guidance. No wasted words.

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 output schema is present (context signals), the description need not detail the return value beyond 'Returns the created variable's listing.' It adequately covers the creation process and security. Minor gaps: no error handling or idempotency mention, but overall complete for a creation 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 coverage is 100% (all 4 parameters described). The description adds meaning for 'name' (referenced as ${name}) and 'value' (plaintext, encrypted at rest), enhancing the schema's descriptions. Sibling differentiation is implicit.

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 verb ('Create') and resource ('Secret variable'), and specifies it is within an OctoPerf design project. It distinguishes from sibling variable creation tools (e.g., create_constant_variable) by focusing on sensitive parameterization inputs.

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 states the tool is for sensitive inputs like passwords and API tokens, giving clear context for when to use it. However, it does not explicitly mention when not to use it or provide direct alternatives.

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

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

Annotations indicate a non-destructive write. The description adds details about backend behavior (pulling other benchResults from the same project) and the output fields, which is valuable beyond the annotations.

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?

Well-structured with each sentence providing unique information. No redundancy, adequate length for the 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?

Covers mechanism, parameter constraints, and return fields. Lacks error handling or prerequisites but sufficient for a complex tool with output schema referenced.

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 baseline is 3. The description adds usage context for parameters (open-ended ranges, at least one constraint), which enhances understanding beyond schema descriptions.

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 creates a TREND bench report using a creation date selector, differentiating from siblings like create_trend_report_by_name and create_trend_report_by_tags. The verb 'Create' is specific and the resource is well-defined.

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?

Provides explicit guidance on parameter usage (at least one of fromMs/toMs, open-ended ranges) and return value. Sibling names imply alternatives, but no exclusionary language.

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

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

Annotations (readOnlyHint=false, destructiveHint=false) confirm it's a non-destructive write. The description adds details on the backend behavior (pulling benchResults from the same project with name matching) and the return fields (id, name, etc., including a deep-link URL). No contradictions with annotations.

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 a single dense paragraph that efficiently conveys the purpose and mechanism. It front-loads the action and then details the matching logic and return fields. Minor improvement could be structuring return fields more concisely, but no wasteful sentences.

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 complexity (4 required params, no output schema), the description adequately explains the algorithm and return fields. It does not mention prerequisites (e.g., existence of reference benchResult) or error handling, but for an AI agent the core information is sufficient.

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% with descriptions for all 4 parameters. The description adds value by explaining how 'search' and 'searchType' work together (e.g., the enumeration of search types and their matching behavior), which goes beyond the schema's individual descriptions.

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 verb 'create', the resource 'TREND bench report', and the specific mechanism: seeded from a reference benchResult and matching scenario names via search and searchType. It distinguishes from sibling tools (create_trend_report_by_creation_date, create_trend_report_by_tags) by specifying name-based matching.

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 implies usage for name-based trend reports but does not explicitly state when to use this versus alternatives. It provides context on the matching behavior but lacks direct guidance on when not to use it or mention of sibling tools.

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

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

The description goes well beyond annotations by detailing the backend behavior: fetching other benchResults carrying ALL tags, plotting them, and materializing the rest on each read. It also lists return fields including a deep-link URL, providing rich 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 a single paragraph of about 4 sentences, each earning its place. It could be slightly more structured (e.g., bullet points for return fields), but it is efficient and not verbose.

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 low parameter count (3) and the presence of an output schema (implied by listed fields), the description covers creation flow, backend behavior, and return values completely. No gaps identified for the complexity level.

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 schema coverage is 100%, the description adds significant meaning: for 'tags' it clarifies intersection semantics ('ALL tags must match'), and for 'shownResults' it explains the maximum count and drop-off behavior ('older matches drop off first'). This adds value beyond schema descriptions.

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 uses specific verb 'Create' and resource 'TREND bench report', clearly distinguishing from sibling tools like 'create_trend_report_by_creation_date' that create reports by different criteria. It explains the seeding mechanism with reference benchResult and tags.

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 for when to use: to create a trend report from tags, mirroring the OctoPerf UI flow. It does not explicitly exclude alternatives or state when not to use, but the context of sibling tools implies differentiation.

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

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

The description goes beyond the `destructiveHint: true` annotation by detailing that the report and its sub-items are deleted while benchResults remain intact and other reports still work. This adds valuable behavioral context without contradicting annotations.

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 three sentences long, front-loaded with the action, and every sentence adds value: core purpose, destructive behavior, and usage prerequisite. No wasted words.

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 delete operation without an output schema, the description fully explains what is deleted, what persists, and how other entities are unaffected. It provides sufficient context for an agent to invoke the tool 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?

Only one parameter (`reportId`) exists with 100% schema description coverage. The description 'by id' confirms the parameter's role, but does not add additional meaning beyond the schema's own description. Baseline score is appropriate.

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 starts with 'Delete an OctoPerf bench report by id.' It clearly specifies the verb (delete), resource (bench report), and identifier (id). It distinguishes from sibling deletion tools like delete_correlation_rule or delete_scenario by focusing on bench reports.

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 warns 'DESTRUCTIVE' and states 'Use only after the user has confirmed the deletion.' It explains what is dropped vs kept, but does not explicitly state when not to use it or list alternatives. However, the context provides enough guidance for appropriate use.

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

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

Goes beyond annotation (destructiveHint: true) by detailing the exact consequences: existing variables are preserved but future applications of apply_correlations_to_virtual_user will not reinject. Also mentions return value.

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?

Two concise sentences that front-load the action and provide necessary consequences. No wasted words.

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?

Sufficiently complete for a single-parameter deletion tool with no output schema. Explains the effect and return value.

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 single parameter correlationRuleId is already well-described in the schema. The description adds no extra detail beyond what 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?

Clearly states 'DELETES a correlation rule from an OctoPerf design project' with specific verb and resource. Distinguishes from sibling tools like create_correlation_rule and list_correlation_rules.

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?

Provides context on when to use by explaining the destructive effect on virtual user correlations. However, lacks explicit mention of when not to use or alternatives.

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

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

The description goes beyond annotations by detailing the internal process: the tool first fetches impacted VU IDs via a usage endpoint, then deletes, and returns those IDs. It also explicitly states the dangling effect on HTTP request actions, providing rich 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 concise, with three well-structured sentences that front-load the core action. It provides all necessary information without superfluous text.

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 low complexity (single required parameter, clear annotations, and output schema present), the description fully covers what the tool does, its side effects, and what it returns. No gaps identified.

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% with a clear description for serverId. The tool description does not add additional parameter meaning beyond what the schema provides, so baseline score of 3 applies.

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?

Description clearly identifies the tool as deleting an HTTP server from a design project, with specific verb and resource. It distinguishes from siblings like delete_unused_http_servers by implying it affects used servers, and mentions the destructive impact.

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?

While the description explains the destructive consequences, it does not provide explicit guidance on when to use this tool versus alternatives like delete_unused_http_servers. Usage is implied but not directly compared or advised.

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

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

Beyond the annotation 'destructiveHint: true', the description adds critical behavioral context: it explains that deleting a file will leave Virtual User actions (CSV iterators, file body sources) that read from that file dangling, and that it returns the deleted filename for confirmation. This fully informs the agent of consequences.

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 three sentences, front-loaded with the core action, followed by warnings and return value. Every sentence is necessary and contributes to understanding without 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 simple delete tool with two required parameters and no output schema, the description is complete. It covers purpose, destructive impact, and return value. Given the context of sibling tools, it sufficiently differentiates itself.

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% with clear parameter descriptions. The tool description does not add additional meaning beyond what the schema already provides for 'filename' and 'projectId'. Baseline 3 is appropriate.

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 deletes a file from an OctoPerf design project, using the specific verb 'DELETES' and resource 'file from an OctoPerf design project'. It distinguishes itself from other sibling delete tools by specifying the resource type, and includes the return value.

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 implies usage (when a file needs deletion) but does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or when not to use it. It only states the destructive nature without comparative context.

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

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

Annotations already mark destructiveHint=true, but the description goes far beyond by detailing what exactly is destroyed (userProfiles, load shapes, engine settings), what remains (past bench runs/reports), and side effects (scheduled jobs stop). This fully discloses the impact.

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 well-structured: action, destructiveness, detailed consequences, and usage instruction, all in three sentences with no wasted words.

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 (one param, destructive), the description covers all essential context: what it deletes, what persists, side effects on schedules, and confirmation requirement. No output schema needed.

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% and the description's mention of 'by id' does not add significant meaning beyond the schema's 'OctoPerf scenario id to delete'. The parameter semantics are adequately covered by the 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 'Delete an OctoPerf Scenario by id', specifying the verb and resource. It distinguishes from sibling delete tools by emphasizing it drops the entire scenario configuration, not just a part.

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?

Explicitly says 'Use only after the user has confirmed the deletion', providing a key usage guideline. Also notes that past bench runs remain and scheduled jobs stop, helping the agent decide when to use this tool. However, it doesn't explicitly compare with sibling delete tools like delete_bench_report.

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

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

Annotations provide destructiveHint=true, but the description adds valuable context: past runs remain in bench history, only schedule entry is dropped. This enhances transparency beyond annotations, though could mention whether deletion is immediate or reversible (it states permanent).

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?

Two concise sentences, front-loaded with 'DESTRUCTIVE' label and key action, no unnecessary words. Perfectly structured for quick comprehension.

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?

With a single parameter, no output schema, and strong annotations, the description fully covers the tool's behavior, side effects (past runs preserved), and usage context. Nothing missing.

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 the description doesn't need to add parameter info. The schema already describes jobId adequately. The description does not elaborate further, so baseline score of 3 is appropriate.

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: 'permanently delete a ScheduledJob'. It uses specific verb ('delete') and resource ('ScheduledJob'), and distinguishes itself from the sibling 'disable_scheduled_job' by noting it is a permanent deletion.

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 guidance: 'For a reversible pause prefer disable_scheduled_job' and 'Use only after the user has confirmed', giving both when to use and when not to use, with a named alternative.

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

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

Adds safety guarantee beyond the destructiveHint annotation, noting only unreferenced servers are removed. Also discloses return of baseUrl for audit. No contradiction with annotations.

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?

Two concise sentences that are front-loaded: first states action and scope, second adds safety and return value. No wasted words.

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?

Covers purpose, safety, and return value adequately for a simple tool. Could mention error cases or behavior when no unused servers exist, but the output schema likely covers return structure.

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% for the single parameter projectId, with a clear description in the schema. The tool description does not add extra meaning for this parameter, so baseline score of 3 applies.

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?

Clearly states the tool deletes unused HTTP servers in an OctoPerf project, with specific verb 'delete' and resource 'unused HTTP servers'. Distinguishes from siblings like delete_http_server by emphasizing the 'unused' condition.

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?

Provides context that it is safe and only removes unreferenced servers, but does not explicitly state when to use this tool versus alternatives like delete_http_server for force deletion. The return value for audit is mentioned.

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

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

Beyond the destructiveHint annotation, the description adds critical context: dangling references to the variable and return of the deleted variableId for confirmation. This helps the agent understand consequences.

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?

Two concise sentences, front-loaded with a tag and clear action, no redundancy. Every sentence adds value.

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 simple delete operation with one parameter and no output schema, the description covers the effect on referenced actions and the return value. Lacks error handling but is adequate.

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 already describes the single parameter variableId with 100% coverage. The description does not add further detail about the parameter beyond what the schema provides, so baseline 3 is appropriate.

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 'DELETES a variable from an OctoPerf design project', using specific verb and resource. It distinguishes from sibling tools like delete_correlation_rule or delete_scenario by explicitly mentioning 'variable'.

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 no guidance on when to use this tool versus alternatives (e.g., create_variable, update_variable). No context on prerequisites or conditions for deletion.

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

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

The description discloses specific behavioral details beyond annotations: 'drops the entire action tree, all attached extractors, assertions and recorded responses. Validation history is preserved separately...' This adds significant context about what is destroyed and what is preserved, exceeding the destructiveHint annotation.

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 highly concise: two sentences, front-loaded with the purpose, then relevant behavioral and usage details. No unnecessary information.

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 simple destructive tool with one required parameter and no output schema, the description is complete. It covers what happens, what is preserved, and when to use it.

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 100% coverage with a clear description for virtualUserId. The tool description mentions 'by id' but does not add meaningful semantics beyond the schema's description. Baseline is 3.

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 'Delete an OctoPerf Virtual User by id.' It specifies the action (delete) and resource (virtual user by id), distinguishing it from other delete tools and virtual user manipulation tools among siblings.

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 only after the user has confirmed the deletion,' providing a clear usage guideline. It also implies destructive nature, but does not directly compare to alternatives like backup or edit.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that the output includes a deep-link URL and specific fields, providing useful context beyond annotations without contradiction.

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?

Two sentences: first defines purpose and output, second gives usage guidance. No wasted words.

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 simple projection tool with one parameter and an output schema, the description fully covers what the tool does, when to use it, and what it returns. Siblings list confirms unique role.

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 covers the single parameter fully. The description mentions 'raw VU id' from import tools, adding slight context but not essential beyond 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?

Clearly states the tool projects a Virtual User into a compact listing with specific fields, and distinguishes itself from get_virtual_user by offering a lightweight alternative.

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?

Explicitly instructs when to use: after an import that returns a VU id when needing a UI link, or when wanting a lightweight projection instead of the full action tree. Also names sibling tool get_virtual_user as alternative.

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

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

Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds that the job stays in the scheduler and can be re-armed, and it specifies the return value (enabled=false, nextRun cleared). This provides good behavioral context beyond the annotations.

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 only two sentences, front-loads the key action, and includes usage context and return behavior with no unnecessary words.

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 simple tool with one parameter and an output schema, the description adequately covers purpose, usage, and return behavior. No additional information is needed.

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 provides 100% coverage for the single parameter jobId with a clear description. The tool description does not add additional meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.

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 action (Disable), the resource (ScheduledJob), and the scope (without deleting). It distinguishes from sibling tools like delete_scheduled_job and enable_scheduled_job by explicitly stating it pauses execution without deletion.

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 advises when to use the tool: 'Use this to safely stop a recurring cron without losing the configuration.' It also mentions the alternative enable_scheduled_job for re-arming, providing clear guidance on when to use versus other tools.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows it is a safe read operation. The description adds value by explaining the presigned URL nature, 5-minute validity, and single-use token behavior, which are not in annotations. No contradiction with annotations.

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 three sentences long, front-loaded with the core action of minting a presigned URL. No extraneous information; every sentence adds value (purpose, usage, and behavioral notes). It is well-structured and 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, combined with the schema (which references list_bench_result_files for filename), provides sufficient context for a file download tool. It explains the URL generation, validity, and single-use token. Returns are covered by the output schema, so no need to detail them further.

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%, with descriptions for both parameters (filename and benchResultId). The description mentions example file types but does not add new semantic meaning beyond the schema. Baseline of 3 is appropriate as schema does the heavy lifting.

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 mints a presigned URL to download one file attached to an OctoPerf benchResult, listing example file types like trace.zip and screenshots. It distinguishes from sibling tools like download_project_file by specifying the resource is a benchResult file. The verb 'Mint a presigned URL' is specific and actionable.

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 implies the tool is for downloading bench result files but does not explicitly state when to use it over alternatives like download_project_file. It provides usage notes (validity period, single-use token) but lacks guidance on when not to use it or prerequisites.

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

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

Beyond annotations (readOnlyHint=true, destructiveHint=false), the description adds behavioral context: the operation mints a presigned URL (non-destructive read), is single-use, and time-limited. No contradiction with annotations.

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?

Three sentences: first states core purpose, second explains usage of the result, third gives a critical warning. No wasted words; all information is front-loaded and essential.

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?

With an output schema and annotations covering safety, the description sufficiently covers all necessary aspects: what it does, how to use the result, and important constraints. Complete for a tool of this complexity.

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% with descriptions for both parameters. The description adds value by stating filename is 'as returned by list_project_files' (linking to sibling tool) and that the file is typically a CSV for parameterization, providing richer context beyond the 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 explicitly states the tool 'Mint a presigned URL to download a file', specifies the resource ('OctoPerf design project'), and differentiates from siblings like 'download_bench_result_file' and 'read_project_file_lines' by mentioning 'typically a CSV used for Virtual User parameterization'.

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 explains how to use the returned URL ('fetch directly, bypassing the MCP server'), its validity ('valid for ~5 minutes'), and a critical constraint ('single-use token is consumed on the first GET'). It does not explicitly state when not to use, but provides sufficient guidance for correct invocation.

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

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

Annotations indicate readOnlyHint=false and destructiveHint=false. Description adds that enabling re-arms a destructive action and consumes credits, which is valuable behavioral context beyond annotations. No contradiction with annotations.

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?

Two sentences, front-loaded with core purpose, no wasted words. Efficient and clear.

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 one parameter and output schema mentioned ('Returns the updated ScheduledJobListing'), the description is complete. No missing critical information for a simple enable action.

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?

Only one parameter 'jobId' with schema covering 100% of description. Description does not add extra meaning beyond schema's 'OctoPerf scheduled job id to enable'. Baseline 3 is appropriate as schema does the heavy lifting.

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 verb 'Enable', the resource 'paused ScheduledJob', and the effect 'the job will fire again at its next trigger time'. It distinguishes from sibling 'disable_scheduled_job' implicitly.

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?

Explicitly states when to use (enable a paused job) and includes a warning about credit consumption and need for user confirmation. Does not mention alternatives explicitly, but context is clear.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context: it is asynchronous (returns taskId immediately), reuses persisted settings, and derives a sanitized filename. No contradiction with annotations.

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 a single dense paragraph containing all key information: async nature, reused config, return value, and follow-up steps. It is efficient with no redundant sentences, though a slight structuring (e.g., bullet points) could improve readability.

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 asynchronous workflow, configuration reuse, file naming, and required follow-up actions. It does not mention error handling or rate limits, but given the presence of an output schema (which likely covers return values) and the tool's moderate complexity, it is fairly 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?

Schema coverage is 100% with a clear description for the single parameter 'benchReportId' ('OctoPerf benchReport id to render as a PDF'). The tool description mentions the report's ExportReportConfig but does not add additional semantics or constraints for the parameter beyond the 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 the tool's purpose: 'Submit an async task to render an OctoPerf benchReport as a PDF (headless Playwright print).' The verb 'submit' and resource 'benchReport as PDF' are specific, and the mechanism 'asynchronous' distinguishes it from sibling tools that return data directly or perform other 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 a clear step-by-step workflow: returns taskId → poll get_task_result → list_bench_result_files → download_bench_result_file. It explains the tool reuses existing ExportReportConfig, so no extra configuration needed. However, it does not explicitly state when not to use this tool or mention alternative tools for similar purposes.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, establishing safe read. Description adds that it returns (request, response) together and that actionId is base64-url-encoded but the tool handles encoding, which is useful behavioral context beyond annotations.

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, front-loading key info with '[Analysis]'. Every sentence contributes value, though it could be slightly more concise. Still effectively communicates without unnecessary fluff.

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 existence of an output schema, the description appropriately omits return value details. It covers prerequisites, encoding, and the nature of the response, making it fully complete for a focused drill-down 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 coverage is 100%, so baseline is 3. Description adds meaning by specifying actionId is verbatim from BenchError.actionId and timestamp is in epoch milliseconds from BenchError.timestamp, plus clarifying encoding handling, which provides added value over the schema alone.

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 verb 'Download' and the resource 'HTTP request AND response' for one specific BenchError. It distinguishes itself from siblings like 'get_report_errors' by specifying it retrieves the full payload of a single error, not a list.

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?

Explicitly states 'Use after get_report_errors returned the per-sample error list' and mentions the goal of drilling into actual payload. Does not exclude cases or mention alternatives, but provides clear context for when to invoke this tool.

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

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

Annotations already declare readOnlyHint=true, so the agent knows it's safe. The description adds value by detailing the untruncated nature, the conditional population of fields, and the timing info. It also notes that timestamp is ignored for RECORDED_* kinds, a behavioral detail not fully captured in the schema. This goes beyond the annotations.

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 a single, well-structured paragraph. It front-loads the core action ('Fetch ONE of the four HTTP entities... UNTRUNCATED') and then adds usage context and parameter guidance. Every sentence adds value, no repetition or fluff.

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 has 5 required parameters, an output schema (exists but not shown), and is a read-only fetch operation, the description adequately covers its purpose, usage conditions, parameter selection, and response shape (only one of two fields populated). No obvious gaps remain.

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 100% (all 5 parameters have descriptions). The main description does not add significantly new parameter-level semantics beyond what the schema already provides (e.g., the `kind` enum values and `timestamp` behavior are both already in the schema). The description's added value is contextual (when to use), not parameter-specific, so baseline 3 is appropriate.

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 with a specific verb ('Fetch'), specific resource ('ONE of the four HTTP entities involved in a failed OctoPerf Virtual User validation run'), and specific behavior ('UNTRUNCATED'). It distinguishes itself from the sibling tool `get_validation_failure_detail` by noting the truncation threshold, making it easy for an AI agent to select the correct tool.

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 states when to use this tool ('when the summary returned by `get_validation_failure_detail` is truncated past 8 KB and you need the complete payload'), provides an alternative (`get_validation_failure_detail`), and guides on parameter selection (`Pick kind ∈ {RECORDED_REQUEST, RECORDED_RESPONSE, VALIDATION_REQUEST, VALIDATION_RESPONSE}`). This is complete usage guidance.

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

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

Annotations already declare readOnlyHint true and destructiveHint false, so the description doesn't need to repeat safety traits. However, it adds behavioral context by detailing the return payload (polymorphic items, configs, discriminator), helping the agent understand the data structure and how to interpret widgets.

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?

Description is a single paragraph that efficiently packs essential information with no wasted words. It front-loads the main purpose and quickly dives into details. Could be slightly more structured (e.g., bullet list for items), but overall concise for the 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?

Description is comprehensive despite existence of an output schema. It details the polymorphic items list, configs, and '@type' discriminator, providing necessary context for the agent to interpret the returned data. It also explains the tool's role as a prerequisite for get_report_*_values tools, ensuring the agent understands the workflow.

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 provides full coverage for the only parameter 'reportId' with description 'OctoPerf bench report id whose content to fetch.' The description does not add additional meaning beyond this, so baseline score of 3 is appropriate.

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?

Description starts with 'Download an OctoPerf bench report in full', clearly stating the action and resource. It details the complex structure including polymorphic items and configs, and distinguishes from sibling 'list_bench_reports_by_project' by noting it provides a one-line overview, not full details.

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?

Explicitly guides when to use this tool vs alternatives: 'For a one-line overview prefer list_bench_reports_by_project'. Also states it is 'Required upstream of every get_report_*_values tool', establishing a prerequisite relationship and informing the agent of the correct workflow.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context by listing the fields returned, including state and timestamps, and indicating terminal states. No contradictions or missing safety information.

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 succinct, with three sentences that each serve a purpose: stating the core functionality, emphasizing its role, and providing alternatives. Every sentence adds value without 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?

Given the single parameter and the presence of an output schema, the description covers all necessary information: what it does, what it returns, and when to use alternatives. It is complete for an agent to make an informed selection.

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?

There is only one parameter, `benchResultId`, and the input schema already includes a description for it. With 100% schema coverage, the description does not add further parameter details, meeting the baseline expectation.

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 specifies the verb 'Get' and the resource 'OctoPerf BenchResult' with a detailed list of returned fields. It distinguishes itself from sibling tools like `get_bench_status` and `get_bench_report`, ensuring the agent understands its unique role.

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 provides guidance on when to use this tool: 'canonical result status lookup'. It also directs to alternative tools for progress (`get_bench_status`) and aggregated metrics (`get_bench_report`), giving clear when-to and when-not-to instructions.

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

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

Describes return format (double) and termination condition (1.0 means finished), adding context beyond the readOnlyHint annotation.

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?

Extremely concise: one sentence with key info and a clarifying example, front-loaded with '[Runtime]'.

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?

Covers purpose, parameter, and return value meaning. Lacks error handling or prerequisites, but sufficient for a simple read operation.

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 already documents the single parameter fully; description restates it without adding new meaning.

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?

Clearly states the tool retrieves progress of a running OctoPerf load test as a double in [0.0, 1.0], distinguishing it from other get_* siblings.

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 '[Runtime]' prefix implies use during a running test, but no explicit when-to-use or alternatives are provided.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds context about the returned data structure (curve, reference, rmse) and the rejection behavior for non-AreaRange items, going beyond the annotations.

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 three sentences long, front-loaded with '[Analysis]', and every sentence adds value (purpose, return structure, usage context). No wasted words.

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 presence of an output schema (implied by described return structure), annotations covering safety, and the tool's focused purpose, the description provides complete context including the rejection behavior and the utility for regression detection.

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 100% description coverage for both parameters (reportId, itemId). The description does not add additional parameter details beyond what the schema provides, so baseline score of 3 is appropriate.

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 verb ('Fetch') and resource ('comparison points of an AreaRangeChartReportItem widget'), and explicitly names the chart type, distinguishing it from sibling report tools that fetch other chart types.

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 'Reject non-AreaRange items', which is a clear when-not-to-use instruction. It also highlights the tool's utility for regression detection, but does not directly compare to other get_report_* siblings.

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

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

Annotations indicate readOnlyHint=true; description adds behavioral traits like 'Reject non-Errors items' and heavy load guidance. Does not cover authorization or error handling, but sufficient given annotations.

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?

Single paragraph, front-loaded with purpose. Lists many fields that could be in output schema, but each sentence adds information. Slightly verbose but effective.

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?

Covers purpose, scoping, parameters, behavior for non-Errors items, and performance advice. With output schema present, the field listing is redundant but not detrimental. Very complete for the tool's complexity.

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%, but description adds value by explaining scoping by item filters (regionId, etc.) and benchResultId, and clarifies fromMs/toMs meaning. Improves understanding beyond raw 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 the tool downloads every BenchError for an ErrorsReportItem widget, specifying the verb (download) and resource (error entries per failed sample). It distinguishes from sibling report tools by focusing on error items.

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?

Provides clear context: scoped by item's filters and benchResultId, optional time bounds, rejection of non-Errors items, and heavy load warning. Lacks explicit when-not or named alternatives, but implied by context.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false; description adds significant behavioral context (heuristics run, output structure with ordered insights, insight components, drill-down capability). 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.

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

Single, well-structured sentence front-loaded with purpose, then details output and usage, with a clear reject instruction. No wasted words.

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 annotations and output schema existence, the description covers purpose, usage, behavior, and parameter semantics well. Minor missing info on error handling, but overall highly informative for this report 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 coverage is 100%, so description adds only marginal value (e.g., reiterating optionality of fromMs/toMs). Baseline 3 is appropriate.

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 verb (evaluate), resource (InsightsReportItem widget), and outcome (returns firing insights). It distinguishes from sibling tools like other get_report_* tools by specifying it is specifically for InsightsReportItem and mentions drill-down via matching tools.

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?

Explicit guidance: 'Reject non-Insights items' clarifies when not to use. Also suggests alternatives for drill-down ('use the matching get_report_*_values tools'). Optional parameters explained.

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

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

Annotations already declare readOnlyHint and destructiveHint, so the description adds value by describing the return format (series of GraphPoint with x/y) and noting that time-series can be hundreds of points, which implies potential data volume.

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 two concise paragraphs, front-loaded with the core purpose, followed by usage guidance and parameter notes. Every sentence adds value with no wasted words.

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 output schema exists and siblings are listed, the description covers purpose, usage, parameter hints, and return format. It lacks error/edge case details but is sufficient for a read-only tool with well-documented 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?

Schema coverage is 100%, so baseline is 3. The description adds minimal extra: it restates optionality and bounds for fromMs/toMs but does not add significant new meaning beyond the schema descriptions.

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 uses a specific verb ('Fetch') and resource ('time-series points of a LineChartReportItem or PercentilesChartReportItem widget'), and distinguishes from siblings by specifying the chart types and data format.

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?

Explicitly states when to use alternatives ('prefer get_report_table_values for action-level summaries when you don't need the temporal shape') and which tools to use for other chart types ('Reject other chart types (use get_report_stacked_chart_values or get_report_area_range_values)').

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

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

Annotations already indicate read-readOnly and non-destructive behavior. The description adds context about returning PieValues with series and PieSlice, and the rejection of non-Pie items, which is additional behavioral transparency beyond the annotations.

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?

Two concise sentences with no fluff. The first sentence states purpose with examples, and the second describes output and error condition. Every sentence earns its place.

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 simple read tool with full annotations and schema, the description is complete. It explains what it does, what it returns, and when it fails. No additional details are needed.

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% with clear descriptions for both parameters. The description does not add extra semantics to the parameters, so it meets the baseline for high 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 the tool fetches slice values of a PieChartReportItem widget, giving examples and specifying the output structure. It distinguishes from siblings by noting it rejects non-Pie items, making it specific to pie chart data.

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 implies usage by stating the tool fetches pie chart data and rejects non-Pie items, but it does not explicitly compare with alternative report tools like get_report_line_chart_values or mention when not to use it beyond non-Pie items.

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

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

Annotations already confirm readOnlyHint=true and destructiveHint=false. The description adds behavioral details: it returns StackedChartValues with point structure and rejects non-Stacked items (an error condition). This is valuable context beyond the annotations.

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 concise: two sentences with no filler. It is front-loaded with '[Analysis]' to quickly signal the domain. Every sentence adds essential information about purpose, examples, return type, and constraints.

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 that an output schema exists, the description adequately explains the return format (points with x and values map) and constraints (reject non-Stacked). It does not miss any critical information needed for correct invocation and interpretation.

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 both required parameters (reportId, itemId) are described in the input schema. The description does not add any additional parameter semantics or usage details beyond what the schema provides, so the baseline score of 3 applies.

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 fetches stacked chart values for StackedChartReportItem widgets, with examples like hits/s split by response status. It explicitly distinguishes itself by rejecting non-Stacked items, making the purpose unmistakable among the many get_report_* sibling tools.

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 implies usage context (only for stacked chart items) and warns against non-Stacked items. It does not explicitly name alternative tools for other chart types, but the sibling list includes many get_report_* variants, making the differentiation clear enough for an agent.

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

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

Annotations already show readOnlyHint=true. Description adds context: return structure (SummaryValues aligned with metrics order, zip by index with item.metrics[i].id), optional time bounds. Does not contradict annotations. Could mention if any rate limits or auth, but fine.

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?

Single paragraph, front-loaded with purpose. Clear and concise, though could be slightly more structured (e.g., bullet points). No wasted sentences.

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?

Complete given complexity: explains parameter usage, item type constraints, output structure (aligned with metrics). Output schema exists, description adds complementary context. No gaps.

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%, baseline 3. Description adds meaning: explains fromMs/toMs optional and their effect, and that itemId must be of specific types. Exceeds baseline.

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?

Description clearly states it fetches aggregated metric values for SummaryReportItem or BarChartReportItem (both MultiMetricReportItem shapes). It explicitly distinguishes from sibling tools by rejecting other item types and directing to alternatives like get_report_table_values or get_report_top_values.

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?

Provides explicit when-to-use: only for summary/bar chart items. Tells when to omit fromMs/toMs (to scan whole test). Offers clear alternatives for other item types, making usage guidance complete.

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

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

Annotations already indicate read-only and non-destructive behavior. The description adds value by detailing the return structure (TableValues with entries binding actionId to values in metric order) and the relationship to the source widget's metrics.

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?

Two sentences efficiently convey purpose, behavior, and alternative tool. Front-loaded with the core action and resource, no superfluous words.

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 read-only tool with output schema present, the description covers purpose, usage guidance, and behavioral details adequately. It is complete for agent decision-making.

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% with both parameters described. The description does not add significant additional meaning beyond the schema, maintaining the baseline score of 3.

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 fetches aggregated metric values for a StatisticTableReportItem widget, specifying the exact resource and action. It distinguishes from sibling get_report_tree_values by noting that tool is for per-VU breakdown.

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?

Explicitly states when to use this tool (flat table rows) and when to use the alternative get_report_tree_values for per-VU breakdown, providing clear usage context.

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

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

Annotations already indicate read-only and non-destructive behavior. The description adds details about fetching data under a specific widget and rejecting other types, enhancing transparency beyond annotations.

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?

Two-sentence description is concise and front-loaded. Every sentence provides value: first states purpose and return data, second clarifies rejection behavior.

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 presence of an output schema and annotations covering safety, the description sufficiently explains the tool's behavior and return values for a read-only data retrieval 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 coverage is 100%, so the baseline is 3. The description does not add significant new parameter semantics; it mentions `TextualMonitorReportItem` which relates to `itemId`, but the schema already describes both parameters adequately.

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 fetches `TextualCounterValue` under a `TextualMonitorReportItem` widget, specifies the return fields, and mentions rejection of other item types. It distinguishes itself from sibling report tools by focusing on this specific data type.

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 explains the tool's purpose well, implying when to use it (for textual monitor data). It lacks explicit exclusions or alternatives, but the sibling list provides differentiation.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds useful behavioral details: it fetches every alarm, lists return fields, and notes optional epoch-millis bounds. No contradiction. Slightly lacks mention of pagination or limits, but for a read-only tool this is sufficient.

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?

Two sentences: first states purpose and return fields, second gives usage context. Front-loaded with key info, no fluff or redundancy. Every sentence earns its place.

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 presence of an output schema (per context signals), the description provides sufficient context: it details return fields, optional parameters, and the trigger condition (alarm from get_report_insights). Covers all necessary aspects for an agent to select and invoke the tool 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 coverage is 100% with descriptions for all parameters. The description adds value by explaining that fromMs/toMs are optional epoch-millis bounds and that omitting them scans the whole test, which is beyond the schema's literal 'Upper bound' and 'Lower bound' phrasing.

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 fetches ThresholdAlarms for a ThresholdAlarmReportItem, listing specific fields (id, monitorConnectionId, severity, etc.). It distinguishes from siblings by referencing get_report_insights which surfaces the alarm id, and uses the verb 'fetch' with the resource 'ThresholdAlarm'.

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?

Explicit context: use when a ThresholdAlarmReportItem fired during a run, typically surfaced in get_report_insights under the THRESHOLD_ALARM id. Also explains optional bounds (fromMs/toMs) can be omitted. Lacks explicit when-not-to-use or alternative tools, but context is strong.

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

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

Annotations already indicate read-only behavior. The description adds the return structure (TopResult with top and curves) and the validation behavior (reject non-Top items). This is sufficient context, though it could mention error handling for missing reports.

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—two sentences with a front-loaded verb. No redundant words. Every sentence adds essential information.

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 parameter count, required fields, and existence of an output schema, the description completely covers what the tool does, its return structure, and its validation. It is sufficient for correct selection and invocation.

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%, but the description adds meaning beyond schema: it clarifies that fromMs/toMs are optional and that omitting them scans the whole test. It also reinforces the itemId constraint. This adds value.

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 verb ('Fetch'), the resource ('TopReportItem widget'), and the purpose (top-N actions by criterion). It distinguishes from sibling tools by specifying the widget type, which is unique among get_report_* tools.

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 'Reject non-Top items,' guiding the agent to use this tool only for TopReportItem widgets. It also explains optional time bounds. However, it does not explicitly mention when not to use other similar tools.

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