Built an open-source MCP Server for Bruno: Run collections, test disabled filter matrices, and keep JWT/secrets out of LLM context

[kta41]

Hey everyone! 👋

I've been using Bruno heavily for API work alongside AI coding agents (GitHub Copilot, Claude Code, Cursor), and I kept running into two major frustrations when letting agents run my .bru collections:

1. Secret leakage into LLM prompts: Agents constantly ask for Bearer tokens or API keys in the chat, or read .env files directly into the context window, sending credentials straight to the AI provider.
2. "200 OK" false confidence: An agent runs a collection, sees 200 OK on the baseline request, and calls it a day—ignoring all the disabled query/filter parameters configured in the .bru files that might actually be broken.

So I built mcp-bruno, an open-source Model Context Protocol (MCP) server specifically designed for Bruno workflows.

What it does:

• 🔒 Zero-Trust Secret Injection (inherited_variables): The LLM only passes variable names (like bearerToken). The MCP server resolves the actual token locally from BRUNO_AUTH_TOKEN or a local .bearer_token file. The AI never sees your secrets.
• 🧪 2-Phase Full Filter Validation (run-full-validation): Runs a baseline check first. If 100% green, it automatically generates and runs temporary scenarios testing every disabled filter across your endpoints to catch regressions.
• 🌍 Auto-Discovery: Automatically discovers sibling environments/ folders and .bru / opencollection.yml structures.
• 📦 Zero-install execution: Published on PyPI, so you can plug it straight into Claude Code, Cursor, or VS Code Copilot using uvx mcp-bruno (or Docker). Includes ready-to-use Copilot .agent.md and SKILL.md rules.

🔗 GitHub Repo: https://github.com/kta41/mcp-bruno
📦 PyPI: mcp-bruno

If you use Bruno with AI agents, I'd love your feedback (and a ⭐ on GitHub if you find it useful!). Let me know if there are specific .bru assertions or multi-environment workflows you'd like to see supported next.

[redbotster]

the secret injection pattern you've built is solid, variable name only into the LLM context and local resolution is exactly the right approach. one thing to watch: if your .bearer_token file lives near the collection, make sure your tool surfaces a warning when it's world-readable, since that's a common footgun people hit after thinking they've solved the problem.

if you ever want a more durable solution for teams, we built 1Claw to do this at the vault layer with short-lived scoped tokens so the raw key never hits env vars or disk either. full disclosure, i work on it. but your local resolution approach is genuinely useful for solo devs and covers the main attack surface.