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

With no annotations provided, the description carries the behavioral disclosure burden. It does add a meaningful constraint: 'Secret values must be omitted or [REDACTED].' However, it does not disclose behavior around overwriting existing files, permission requirements, or what happens after creation. This is a mutation tool, so more detail would be valuable.

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 short sentences: one states the primary action, the other communicates the one critical rule. There is no filler or repetition of schema details. The structure is appropriately concise and 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?

The schema covers all parameters and the description highlights the key secret-handling rule, so an agent can likely call the tool correctly. However, there is no output schema and the description does not mention what the tool returns, whether it will overwrite an existing environment at the same path, or any side effects. For a file-creating mutation tool, these are notable 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 description coverage is 100%, so the schema fully documents all three parameters. The description adds the security rule about secrets, but this mostly restates what the schema already specifies via the '[REDACTED]' const and corresponding descriptions. Thus the description provides minimal added value 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 action: 'Create a new Bruno environment file.' This is specific and unambiguous, naming both the verb and the resource. It distinguishes this tool from siblings like bruno_update_environment and bruno_get_environment simply by emphasizing 'new'.

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 establishes when to use the tool: when creating a new environment, not updating or listing existing ones. It does not explicitly name alternatives, but the 'new' qualifier makes the intended use clear enough. It stops short of explaining what not to use it for, so it lacks explicit exclusion 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?

With no annotations provided, the description carries the behavioral burden. It does disclose two non-obvious file behaviors: missing parent folders are auto-created and existing files are not overwritten. But it omits what happens when a file already exists (error vs no-op), what the successful response contains, and any other side effects beyond file creation.

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 one front-loaded sentence that conveys the essential action plus two important edge-case behaviors with no filler. Every clause 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 17-parameter mutation tool with no output schema and no annotations, the description is not fully complete: it lacks success/error signaling, what happens on an existing-file conflict, and explicit routing to bruno_update_request. The schema compensates for parameter details, and the description covers the most important file-system behaviors, so it is adequate but has clear 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 description coverage is high at 88%, so the schema already documents most parameters and the baseline is 3. The description adds extra meaning by clarifying request-path behavior: nested parent folders are automatically created and an existing target file is not overwritten, which is not stated in the schema's parameter 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 names a concrete action ('Create') and a concrete resource ('Bruno HTTP request YAML file'), so an agent immediately knows what the tool does. The phrase 'existing files are not overwritten' also distinguishes it from bruno_update_request, which is the main sibling it could be confused with.

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 'create' verb and the warning that existing files are not overwritten imply this tool is for new request files, giving some usage context. However, it never explicitly says to use bruno_update_request when the target already exists, nor does it state any other when-to-use/when-not-to-use guidance relative to 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 discloses one important behavior: secret variables are always redacted in the output. However, it does not explicitly state that the operation is read-only, nor does it mention potential errors or permission requirements. Since no annotations are provided, the description carries the burden of behavior disclosure, but it only partially fulfills this.

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 sentence that leads with the core purpose and then adds a crucial detail about secret redaction. It is concise, free of filler, and well-structured; every word contributes to the tool's understanding.

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 get operation with two well-documented parameters, the description provides sufficient context: it names the action, the resource, and a key output behavior (redaction). It does not explicitly state the return format, but 'inspect' implies retrieving the environment's details, and the absence of an output schema makes this a minor gap.

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 provides full descriptions for both parameters (collection and environment), so the baseline is 3. The description adds no additional parameter-level semantics beyond what the schema already states, making this a neutral score.

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 ('Inspect') and the resource ('a Bruno environment'), which distinguishes it from create/update/delete operations. It does not explicitly contrast with bruno_list_environments, but 'inspect' implies fetching details of a specific environment, making the purpose reasonably clear.

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 does not provide explicit guidance on when to use this tool versus alternatives. It does not mention that this is for retrieving a single environment's details as opposed to listing environments or running requests, leaving the selection decision to the agent's interpretation.

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?

No annotations are provided, so the description carries the full behavioral burden. It does convey that the operation is a read and that 'full' returns parsed content while 'revision' performs a revision check, which gives some behavioral insight. However, it does not describe the exact response shape, error behavior, or explicitly confirm that no side effects occur.

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 short sentences with the core operation front-loaded and mode guidance immediately following. Every phrase earns its place, and there is no redundancy or filler.

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 schema covers parameter semantics well, but with no annotations and no output schema, the description should more clearly explain return behavior and how this tool relates to sibling tools. It sketches the difference between revision and full modes but leaves the exact response and tool-selection context to inference. This is adequate but has clear 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?

