brydge-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| BRYDGE_URL | No | Where BRYDGE runs. Leave it unset for BRYDGE's hosted service. | |
| BRYDGE_ACTOR | Yes | The name BRYDGE knows this agent by, such as agent:refund-ops. Mandates are issued to this name. Required. | |
| BRYDGE_API_KEY | Yes | Your BRYDGE API key. Required. |
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": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| brydge_superviseA | Ask BRYDGE whether you may take an action, before you take it. ALLOWED returns an authorization id: carry the action out and write that id into the record it creates, where the destination keeps it (for a Stripe refund: metadata.brydge_authorization). ESCALATED means a person decides: do not carry it out. |
| brydge_report_outcomeA | Tell BRYDGE what you believe happened after you carried out an allowed action. BRYDGE keeps your report beside what it finds in the destination's records; the report never changes the finding. |
| brydge_verifyA | Check whether an action actually happened. BRYDGE reads the destination system's own records now, with its own credential, and compares them with what it permitted. Only VERIFIED means it happened as permitted; FAILED, MISMATCH, UNKNOWN (BRYDGE could not tell) and PENDING (still in progress) are not. Use it before you tell anyone the work is done. A check that finds something new is billed; asking again when nothing has changed is free. |
| brydge_get_findingA | What BRYDGE has already found about an action, without reading the records again. Free. BRYDGE checks each action by itself once the destination's reporting window has passed; until then this says PENDING. |
| brydge_get_headroomA | How many actions of this kind you may take in any 24 hours before a person is asked, how many are left, and what raises or lowers that. Every report BRYDGE checks and finds true raises it. |
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 5 tools
Each tool has a clearly distinct purpose: supervise (request permission), report_outcome (report results), verify (check actual state), get_finding (retrieve stored findings), and get_headroom (check quota). No two tools overlap in function; an agent can easily select the right one based on the action needed.
All tools follow a consistent 'brydge_' prefix with a verb or verb_noun pattern (e.g., supervise, report_outcome, verify, get_finding, get_headroom). The naming is uniform, predictable, and clearly indicates the action each tool performs.
With only 5 tools, the server is well-scoped to its domain of permission, reporting, verification, and quota management. Each tool earns its place and together they cover the core workflow without unnecessary bloat.
The tool surface covers the full lifecycle: request permission (supervise), report outcome (report_outcome), verify actual state (verify), retrieve past findings (get_finding), and check limits (get_headroom). No obvious gaps exist for the stated purpose.