Mechanism: MCP Tool Bridge
One-sentence definition
An MCP tool bridge gives the agent structured, scoped access to external systems — browser, database, APIs, docs — through defined tools instead of vague “figure it out” permissions or pasted secrets.
The problem
You paste API keys, copy SQL results by hand, or let the agent guess URLs. Context fills with fragile snippets. The agent hallucinates endpoints or runs destructive queries because it has no real boundary between “read health check” and “drop table.”
MCP (Model Context Protocol) and similar tool layers turn integrations into named capabilities with inputs and outputs — closer to functions than freeform browsing.
Symptoms:
- Secrets in chat for one-off API calls
- Agent describes browser state without seeing the page
- Manual copy-paste loops between terminal and chat
- Over-broad “run any command” agent permissions
How it works
Agent
│
▼
MCP tool (browser · DB read · ticket API)
│
├── allowed action set
├── structured request/response
└── logged / reviewable output
│
▼
You verify output ([verify loop](/mechanism-verify-loop/))Design tools with constraints:
- Read-only DB tool vs write
- Browser navigate + snapshot, not arbitrary shell
- No credential in prompt — env on server side
TeacHER teaches MCP as a concept; this mechanism is using it safely in vibe workflows.
When to use it
- UI bugs needing real DOM state
- Integration tests against staging APIs
- Fetching ticket/spec from Linear, Notion, etc.
- Replacing five manual paste steps with one tool call
When not to use it
- Task solvable with local tests and git diff only
- MCP tool with admin scope “because easier”
- Production write tools without human checkpoint
Failure modes
God tool — One MCP server with full shell. Fix: Least privilege per tool.
Secret in prompt — API key in user message. Fix: Server-side env; rotate if leaked.
Trust tool output blindly — Stale snapshot, wrong tab. Fix: Re-snapshot; verify behavior.
Tool sprawl — 30 MCP servers enabled. Fix: Enable per task; context budget.
Skip verify — Tool says OK; app broken. Fix: Independent check (curl, test).
Minimal example
Context: Verify health endpoint in running dev server.
Steps:
- Enable browser or HTTP MCP tool (read-only).
- Prompt: “GET
http://localhost:3000/health?verbose=1; report status and JSON body only.” - Compare tool output to example-driven spec rows.
- Agent edits code; you re-run tool — not “looks fine.”
Done when: Behavior verified via tool output captured in chat or log.
Tool instances (optional deep-dive)
Portable idea above; this section is tool-specific. Date: June 2026.
Cursor
- MCP servers in settings: browser, GitHub, custom HTTP.
- Prefer read-only tools for exploration; write tools behind approval.
- Combine with hooks: tool result → test → agent.
Other tools
Custom MCP servers for internal APIs; same bridge pattern anywhere MCP is supported.
Related mechanisms
- Verify loop — validate tool-reported state
- Hooks / automation — tools triggered on events
- Constraints — scope tool permissions
Try it yourself
Exercise: Replace one manual paste habit (curl output, DB row, browser check) with a single tool call and save the raw tool response in notes.
Done when: Next session can reuse the same tool pattern without re-explaining credentials.