governed-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| as | No | Name recorded for the approver, passed as `--as <name>` (e.g. `governed-mcp -c examples/governed.yaml approve apr_... --as you --note "looks right"`). Authentication is out of scope; this only records a name. | |
| role | No | Gateway role, passed as `--role <agent|approver>`. The default agent-facing role exposes the proxied downstream tools; `--role approver` additionally exposes `approve` and `reject` (e.g. `governed-mcp -c governed.yaml serve --role approver --as <name>`). | |
| config | Yes | Path to the YAML policy/config file, passed with the -c option (e.g. `governed-mcp -c governed.yaml serve`, `governed-mcp -c examples/governed.yaml pending`). |
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
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| search_ticketsA | [policy: allow] Search tickets by text in title/body, optionally filtered by status. |
| get_ticketA | [policy: allow] Get one ticket with its full body and comments. |
| get_customerC | [policy: allow] Get a customer record. |
| add_commentB | [policy: allow] Add an internal comment to a ticket. |
| update_ticketA | [policy: require_approval] Change a ticket's status (open|in_progress|closed), priority (P1-P4) and/or assignee. |
| issue_refundB | [policy: require_approval] Refund an amount to a customer's account balance. |
| delete_customerB | [policy: deny] Permanently delete a customer and their tickets. |
| list_pendingA | List tool calls waiting for a human decision. |
| approval_statusA | Check a held call by its approval_id. Returns its status (pending, executing, done, failed, rejected, expired) and, once done, the downstream result. |
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 9 tools
Each tool maps to a distinct resource+action: searching vs. fetching tickets, commenting vs. updating status, refunding, and deleting a customer are all clearly separated. The only mild overlap is between list_pending (all held calls) and approval_status (one call by id), but the descriptions make the boundary readable.
Strong, predictable snake_case verb_noun pattern (search_tickets, get_ticket, add_comment, update_ticket, issue_refund, delete_customer). The two approval tools deviate slightly toward noun phrasing (list_pending, approval_status), with approval_status notably lacking a verb.
Nine tools is well within the ideal 3-15 range and each one earns its place across the ticket, customer, and approval-gate surfaces. No tool looks redundant or vestigial.
Read/update/comment/refund/delete are covered, but there is no create_ticket and no customer creation or update, so the lifecycle is not closed. The approval flow also lacks any approve/deny operation, leaving agents to rely on an out-of-band human decision.