AI Intervention Agent
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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
} |
| logging | {} |
| prompts | {
"listChanged": true
} |
| resources | {
"subscribe": false,
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| interactive_feedbackA | Ask the human user for interactive feedback through the Web UI. Use this tool whenever you need a human decision, clarification, confirmation, plan approval, design review, or final sign-off before continuing — especially when the next step has multiple valid approaches, irreversible side effects, or significant trade-offs. Behavior:
Cross-tool compatibility:
|
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| Server Info | Self-information for ai-intervention-agent MCP server. Returns version, transport, runtime details, middleware chain, accumulated error stats, Web UI runtime status, and task-queue snapshot as JSON. |
TDQS
Scored across 1 tool
There is only one tool, so no selection ambiguity is possible. Its purpose (soliciting human feedback via a Web UI) is stated explicitly and cannot be confused with anything else on the server.
The lone tool uses a clear snake_case verb_noun name (`interactive_feedback`) consistent with common MCP conventions. With a single tool there is no opportunity for convention mixing.
The server's scope is deliberately narrow — one blocking human-in-the-loop request — so a single tool is defensible rather than thin. A slightly richer surface (e.g. a non-blocking/poll variant) would justify a higher score, but nothing here is redundant.
The ask-feedback lifecycle (render message/options, block, return reply, retry on failure, then surface cause after 3 failures) is well covered, including tolerance for alias parameters from sibling servers. Minor gaps exist: no way to query pending/previous feedback or to check status without issuing a new request.