Skip to main content
Glama
gpact

bruno-mcp

by gpact
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Run Bruno requests

bruno_run

Executes Bruno collections, folders, or requests using the Bruno CLI, returning structured results for tests and assertions. Run API checks from your workspace.

Instructions

Execute requests, folders, or an entire Bruno collection using Bruno CLI v4. Returns structured execution results. Do not pass credentials or other secrets through variables. MCP tool arguments may be visible to the model and host.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bailNoStop after the first failing request, test, or assertion.
delayMsNoDelay between requests in milliseconds.
sandboxNoJavaScript sandbox mode (safe or developer).safe
targetsNoRequest files or folders relative to collection root, or empty array for entire collection.
insecureNoDisable normal TLS certificate verification.
testsOnlyNoOnly run requests containing tests or active assertions.
variablesNoNon-secret environment variable overrides.
collectionYesCollection path relative to workspace root (as returned by bruno_list_collections).
environmentNoBruno environment name to use for this run.
responseBodyModeNoWhen to return response bodies: none, onFailure, or full.onFailure
maxResponseBodyBytesNoMaximum bytes for each returned response body.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv0.2.0
    • changedInput schema / properties / collection / description
      Previous value: -"Collection identifier: the collection's path relative to the workspace root (as returned by bruno_list_collections), not its display name."New value: +"Collection path relative to workspace root (as returned by bruno_list_collections)."
    • changedInput schema / properties / insecure / description
      Previous value: -"Disable normal TLS certificate verification. Must be enabled by server policy."New value: +"Disable normal TLS certificate verification."
    • changedInput schema / properties / maxResponseBodyBytes / description
      Previous value: -"Maximum serialized UTF-8 size of each returned response body. Oversized bodies are replaced by size metadata."New value: +"Maximum bytes for each returned response body."
    • changedInput schema / properties / responseBodyMode / description
      Previous value: -"Response bodies to return in the MCP payload: none, only results with failed tests or assertions, or all results."New value: +"When to return response bodies: none, onFailure, or full."
    • changedInput schema / properties / sandbox / description
      Previous value: -"JavaScript sandbox mode. Developer mode must be enabled by server policy."New value: +"JavaScript sandbox mode (safe or developer)."
    • changedInput schema / properties / targets / description
      Previous value: -"Request files or folders relative to the collection root. An empty list runs the entire collection."New value: +"Request files or folders relative to collection root, or empty array for entire collection."
    • changedInput schema / properties / variables / description
      Previous value: -"Non-secret environment variable overrides. Do not include credentials or other secrets."New value: +"Non-secret environment variable overrides."
  2. First observedv0.1.0

TDQS

A3.6/5.0
Behavior3/5

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

With no annotations, the description carries the full 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.

Conciseness5/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.

Deploy Server

Other Tools