What can you do with this server?

The Bruno MCP server provides read-only access to Bruno API collections, allowing you to discover, search, and inspect endpoint contracts without executing requests. * List collections and browse their folder hierarchy with pagination, subtree filtering, and depth control. * List and filter endpoints by HTTP method, request type (HTTP, GraphQL, gRPC, WebSocket), folder, path prefix, or tags. * Search endpoints with field-aware ranked text search, returning scores and matched fields; supports general, contract, and documentation modes with tag/method/folder filters. * Retrieve complete sanitized endpoint contracts individually by stable ID or method+path, or batch up to 25 by stable IDs. Contracts include method, URL, auth, body, docs, tests, but sensitive values are omitted. * Get saved response examples (status, content type, body) separately. * Check index status for generation time, endpoint count, and parser warnings. Additional features: automatic indexing of .bru and OpenCollection YAML files, mixed-format collections, gradual migrations, persistent indexes with fingerprints, and background reindexing.

Which integrations are available for this server?

Provides tools for indexing, searching, and retrieving HTTP, GraphQL, gRPC, and WebSocket API requests from Bruno collections, enabling endpoint discovery and contract inspection without executing requests.

How do I use bruno-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@bruno-mcp search endpoints for 'payment'" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

bruno-mcp

by TheDMPV

Overview Schema Related Servers Score Discussions

TypeScript

Local

Bruno MCP

A read-only Model Context Protocol server and indexer for Bruno API collections.

Bruno MCP discovers classic .bru and OpenCollection YAML (.yml/.yaml) request files, parses them with Bruno's official filestore package, builds a sanitized AI-oriented index, and gives MCP clients deterministic tools for endpoint discovery. It never sends API requests.

Status: early 0.x release. The index schema may evolve before 1.0.

Features

Automatic recursive discovery of .bru and OpenCollection YAML requests
Mixed-format collection support during gradual migrations
Official Bruno parser via @usebruno/filestore
HTTP, GraphQL, gRPC, and WebSocket request indexing
Sanitized contracts that omit header, parameter, and auth values
Explainable, field-aware search with scores and matched fields
Explicit and folder-derived tags
Versioned persistent JSON index with source fingerprints
Automatic loading of fresh docs/api-index.json or .bruno-mcp/api-index.json
Paginated folder hierarchy with subtree/depth filtering
Batch contract retrieval by stable endpoint IDs
Complete saved response examples without extra source parsing
Automatic reindexing while the MCP server is running
MCP 2026-07-28 support with automatic fallback for 2025-era clients
A reusable TypeScript API

Related MCP server: Bruno MCP Server

Requirements

Node.js 20.11 or newer
A Bruno collection directory with bruno.json, opencollection.yml, or request files in either supported format

Quick start

Run the MCP server against a collection:

npx -y @dmpv/bruno-mcp serve ./path/to/collection

Generate a persistent index:

npx -y @dmpv/bruno-mcp index ./path/to/collection \
  --output ./generated/api-index.json

Inspect a collection without writing files:

npx -y @dmpv/bruno-mcp inspect ./path/to/collection

MCP client configuration

Example configuration for clients that support local stdio servers:

{
  "mcpServers": {
    "bruno": {
      "command": "npx",
      "args": [
        "-y",
        "@dmpv/bruno-mcp@0.6.0",
        "serve",
        "/absolute/path/to/bruno-collection"
      ]
    }
  }
}

The stdio server automatically negotiates MCP 2026-07-28 with modern clients and continues to serve clients that use the 2025 initialization handshake.

Pin a version in team configuration. During local development, replace the package command with node /absolute/path/to/bruno-mcp/dist/cli.js.

MCP tools

Tool	Purpose
`list_collections`	Describe the active collection
`list_folders`	List the folder hierarchy and endpoint counts
`list_endpoints`	Filter endpoint summaries
`search_endpoints`	Rank endpoints by a text query
`get_endpoint`	Get a sanitized contract by ID or method/path
`get_endpoints`	Get up to 25 contracts by stable ID in one call
`get_endpoint_examples`	Get saved response examples and complete bodies
`get_index_status`	Check generation time and parser warnings

