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

With no annotations, the description carries the full burden. It does disclose a meaningful behavioral trait — secret values are not returned — which is useful data-safety context. However, it does not confirm the operation is read-only, mention side effects, error behavior, or traversal limits.

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, zero filler, with the return payload front-loaded before the secret-value caveat. Nothing that could be cut.

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?

No output schema exists, so the description correctly spells out the return shape (sibling directory, environment names, variable names) and the secret-value exclusion. It is nearly complete for a single-parameter read tool; only the read-only/no-side-effect confirmation is 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?

Single parameter with 100% schema description coverage, so the schema already documents the collection path and the sibling-environments lookup. The description restates the directory behavior but adds no format or syntax detail beyond the schema. Baseline 3 for full 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?

States a specific verb (inspect) and resource (folder structure around a Bruno collection) and enumerates the return payload: environments directory, environment names, variable names. Sibling differentiation is not explicit, but the resource is distinct from list-collections/run-collection.

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 on when to reach for this tool versus siblings like list-collections or run-collection. The purpose implies a discovery step before a run, but nothing states it, and there are no exclusions 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?

No annotations are provided, so the description carries the full burden. 'List' does imply a read-only, non-destructive operation, which is useful, but the description says nothing about recursion depth, result size, or behavior when the root is missing or invalid, and the root-resolution note duplicates the schema.

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 the capability front-loaded and the usage trigger second; there is no filler. The second sentence is slightly elliptical ('instead of a full path' relative to what?), which keeps it from a 5.

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 no output schema and no annotations, the agent gets no sense of the return shape (collection objects, paths, counts) or failure modes. For a zero-required-parameter list tool this is adequate but leaves real 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% with examples for both optional parameters, so the baseline is 3. The phrase 'below a root directory or configured roots' loosely mirrors the root parameter and 'partial collection name' gestures at query, but adds no syntax or matching rules 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?

States a specific verb and resource ('List Bruno collections') plus scope ('below a root directory or configured roots'), which is clearly distinct from siblings like list-request-filters and discover-environments. It does not name any sibling explicitly, so it stops short of a 5.

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

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

Gives an explicit usage trigger: 'Use this when the user gives a partial collection name instead of a full path.' That tells the agent the discovery scenario this tool serves, but there are no when-not conditions and no named alternatives for the full-path case.

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 burden but does disclose a meaningful behavioral trait: 'Secret values are not returned', which tells the agent about output sanitization. It does not state that this is a read-only inspection (only implied), nor mention error behavior for invalid/unreadable collection paths.

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 zero filler; the core action and return payload are front-loaded, and the security caveat is a brief, worthwhile addition.

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 single-parameter, read-only inspection tool with no output schema, the description covers what is inspected and what is returned (enabled/disabled params, secrets withheld). It would be marginally stronger if it clarified the read-only nature and behavior on a missing or malformed collection.

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% with a single parameter, so the schema already documents the collection path argument fully, including examples and length constraints. The description adds no additional semantics about the path or parsing behavior, 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 pairs a specific verb ('Inspect') with a precise resource ('OpenCollection YAML requests') and states exactly what is returned: enabled and disabled query params usable as filter scenarios. This distinguishes it from siblings like list-collections and run-filter-scenarios without ambiguity.

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 phrase 'can be used as filter scenarios' implies this tool feeds a downstream workflow (likely run-filter-scenarios), which hints at when to use it. However, there is no explicit when-to-use statement, no prerequisites, and no named alternative for cases where you want to list collections versus request filters.

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 disclose two meaningful traits: output is 'bounded' and 'redacted', which tells the agent results are truncated/sampled and sanitized. However, it omits error behavior for bad paths, permission needs, and what the summary actually contains beyond the redaction/bounding note.

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, zero waste, and the purpose is front-loaded ahead of the usage condition. Nothing is redundant or padded.

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 two-parameter read tool with no output schema or annotations, the description covers purpose, provenance of the path, and the sampling/redaction behavior, which is enough to invoke it correctly. It could say slightly more about the summary's contents or failure modes, but nothing essential is 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 description coverage is 100%, so both the 'path' and 'max_items' semantics (default 3, max 20) are already documented in the schema. The description only restates that the path comes from run-collection or run-filter-scenarios, adding minimal meaning over the schema. Baseline 3 applies when the 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?

