add_response_assertion

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states that the tool fails the sample when the response doesn't match, which is the primary side effect. However, it does not mention constraints (e.g., parent must be an HTTP sampler), error conditions, or any side effects on existing assertions. The core behavior is clear but details are missing.

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

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

The description is a single, front-loaded sentence that states the action and purpose without unnecessary words. It is concise and efficient, scoring well for conciseness, though it could be expanded slightly with parameter guidance without becoming 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?

For a tool with 7 parameters, no output schema, and low schema description coverage, the description is inadequate. It doesn't explain the required parameters (planId, parentId, patterns) or optional ones (matchType, testField, name, not), nor does it describe the return behavior. An agent would need to infer too much from the schema alone, making the description incomplete.

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 only 14% (only 'not' has a description), so the description must compensate. It does not explain planId, parentId, patterns, matchType, testField, or name. The phrase 'if the response doesn't match' implies patterns are used for matching but offers no parameter semantics. The agent is left to guess from property names and enums, which is insufficient.

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: adding a Response Assertion under an HTTP sampler, with the purpose of failing the sample on mismatch. This is specific and distinguishes it from sibling add_* tools (e.g., add_http_sampler, add_json_extractor) by naming the resource and behavior. However, it doesn't explicitly contrast with alternatives, so a 4 is appropriate.

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 others, nor any conditions where it should not be used. It only states what the tool does without context on selection. No exclusions or alternatives are mentioned, leaving the agent to infer appropriateness from the name alone.

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