Loading ToolBench
Rust implementation of the Model Context Protocol (MCP) for AI-agent integration with Canary Deployment System
This Rust MCP server provides a database engine switching system with 9 tools. Most tools have clear verb-based names and reasonable descriptions (average ~120 chars), but parameter descriptions are inconsistent and output schemas are not documented. Naming is strong (switch_database_engine, list_available_engines, trigger_manual_switch) with proper action verbs. However, critical gaps exist: no parameter descriptions for several required fields, no documented output schemas for any tool, and error handling is not demonstrated in the source. The HTTP transport is current (Streamable HTTP capable via axum). Tool composition is reasonable, each tool has a single responsibility, but the lack of response schema documentation and missing parameter hints (e.g., 'engine_id' in get_engine_metrics lacks a description) weaken the definition quality significantly.
Cancel a pending database engine switch operation
Configure automatic switching policies based on performance thresholds
Get information about the currently active database engine
Get real-time performance metrics for a specific database engine
Get the history of database engine switches
List all available database engines and their current status
Dynamically switch the active database engine with zero downtime
Output schemas not documented. No tool returns a documented response structure. LLMs cannot plan chained calls or extract required fields for downstream tool invocations. E.g., switch_database_engine does not document whether it returns a switch_id, confirmation_time, or status.
Parameter 'engine_id' in get_engine_metrics has no description. LLMs cannot infer whether to pass 'postgresql', 'postgresql-1', a UUID, or an internal identifier. Description must clarify format and valid values.
No error recovery guidance in descriptions. Tools like cancel_pending_switch and validate_switch_readiness provide no hint about what to do if validation fails or switch cancellation is impossible. Error responses must include actionable next steps.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 72 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Manually trigger a database engine switch immediately
Validate if a target engine is ready for switching
Response field naming not specified. If tools return engine identifiers, they must match parameter names. E.g., if get_engine_metrics expects 'engine_id', responses must return 'engine_id', not 'id' or 'engineId'. This prevents LLM mapping errors when chaining calls.
Destructive tools (switch_database_engine, cancel_pending_switch) lack confirmation/dry-run pattern. These operations could interrupt live database service. No evidence of a dry-run or confirmation step to prevent catastrophic errors.
threshold_config object in configure_switch_policy has optional properties but no guidance on which are required for each trigger_type. E.g., 'performance' trigger may require response_time_ms and cpu_threshold, but 'scheduled' may not. Dependencies between parameters are undocumented.
Pagination not documented. get_switch_history accepts 'limit' (max 100) but no offset, cursor, or next_token field. If history grows large, LLMs cannot paginate results. Include offset/cursor in output schema and limit guidance in description.
No idempotency guarantees stated. trigger_manual_switch and switch_database_engine should document whether repeated identical calls with the same parameters produce the same result. Idempotency is critical for LLM retry safety.
strategy parameter (graceful/immediate/rolling/canary) appears in both switch_database_engine and configure_switch_policy but no description explains the behavioral differences. LLMs cannot reason about which to choose.