Loading ToolBench
MCP server for Claude Code — multi-AI orchestration across local + cloud LLMs, intelligent backend routing, council-driven workflows, and token-saving file operations.
Smart AI Bridge presents 4 well-documented tools with complete JSON schemas and detailed descriptions. Tool names follow verb-noun conventions (review, write_files_atomic, backup_restore, ask). Descriptions are comprehensive (200-800+ chars), explaining WHAT each tool does, WHEN to use it, and what it returns. All tools include input schemas with typed parameters and descriptions. However, there are notable gaps: (1) output schemas are described in prose within the description field rather than formally defined in a structured 'returns' block, LLMs cannot parse these and must infer output shapes from text; (2) some parameters lack granular descriptions (e.g., 'model' param in ask has a long enumeration but no guidance on when to pick 'auto' vs a specific backend); (3) error handling is mentioned in descriptions but not formally documented in a separate error spec; (4) no tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present in the schema definition, forcing LLMs to infer safety from descriptions. The backup_restore and write_files_atomic tools correctly flag destructive operations in their descriptions, which is good practice but would be stronger with formal annotations.
Send one prompt to one AI backend and return the response. `model:'auto'` lets SAB's router pick the best backend by task complexity + current health; passing a specific model name forces that provider. Use this for direct LLM queries that don't fit a more specialized tool. For multi-backend consensus on the same prompt, use `council`. For agentic multi-step work with a defined role, use `spawn_subagent`. For LLM-driven file generation or editing, use `generate_file` / `modify_file` so the file content stays out of Claude's context window. Read-only: makes one HTTP call to the chosen backend. Returns: `{success, model, requested_backend, actual_backend, prompt (truncated preview), response (the LLM output), backend_used, fallback_chain, response_time, cache_status, thinking_enabled, max_tokens, was_truncated, smart_routing_applied, routing, processing_time}`.
Manage the timestamped backup files produced by `modify_file` and `write_files_atomic`. Four actions: `create` (manually snapshot a file before a risky native edit), `list` (enumerate known backups, optionally filtered to one file), `restore` (overwrite a file with a specific backup_id), `cleanup` (delete old backups per the policy in cleanup_options). The cleanup policy applies BOTH thresholds — a backup is deleted only when it exceeds max_age_days OR when its file already has more than max_count_per_file newer backups. Use dry_run to preview before applying. ⚠️ DESTRUCTIVE: `restore` overwrites the current file (the prior state is auto-snapshotted to `<path>.pre_restore_<timestamp>`, so the restore itself is reversible); `cleanup` permanently deletes backup files from disk. `create` and `list` are read-only. Returns: `{ success, action, ...action-specific fields }`. `create`→`{backup_id, backup_path, original_path, size}`. `restore`→`{backup_id, restored_to, pre_restore_backup}`. `list`→`{file_path, backups:[{path, backup_id, size, created, metadata}]}`. `cleanup`→`{dry_run, backups_deleted, deleted:[{path, reason:'age'|'count'}]}`.
Output schemas described in prose but not formalized as JSON Schema 'returns' structures. LLMs cannot machine-parse prose documentation and must infer output shapes by reading descriptions. This violates the pattern:response-shaper guideline and increases hallucination risk when tools return complex objects.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) in schema definitions. Tools explicitly document their safety properties in descriptions (e.g., 'Read-only' in review, '⚠️ DESTRUCTIVE' in write_files_atomic), but MCP schema annotations would let clients and LLMs enforce safety guarantees programmatically rather than relying on prose parsing.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 69 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 46 | - | v1 |
Review a code blob you already have in context and return structured findings + a quality score + improvement suggestions. Pass the code itself in `content`; this tool does not read any file from disk. Use when Claude already has the code in hand. For a review of a file Claude has NOT seen (so the file content stays out of context and a real `tokens_saved` figure is returned), use `analyze_file` with analysisType:'security' instead. For multiple AI perspectives on the same code, use `council`. Read-only: never writes to disk. Returns: `{success, file_path, language, review_type, review (full review text from the LLM, includes findings + severity + suggestions), endpoint_used}`.
Write a batch of files in a single atomic operation with automatic backup. All files succeed or all roll back on any failure. Use this when several file writes must land together (config changes across modules, multi-file generation output). For natural-language edits to a single file, use `modify_file` instead. For appending to a log or accumulator file, use the `append` operation here. Each overwrite produces a `<path>.backup.<timestamp>` file when create_backup is true (default). ⚠️ DESTRUCTIVE: every operation writes (or appends to) a real file on disk. The rollback path runs only when a LATER operation in the same batch fails — earlier successful writes are reverted from their backups, but if every operation succeeds, the new files stand and the backups remain on disk. Returns: `{success, files_written, results:[{path, operation, success, size}], backups_created, backups:[{original, backup}]}`. On a mid-batch failure the call throws after restoring earlier files (rollback is not reflected in a success response).
Model parameter in 'ask' tool has a very long enum list (15+ backends) documented only in prose within the description field, not formalized as a JSON Schema enum constraint. This makes it impossible for LLMs to programmatically discover valid values or for tooling to validate input. The enum should be in the schema.
No formal conditional schema constraints. The backup_restore tool requires file_path for action='create' but ignores it for action='restore', this is only documented in prose descriptions. JSON Schema should use allOf/if-then-else to enforce parameter requirements based on action value, making the constraint machine-readable.
Error handling guidance is minimal. Descriptions mention error responses (e.g., 'returns a result naming the problem' for ask) but do not formally document error categories, retry-ability, or actionable next steps. No pattern:recovery-guide structure for error codes, error classifications, or self-correction hints.
Backup_restore tool has complex action-specific return schemas (create→backup_id, restore→pre_restore_backup, list→backups array, cleanup→deleted array) described only in prose. This violates the pattern:response-shaper principle and forces LLMs to infer per-action return types from text, increasing error risk.
Write_files_atomic tool describes rollback and partial-failure behavior in prose but provides no formal guarantee of atomicity in the schema or explicit per-operation error reporting. The description mentions 'rollback is not reflected in a success response' which is confusing, atomic operations should either succeed or fail wholly, not throw mid-batch.