mcp-bruno
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| run-collectionA | Run a Bruno collection with the local |
| list-collectionsA | List Bruno collections below a root directory or configured roots. Use this when the user gives a partial collection name instead of a full path. |
| discover-environmentsB | Inspect the folder structure around a Bruno collection and return the sibling environments directory, available environment names, and variable names. Secret values are not returned. |
| list-request-filtersA | Inspect OpenCollection YAML requests and return enabled and disabled query params that can be used as filter scenarios. Secret values are not returned. |
| run-filter-scenariosA | Run temporary Bruno request variants with selected disabled query params enabled, then validate HTTP status and response payload consistency. Each request is also run once without filters (baseline) to distinguish an ignored filter (response identical to baseline) from a filter that legitimately returns zero matches. Infrastructure failures (auth, routing, timeout, connectivity) are reported as inconclusive, never as filter defects. Source collection files are not modified. |
| read-result-artifactA | Read a bounded, redacted summary from a raw Bruno JSON artifact path returned by run-collection or run-filter-scenarios. Use this when response data is too large to include directly in a tool result. |
| run-full-validationA | Two-phase validation. Phase 1 runs the collection once and checks every endpoint is reachable (HTTP status, no request errors). Phase 2 only runs if phase 1 passes: it tests every documented disabled query filter across every endpoint in temporary request copies, without modifying source files. Each scenario is compared against an unfiltered baseline to distinguish ignored filters from legitimate zero-match results, and infrastructure failures are marked inconclusive instead of failed. Returns a consolidated result stating which phase ran, per-endpoint baseline status, and per-endpoint per-filter pass/fail/skip with the reason. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 7 tools
Tools have distinct primary purposes (listing, running, discovering, reading, validating). However, run-filter-scenarios and run-full-validation overlap in testing disabled query filters, requiring careful reading to choose between targeted filter testing and comprehensive two-phase validation.
All tool names follow a consistent lowercase hyphen-separated verb_noun pattern (list-, run-, discover-, read-), with no mixed casing or verb styles.
Seven tools is well-scoped for a Bruno collection runner/validator; each tool covers a distinct stage (discovery, execution, filtering, validation, artifact reading) without bloat.
The surface covers discovery, execution, filter validation, and artifact reading, which are the core lifecycle for running and validating collections. Minor gaps exist (e.g., no dedicated single-request execution or collection editing), but agents can work around them via run-collection and filter scenarios.