All four parameters already have descriptive comments in the input schema, so the baseline is 3. The description's mode sentence mostly restates the responseMode schema, though 'parsed content' adds a small nuance. It adds no meaningful detail for collection, request, or includeSource 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 operation: 'Read a Bruno request.' The mention of responseMode further clarifies that the tool supports both full content retrieval and revision checks, which is specific and useful. It is distinguishable from create/update/run siblings, though it does not explicitly contrast with list/search 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 provides guidance for choosing between responseMode values, but it says nothing about when to use this tool instead of bruno_list_requests, bruno_search_requests, or bruno_run. No alternatives or exclusion conditions are mentioned, so an agent must infer the tool's appropriate context from its name alone.

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?

No annotations are provided, so the description carries the full behavioral disclosure burden. It only restates the listing action and does not mention read-only behavior, return format, ordering, pagination, or potential side effects.

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?

A single, front-loaded sentence that states the essential purpose with no filler or repetition. It is appropriately sized for such a simple tool.

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 zero-parameter listing tool, the description is functionally sufficient: the agent knows what the tool does and that it operates on workspace collections. The only minor gap is the lack of explicit return-shape details, but no output schema exists and the tool is simple enough to infer a list of collections.

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 tool has zero parameters, so there is no parameter semantics burden. The description does not need to explain inputs, and the empty input schema is trivially complete.

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

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

The description states a specific action ('List') and resource ('Bruno collections') with a clear workspace scope. It is unambiguous, though it does not explicitly contrast with sibling listing tools such as bruno_list_requests or bruno_list_environments.

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?

There is no guidance about when to use this tool versus alternatives. The agent must infer from the resource name that this is for collections, with no explicit exclusions or context for choosing among the sibling list 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?

With no annotations, the description carries the burden of behavioral disclosure. It explicitly promises that variable values are not exposed, which is a meaningful safety/security behavior. It does not describe error handling or return format, but for a simple listing operation this is a solid level of transparency.

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

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

The description is a single sentence with no filler. It front-loads the core purpose ('List environments...') and immediately adds the key differentiator ('without exposing variable values'). Every word 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 low-complexity tool with one required parameter and no output schema, the description is largely sufficient. It covers purpose, scope, and the security-relevant behavior. It could be more complete by stating the return shape more explicitly, but the core selection and invocation needs are met.

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 has 100% coverage with a clear parameter description: 'Collection path relative to workspace root (as returned by bruno_list_collections).' The tool description adds no parameter details itself, but the schema already provides sufficient meaning, so the baseline 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 states a specific verb and resource ('List environments') and adds the scope 'available to a Bruno collection'. It also includes a distinctive qualifier, 'without exposing variable values', which differentiates it from a tool like bruno_get_environment that would return variable 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?

The description clearly scopes the tool to listing environments for a collection and points to bruno_list_collections as the source of the collection path. It does not explicitly name alternatives or say when not to use it, but the 'without exposing variable values' phrasing gives helpful context for choosing between this and a more detailed environment 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?

With no annotations, the description carries the burden of explaining behavior. It does disclose that the tool returns request paths, names, types, and HTTP metadata, but it does not mention error behavior, pagination, or whether the operation is strictly read-only. The read-only nature is implied by 'list and search' but not explicit.

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 compact and front-loaded: it states the core action and return contents in two short sentences with no filler. Every phrase contributes meaningful 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?

The description covers the main inputs and return fields, but with no output schema and no annotations, it is only minimally complete. The lack of any distinction from bruno_search_requests is a notable gap for an agent deciding which tool to invoke.

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

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

Input schema coverage is 100%, so all parameters already have descriptions. The tool description adds no extra parameter-level semantics beyond confirming the collection context, which the schema already provides. 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 operation: listing and searching requests in a Bruno collection, and it lists what is returned. However, it does not differentiate itself from the sibling tool bruno_search_requests, whose name suggests overlapping search functionality.

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?

No guidance is given about when to use this tool instead of bruno_search_requests or bruno_get_request. The description implies it is for exploring requests but never states exclusions or alternative selection criteria, leaving the agent to guess.

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?

With no annotations, the description carries the full behavioral disclosure burden. It does provide useful warnings about not passing secrets and MCP argument visibility, and it mentions structured results. However, it does not disclose that executing requests may perform live network calls, cause side effects, or take a long time, which are significant behavioral traits for an execution tool.

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

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

The description is three concise sentences that front-load the core action, then state the return type, then add a critical security warning. There is no filler or redundant wording, and 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?

