Loading ToolBench
An MCP server for the Unfour workspace platform, providing command execution, database queries, HTTP requests, SSH operations, and workflow automation capabilities.
Unfour MCP exhibits significant gaps in tool definition quality. While six tools are explicitly defined with names and input schemas in crates/unfour-command-bus/src/lib.rs, the definitions lack depth and rigor required for production LLM-facing tools. Tool descriptions are present but generic (averaging ~80 chars), falling below the baseline of 194 chars. Parameter descriptions exist but are minimal (often single-phrase). No output schemas are documented, critical for LLM planning and chaining. Error handling guidance is absent. The tools mix concerns (e.g., unfoor.http.request accepts both headers AND auth objects, conflating orthogonal concepts). No input validation rules, enums, or constraints are visible in the source. The tool interface favors opaque IDs (database_id, session_id, flow_id) over human-friendly names, forcing agents into unnecessary lookup loops.
Execute SQL queries against configured databases (SQLite, PostgreSQL, MySQL)
Execute workflow flows with support for variables, conditions, and step orchestration
Send HTTP requests with support for various methods, headers, authentication, and response processing
Execute SSH diagnostic commands for troubleshooting SSH connections and service status
Get details about a specific workspace
List available workspaces and their configurations
No output schemas documented for any tool. LLMs cannot infer response structure, plan downstream tool calls, or extract necessary fields for chaining. Critical blocker for multi-step agent workflows.
Opaque IDs (database_id, session_id, flow_id, workspace_id) force agents into unnecessary lookup loops and prevent natural-language input. No tools to resolve human-friendly names to IDs, and output schemas missing so lookup results cannot be used effectively.
Descriptions are generic and under baseline (avg 62 chars vs 194 baseline). No WHEN/WHY context, no actionable guidance for selection, no recovery hints on error. Tool descriptions should answer: What does it do? When to call it? What if it fails?
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 44 | 2026-07-28+ | v2 |
No input validation or constraints. 'limit' is unbounded integer (can be 0, negative, or millions). HTTP method has no enum. 'diagnostic_type' accepts free text instead of enum. Diagnostic_type description includes examples ('logs', 'service-status') which invite LLM hallucination. Parameters must use enums or formal constraints, not examples.
'unfour.http.request' accepts 'auth' object parameter with no schema, allowing credentials to be passed as tool parameters. This violates secret-injection pattern, agent traces log all parameters, leaking secrets into logs and prompt history.
No error handling guidance. Tools do not indicate what errors are retryable, user-fixable, or fatal. No recovery paths provided (e.g., 'If database not found, call list_databases()'). Error responses will be cryptic to LLMs.
'unfour.database.query' marked as WRITE but description does not warn of side effects. Agents need explicit messaging about irreversibility to plan correctly. Description should state: 'This tool executes queries that may modify data, use with caution. Consider dry-run or confirmation.'
No idempotency or retry semantics documented. 'unfour.flow.execute' and 'unfour.http.request' do not indicate if repeated calls with same input produce same result or cause duplicates. Agents will not know if it is safe to retry on ambiguous failures.
'unfour.workspace.list' and 'unfour.workspace.get' lack pagination support. No limit, offset, or cursor parameters. If many workspaces exist, list response could exceed context window. No guidance on result counts or truncation.