get_endpoint includes method, URL, normalized path, auth mode, body content, field names, documentation, test/assertion presence, source file, and a stable contract hash. Pass include_examples: true to include saved response examples in the same call. Secret-bearing auth, header, and parameter values are not indexed.

get_endpoint_examples returns examples already stored in the index, including the saved response status, content type, and complete body, while omitting the saved request and other response header values.

search_endpoints returns a numeric score and matchedFields with every result. Its default all mode excludes matches found only in low-signal documentation text. Use search_mode: "docs" for an intentional documentation search, or "contract" to ignore docs entirely. Tag filters match both explicit Bruno tags and derivedTags generated from the endpoint folder, method, request type, and known current/legacy roots.

list_folders accepts parent, depth, offset, and limit. get_endpoints accepts at most 25 stable IDs and reports missing IDs without failing the whole batch.

Index command

The generated JSON has a versioned top-level shape:

{
  "schemaVersion": 4,
  "generatedAt": "2026-07-27T00:00:00.000Z",
  "generator": {
    "name": "@dmpv/bruno-mcp",
    "version": "0.6.0"
  },
  "collection": {
    "name": "Example API",
    "endpointCount": 2,
    "sourceFingerprint": "...",
    "formats": ["bru", "opencollection-yaml"]
  },
  "sources": [],
  "folders": [],
  "endpoints": [],
  "warnings": []
}

The default output is .bruno-mcp/api-index.json, which is ignored by Git. Choose a tracked output path when the index is intended as a versioned build artifact. serve automatically checks docs/api-index.json and .bruno-mcp/api-index.json. It loads a persistent index only when its schema is supported and its source fingerprint matches the current Bruno source files; otherwise it safely rebuilds from source. Each endpoint exposes sourceFormat as either bru or opencollection-yaml. Use serve --index <file> to select an explicit index.

Library API

import {
  buildBrunoIndex,
  searchIndex,
  writeBrunoIndex
} from "@dmpv/bruno-mcp";

const index = await buildBrunoIndex("./collection");
const endpoints = searchIndex(index, {
  query: "create order",
  method: "POST"
});

await writeBrunoIndex(index, "./generated/api-index.json");

Development

npm install
npm run check
npm run dev -- serve ./tests/fixtures/sample-collection

npm run check runs the project's automated validation suite.

Security and scope

Bruno MCP is read-only. Version 0.x does not execute requests, scripts, tests, or assertions. It only parses local files.

Body content is included because it is part of an endpoint contract. Do not put real secrets in request bodies. Auth values, header values, and parameter values are deliberately omitted from the index.

License

MIT

Available Tools

8 tools

get_endpointGet a Bruno endpointB

Returns a complete sanitized endpoint contract by stable ID, or by exact method and normalized path.

ParametersJSON Schema

Name	Required	Description	Default
`id`	No
`path`	No
`method`	No
`include_examples`	No

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, so the description must fully disclose behavior. It mentions 'sanitized' without explanation, and omits auth requirements, rate limits, or side effects. The tool is a read operation, but this is not explicitly stated.

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

Conciseness4/5

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

The description is a single sentence with no extraneous information. It is concise but could benefit from additional structuring to separate retrieval modes.

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?

Given 4 parameters, no output schema, and sibling tools for listing, the description does not cover return format, error cases, or how it complements other tools. It is incomplete for reliable agent invocation.

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

Parameters2/5

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

With 0% schema description coverage, the description must compensate by explaining parameters. It only maps two parameters (id, path/method) vaguely. Missing include_examples and the meaning of 'normalized path' are not explained.

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 clearly states it returns a sanitized endpoint contract by stable ID or by method and path. This distinguishes it from sibling tools like list_endpoints and search_endpoints, which handle multiple endpoints.

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 usage when you have a specific endpoint identifier or route, but it does not explicitly state when to use this tool over alternatives like list_endpoints or search_endpoints. No exclusions or conditions are given.

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

