Loading ToolBench
An MCP server that bridges AI agents to external tools and services, providing configuration management, session handling, signaling, and tool dispatching capabilities.
Praetorium.Bridge exposes 17 configuration management tools with consistent naming (verb_noun pattern: get_*, list_*, upsert_*, delete_*, set_*) and clear descriptions (avg ~120 chars). All tools have input schemas with typed parameters and descriptions. However, output schemas are not formally documented, responses are JSON strings without declared structure. Error handling is basic (string error messages, no recovery guidance). No tool annotations (readOnlyHint/destructiveHint) despite clear risk levels. Missing idempotency guarantees and parameter validation details. Composition is sound: tools chain well (e.g., list_tools → get_tool → upsert_tool). Security: no secrets in params, but no audit logging visible.
Removes an agent tool source from the staged configuration.
Removes a tool from the staged configuration.
Returns the full JSON of one agent tool source.
Returns the staged configAgent section (provider/model/reasoningEffort/promptFile for this chat agent itself).
Returns a high-level summary of the staged configuration: server, defaults, tool names, agent tool source names, and configAgent section. Use this first to orient yourself.
Returns the staged defaults section (agent, session, signaling defaults).
Returns the staged server section.
Returns the full JSON definition of a single tool from the staged configuration.
Output schemas not formally documented. Tools return JSON strings (e.g., get_config_summary, list_tools) but the structure of those JSON objects is not declared in the tool definition. LLMs cannot plan downstream calls or extract fields reliably.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Tools are marked with Risk levels (READ_ONLY, WRITE, DESTRUCTIVE) in metadata but not exposed via MCP tool annotations. Agents cannot infer safety properties from the tool definition alone.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | <=2025-11-25 | v2 |
Lists all agent tool sources (MCP servers) in the staged configuration.
Lists all tools in the staged configuration with their descriptions.
Replaces (or sets, if null) the configAgent section. Pass an empty object {} to clear individual fields; pass 'null' as the JSON to remove the section entirely.
Replaces the defaults section wholesale with the provided JSON body.
Replaces the server section wholesale with the provided JSON body.
Replaces the 'agent' subsection of one tool (or removes it with 'null'). Touches only tools.<toolName>.agent.
Sets or clears the description of an existing tool. Pass empty string to clear.
Adds or replaces an agent tool source. The sourceJson must be a valid AgentToolSource (stdio/http/sse/websocket).
Adds a new tool or replaces an existing one. The toolJson must be a valid ToolDefinition (matching the bridge schema).
Error handling lacks recovery guidance. Errors return plain strings ('Error: tool not found', 'Error: invalid JSON') without suggesting next steps. Per pattern:recovery-guide, errors should guide the LLM: 'Tool not found. Call list_tools() to see available tools.'
JSON parameter descriptions lack format/constraint details. 'toolJson' and 'sourceJson' params say 'JSON body' but do not specify required fields, allowed keys, or validation rules. LLMs cannot self-correct invalid JSON without explicit constraints.
No idempotency guarantees documented. Destructive operations (delete_tool, delete_agent_tool_source) do not state whether repeated calls are safe. Agents retry on ambiguous failures, non-idempotent tools risk duplicate deletions.