Despite having 11 parameters and no output schema or annotations, the description stays very brief. It does not explain the structure of the execution results, warn about side effects, or provide guidance on selecting targets or interpreting failures. For such a complex, potentially side-effectful tool, the description is insufficiently complete on its own.

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 the parameters are already well-documented in the schema. The description adds a security warning about variables, reinforcing but not extending the schema's note that variables are non-secret overrides. It provides no additional semantic value for the other ten parameters, so the 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 uses the specific verb 'Execute' and clearly identifies the resource: 'requests, folders, or an entire Bruno collection' via 'Bruno CLI v4'. It also states the result type ('structured execution results'), making the tool's purpose unambiguous and easily distinguishable from the listing/getting/creating 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 implies this tool is for running Bruno requests rather than managing them, but it does not explicitly state when to choose it over alternatives or when not to use it. There is no mention of sibling tools like bruno_list_collections or bruno_get_request, leaving usage context to inference. It is adequate but not 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?

No annotations are provided, so the description carries the full burden of disclosing side effects and behavior. It mentions it returns matching requests, implying a read-only operation, but does not explicitly state that it does not modify data or that it is safe to call. The transparency is moderate but not thorough.

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

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

The description is two sentences, direct, and free of unnecessary detail. It efficiently conveys the tool's purpose and a key aspect of the output, with no fluff or 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?

The description provides the essential information needed to invoke the tool: that it searches across all collections and returns matching requests with collection id. Even though there is no output schema, the mention of the return content satisfies basic completeness. It lacks details on pagination or filtering specifics, but these are minor for a search tool.

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

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

The schema already provides descriptions for all three parameters: query, type, and method. The tool description does not add any extra context about how these parameters interact or affect the search, so the value added beyond the schema is minimal. 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 searches for requests across all collections, using the specific verb 'search' and resource 'requests'. It also mentions it returns matching requests with collection id, which distinguishes it from simply listing requests. However, it does not explicitly contrast with the sibling tool bruno_list_requests, so it stops short of a perfect 5.

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

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

The description says what the tool does but does not explicitly state when to use it over alternatives (e.g., bruno_list_requests or bruno_get_request). There is no guidance about using search when a filter is needed versus listing when a full enumeration is required, leaving the agent to infer usage.

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?

With no annotations, the description must carry the full behavioral disclosure burden. It does disclose one important constraint (preserving secrets with secret: true), but it omits that variables form a replacement list, whether unspecified variables are removed, and what the operation returns. This is a significant gap for a mutating tool.

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

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

Two short sentences with no redundancy. The primary purpose is stated first, and the critical secret-preservation constraint is added immediately without unnecessary detail.

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 mutating tool with no annotations and no output schema, the description is too thin. It does not explain the replacement semantics, the effect on omitted variables, or the expected return value. The secret warning is helpful but leaves important operational context uncovered.

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 the schema already documents all parameters. The description's secret-preservation note adds emphasis but largely duplicates the schema's 'Existing secrets must keep secret: true.' 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 action ('Update') and the resource ('an existing Bruno environment file'), which distinguishes it from environment creation tools. It does not explicitly name sibling alternatives, so it stops short of full differentiation.

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?

'Existing' implies this tool is for modifying an already-created environment rather than creating one, providing weak usage context. However, it does not explicitly state when to use this tool over bruno_create_environment, bruno_get_environment, or other 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?

With no annotations, the description carries the burden of behavioral disclosure. It does reveal the partial-update nature and the preflight bypass behavior. However, it does not state side effects like persistence, what happens on a revision mismatch, or what the response contains, so it is adequate but not comprehensive.

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 tight sentences with no filler: the core patch behavior is front-loaded, and the operational revision tip follows immediately. The description avoids repeating parameter-level schema details.

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 an 18-parameter mutation tool with no annotations and no output schema, the description plus the rich schema provides enough to select and invoke the tool correctly: patch an existing request, preserve untouched content, and optionally bypass preflight. Missing details like return shape and conflict behavior are minor but would make it more complete.

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

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

The schema already documents most parameter meanings in detail. The description adds the cross-cutting patch semantics that omitted content is preserved, which is essential for constructing correct patches. The expectedRevision wildcard tip mostly reinforces existing schema text, so this is above baseline but not exceptional.

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?

Uses a specific verb ('Patch'), a clear resource ('existing Bruno HTTP request'), and the critical scope 'preserving untouched content'. This unmistakably distinguishes it from bruno_create_request and from read/run siblings without needing the schema.

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 usage is implied: this is for modifying an existing request, not creating one. However, it never explicitly names alternatives such as bruno_create_request or advises calling bruno_get_request first to fetch a revision. The expectedRevision='*' tip is a useful operational detail but not a full when-to-use vs. when-not-to-use guideline.

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