get_endpoint_examplesGet Bruno endpoint response examplesB

Lean examples-only alternative to get_endpoint(include_examples: true). Returns saved status, content type, and complete response bodies without the full contract.

ParametersJSON Schema

Name	Required	Description	Default
`id`	No
`path`	No
`method`	No

TDQS

B3.4/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 burden. It discloses what is returned (status, content type, complete response bodies) and that it excludes the full contract. However, it does not mention read-only behavior, authorization needs, or any 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.

Conciseness4/5

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

The description is a single sentence that efficiently conveys the tool's purpose and value proposition. It is front-loaded with key information, though it could be slightly more structured.

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?

Given 3 undocumented parameters, no output schema, and no annotations, the description is insufficient. It does not explain how to use the parameters or what the response structure looks like beyond a vague list.

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

Parameters1/5

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

The input schema has 3 parameters (id, path, method) with 0% schema description coverage. The description adds no information about these parameters, leaving the agent to guess their purpose and required format.

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 clearly states the tool returns response examples (status, content type, bodies) and positions itself as a lean alternative to get_endpoint(include_examples: true). This verb+resource pair is specific and distinguishes it from siblings.

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

Usage Guidelines4/5

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

The description explicitly frames the tool as an alternative to get_endpoint when only examples are needed, providing clear context for when to use it. However, it does not list explicit 'when not to use' or alternative tools beyond get_endpoint.

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

get_endpointsGet multiple Bruno endpointsA

Returns up to 25 complete sanitized endpoint contracts by stable ID in one call. Use include_examples only when complete saved responses are required.

ParametersJSON Schema

Name	Required	Description	Default
`ids`	Yes
`include_examples`	No

TDQS

A3.6/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. It states 'returns' implying read-only but does not explicitly confirm idempotency, safety, or side effects. Also lacks details on auth, rate limits, or error behavior.

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?

Two sentences, front-loaded with purpose, no wasted words. Every sentence adds value.

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

Completeness3/5

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

With 2 simple parameters, no output schema, and moderate sibling set, description covers core function but lacks return structure details and explicit sibling distinctions. Adequate but leaves gaps.

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

Parameters2/5

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

Schema description coverage is 0%. Description only mentions include_examples in usage advice and indirectly references IDs. Does not explain what stable IDs are, format, or how to obtain them.

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?

Description clearly states it returns up to 25 complete sanitized endpoint contracts by stable ID in one call. This distinguishes from siblings like list_endpoints (summaries) and get_endpoint (single).

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

Usage Guidelines4/5

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

Explicitly advises to use include_examples only when complete saved responses are required. Implies when to use this tool (batch by ID) vs alternatives (list, search), but lacks explicit contrast descriptions.

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

get_index_statusGet Bruno index statusA

Returns index generation time, endpoint count, and parser warnings.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It fails to mention that the operation is read-only, has no side effects, or any permission requirements. While the read-only nature is implied, it is 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.

Conciseness5/5

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

The description is a single concise sentence that efficiently conveys the tool's output. No wasted words.

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

Completeness3/5

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

Given no parameters and no output schema, the description covers the basics by listing the returned items. However, it lacks details on the format or structure of those items, and no behavioral context, making it minimally complete.

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

Parameters4/5

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

There are zero parameters, so per the guidelines the baseline is 4. The description correctly adds no unnecessary parameter information since none exist.

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 clearly states what the tool does: 'Returns index generation time, endpoint count, and parser warnings.' The verb 'returns' and the resource 'Bruno index status' are specific, and it distinguishes from sibling tools that focus on listing or retrieving endpoints.

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

Usage Guidelines2/5

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 its siblings. It does not explain the purpose of the index status or when it would be relevant to call this tool.

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

list_collectionsList Bruno collectionsA

Returns the active Bruno collection and its endpoint count.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.5/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden but only states it 'Returns' data. It does not disclose behavioral traits such as read-only nature, authentication needs, or side effects. The brief description provides minimal transparency beyond the obvious.

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 extremely concise: a single sentence that front-loads the core purpose. Every word is necessary and no redundancy.

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