States a specific verb ('Read') and resource ('Bruno result artifact'), and scopes it precisely as a 'bounded, redacted summary' from a path produced by run-collection or run-filter-scenarios. This clearly separates it from the sibling run-* and list-* tools, which produce rather than consume artifacts.

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 an explicit trigger condition: 'Use this when response data is too large to include directly in a tool result.' It also identifies the upstream tools that supply the path. It stops short of stating when NOT to use it (e.g., prefer direct output when data is small), so it is clear context without full 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, the description carries the full burden and does well: it discloses the security mechanism (secrets read from the MCP server process, injected via a temporary private --env-file, never through CLI arguments) and the workspace-root path restriction. It does not state side effects of actually executing requests (real network calls to target systems, possible mutation, timeouts, or failure semantics), which is a notable gap 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?

Front-loaded with the action and return shape, followed by parameter and safety guidance. Four dense sentences with little waste, though the phrasing is tightly packed and could be marginally trimmed.

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

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

For a 4-param execution tool with no output schema or annotations, the description covers what the tool does, its return shape, secret handling, and path constraints. It omits runtime behavior such as failure/timeout handling and whether execution is destructive to the target system, which leaves a small but real 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?

Schema description coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining the secret-handling protocol for `inherited_variables` and the workspace-root constraint on `collection`, which the schema does not convey.

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

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

States a specific verb and resource ('Run a Bruno collection with the local `bru` CLI') plus the return shape ('normalized JSON with success, request summary, per-request details, failures, and execution timings'). An agent can distinguish it from the sibling run-filter-scenarios / run-full-validation tools by the explicit reference to running a whole collection.

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 conditional guidance: pass KEY=value variables normally, but for secrets pass only names via `inherited_variables`, and collection paths must stay inside configured workspace roots. It stops short of naming alternative tools (e.g. run-filter-scenarios) or stating when not to use this one, so it is context-rich but not a full routing guide.

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, and it does well: it discloses that each request also runs a baseline, that infrastructure failures are reported as inconclusive rather than defects, and that source collection files are not modified. Missing details on auth requirements and whether requests hit live endpoints (side effects) keep it from a 5.

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 tight sentences, front-loaded with the core action and followed by the baseline rationale, failure semantics, and the non-mutation guarantee. No 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?

With no output schema, the description could say more about the shape of the returned results (per-scenario status, baseline comparison fields), but it covers the key behavioral and side-effect questions an agent needs before invoking a multi-request execution tool.

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

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

Schema description coverage is 100%, so the schema already documents every parameter; baseline is 3. The description adds conceptual context about disabled query params and baseline runs but no syntax or formatting detail 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?

States a specific verb and resource ('Run temporary Bruno request variants with selected disabled query params enabled') plus the validation goal, which cleanly separates it from siblings like run-collection and run-full-validation. An agent can tell this is the filter-scenario verifier without opening 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 description sets up the use case clearly: run filter variants to distinguish an ignored filter (identical to baseline) from one that legitimately returns zero matches. It does not explicitly say when NOT to use this or name run-collection/run-full-validation as alternatives, but the context is unambiguous.

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 burden and discloses several important traits: Phase 2 is conditional on Phase 1 passing, filters are tested in temporary request copies without modifying source files, baseline comparisons distinguish ignored filters from zero-match results, and infrastructure failures are marked inconclusive. It stops short of covering authentication requirements, external side effects of running the collection, or rate limits.

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 four tightly written sentences with the core concept ('Two-phase validation') front-loaded. Every sentence contributes necessary detail about phases, behavior, and return values, with no filler or repetition.

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

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

For a complex, five-parameter tool with no annotations and no output schema, the description provides substantial context: it explains both phases, the conditional execution, the temporary-copy approach, baseline comparison logic, inconclusive handling, and the shape of the consolidated result. It leaves some prerequisites and external side-effect details unspecified, but is complete enough for correct 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 description coverage is 100%, so the input schema already documents all five parameters in detail. The description adds no parameter-specific syntax, format, or constraint information beyond what the schema provides, which makes the baseline score of 3 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 states a specific verb and resource: 'Two-phase validation' of a Bruno collection, with Phase 1 checking endpoint reachability and Phase 2 testing disabled query filters. It clearly distinguishes this tool's combined scope from siblings like run-collection or run-filter-scenarios, which cover only one phase each.

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 through its two-phase explanation and the condition that Phase 2 only runs if Phase 1 passes. However, it never explicitly says when to choose this tool over alternatives such as run-collection or run-filter-scenarios, nor does it state any exclusions or prerequisites. Guidance is inferred rather than stated.

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