Completeness3/5

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

For a simple tool with no parameters, the description is adequate but minimal. It lacks detail about the output format, what constitutes an 'active' collection, and potential nuances. Given the lack of output schema, more context would improve completeness.

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

Parameters4/5

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

The tool has zero parameters, so the description adds context about what is returned, which is valuable. Baseline for zero parameters is 4, and the description meets that by explaining the output.

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 clearly states the tool returns the active Bruno collection and its endpoint count, using a specific verb and resource. It distinguishes from siblings like list_folders and list_endpoints by focusing on collections.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives like list_folders or list_endpoints. The description lacks context for selection.

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

list_endpointsList Bruno endpointsC

Lists endpoint summaries, optionally filtered by method, request type, folder, or tags.

ParametersJSON Schema

Name	Required	Description	Default
`tags`	No
`type`	No
`limit`	No
`folder`	No
`method`	No
`pathPrefix`	No

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose behavioral traits such as pagination (despite a limit parameter), ordering, rate limits, or whether the operation is read-only. The term 'summaries' is vague.

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

Conciseness4/5

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

Single concise sentence that communicates the core function without redundancy. Could be slightly more informative without losing conciseness.

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?

For a tool with 6 parameters and no annotations or output schema, the description is incomplete. It lacks details on pagination, output format (what a summary includes), and how to handle large result sets. Sibling tools suggest overlapping functionality.

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?

The description adds meaning for 4 of 6 parameters by naming filters for method, request type, folder, and tags. However, it omits explanation of 'limit' and 'pathPrefix', and does not elaborate on the enum values for 'type'. With 0% schema description coverage, compensation is partial.

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

Purpose4/5

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

The description clearly states 'Lists endpoint summaries' with optional filters, which distinguishes it from sibling tools like list_collections and get_endpoint. However, it does not explicitly differentiate from search_endpoints or get_endpoints.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like search_endpoints for full-text search or get_endpoints for retrieving all endpoints. The description implies usage for filtered listing but provides no exclusions.

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

list_foldersList Bruno collection foldersB

Returns a paginated collection folder hierarchy. Use parent and depth to explore a subtree without loading the complete hierarchy.

ParametersJSON Schema

Name	Required	Description	Default
`depth`	No
`limit`	No
`offset`	No
`parent`	No

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations, the description should disclose behavioral traits. It only says the tool returns paginated results, but omits details like whether it's read-only, side effects, error handling, or access requirements.

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?

Two concise sentences: first states the primary action, second provides a usage tip. No redundant information, efficiently front-loaded.

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?

The tool has 4 parameters and no output schema. The description lacks details on pagination behavior (e.g., how to iterate), expected output structure, error conditions, and relationship to sibling tools. Important gaps remain.

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

Parameters2/5

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

Schema coverage is 0%, so the description must compensate. It mentions 'parent' and 'depth' but does not explain 'limit' or 'offset', nor does it specify data types or defaults. It adds minimal semantic value beyond the parameter names.

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 clearly states the tool returns a paginated collection folder hierarchy, and the title 'List Bruno collection folders' reinforces this. It distinguishes from siblings like list_collections (which likely returns collections, not folders) by specifying hierarchy context.

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 advises using 'parent' and 'depth' to explore subtrees without loading the full hierarchy, which provides some usage context. However, it does not explicitly state when to use this tool over alternatives or mention any exclusions.

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

search_endpointsSearch Bruno endpointsA

Searches endpoints with field-aware ranking. Returns score and matchedFields for every result; docs-only matches are excluded by default.

ParametersJSON Schema

Name	Required	Default
`tags`	No
`type`	No
`limit`	No
`query`	Yes
`folder`	No
`method`	No
`pathPrefix`	No
`search_mode`	No	all

TDQS

A3.9/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It discloses key behaviors: field-aware ranking, return of score and matchedFields, and default exclusion of docs-only matches. This goes beyond the schema, though it omits details like auth requirements or rate limits, which are less critical for a search 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 consists of two concise sentences that efficiently convey the tool's purpose and key behaviors without extraneous information. It is front-loaded with the core verb and resource.

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

Completeness4/5

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

For a search tool with no output schema, the description adequately specifies return values (score, matchedFields) and a key filter (docs-only exclusion). However, it does not explain the ranking algorithm or other search mode behaviors, though the schema's enums cover search_mode. Overall sufficient for typical use.

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

Parameters2/5

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

Schema description coverage is 0%, and the description does not elaborate on any parameters. While the schema defines types and enums, the description adds no additional meaning to help the agent understand parameter usage, default behaviors, or constraints beyond what the schema already provides.

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 clearly states the tool searches endpoints with field-aware ranking, and specifies that it returns score and matchedFields and excludes docs-only matches by default. This distinguishes it from sibling tools like list_endpoints which likely return all endpoints without ranking.

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 usage for searching endpoints with ranking and filtering, but does not explicitly state when to use this tool over alternatives like list_endpoints, get_endpoint, or search modes. No exclusions or alternative recommendations are provided.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

8 tool updatesv0.4.0Jul 28, 2026
- First observedget_endpoint
- First observedget_endpoint_examples
- First observedget_endpoints
- First observedget_index_status
- First observedlist_collections
- First observedlist_endpoints
- First observedlist_folders
- First observedsearch_endpoints

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation5/5

Each tool targets a distinct operation: listing collections, folders, endpoints, getting single/bulk endpoints, searching, examples, and index status. No overlap in functionality.

Naming Consistency5/5

All tools follow the verb_noun pattern consistently, using 'list_' for enumeration and 'get_' for retrieval, with clear singular/plural distinctions (e.g., get_endpoint vs get_endpoints).

Tool Count5/5

With 8 tools, the server is well-scoped for its purpose of inspecting Bruno API collections. Each tool has a clear role, and the count is neither too sparse nor excessive.

Completeness4/5

The tool surface covers all essential read operations for collections, folders, endpoints, and search. Missing write operations (create, update, delete) are outside the intended scope, though a tool to list tags or metadata could be a minor addition.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

apis-io B
io.apis
Read-only MCP server over the APIs.io catalog — discover APIs, providers, tags & artifacts.
Search Developer Tools Documentation Access
1332
OrchestKit Docs MCP A
io.github.yonatangross
Read-only MCP server for the OrchestKit docs: full-text search + Markdown fetch. No auth.
Documentation Access Search
23186
kalicart-global A
io.github.giuseppesocci-bot
Federated commerce search across independent WooCommerce merchants. Keyless, read-only MCP server.
E-commerce & Retail Search
53
mcp A
ai.llmse
Public MCP server for the LLM Search Engine
Search RAG Systems Developer Tools
102

Related MCP Servers

Bruno MCP
Testing & QA Tools Developer Tools
hungthai1401
A
license
B
quality
D
maintenance
MCP Server for running Bruno Collections
Updated a year ago (2025-08-16 04:24 UTC)
1
87
44
MIT
Bruno MCP Server
macarthy
A
license
B
quality
F
maintenance
A Model Context Protocol (MCP) server that enables programmatic creation and management of Bruno API testing collections, environments, and requests through standardized MCP tools.
Updated a year ago (2025-07-19 05:23 UTC)
1
87
31
MIT
bruno-mcp
API Testing Developer Tools
jackmulligan-ire
A
license
Not graded
quality
C
maintenance
MCP server that executes requests from Bruno API collections via the Bruno CLI tool, enabling API request execution and collection management.
Updated 5 months ago (2026-04-14 20:13 UTC)
4
MIT
swagger-mcp
Documentation Access Developer Tools
emreycolakoglu
A
license
A
quality
B
maintenance
A read-only MCP server for navigating OpenAPI / Swagger specifications, enabling agents to search endpoints, retrieve parameters and schemas, and inspect authentication without loading the full spec into context.
Updated 2 months ago (2026-07-08 19:20 UTC)
9
19
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/TheDMPV/bruno-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server