Loading ToolBench
MCP server that checks the status of Airbyte sources and connections, and lists available sources in a workspace
This MCP server has significant definition quality gaps. Two tools are defined with basic descriptions and input schemas, but both suffer from ambiguous naming, incomplete parameter documentation, no output schema documentation, and weak error handling guidance. The descriptions are adequate in length (90+ chars) but lack LLM-optimized structure (no WHEN to use, no dependency hints, no actionable error recovery). Tool names do not follow verb_noun conventions clearly, 'check_airbyte_connection' and 'check_airbyte_source' conflate listing and checking, violating the single-responsibility principle. Parameter descriptions exist but are minimal (17 chars for 'connection_name') and do not explain format, constraints, or what happens if omitted. No output schema is documented anywhere, forcing LLMs to guess the response structure. Error handling returns generic dictionaries with a 'status' field but no guidance on recovery actions.
Check the status of an Airbyte connection or list all connections. Args: connection_name: Name of the connection to check. If not provided, lists all connections. Returns: A dictionary with status information.
Check the status of an Airbyte source or list all sources. Args: source_name: Name of the source to check. If not provided, lists all sources. Returns: A dictionary with status information.
Tool names conflate two distinct operations (list vs. check). 'check_airbyte_connection' returns either a list of all connections (when connection_name is null) or details for one connection (when provided). This violates single-responsibility and forces LLMs to reason about conditional behavior. Split into 'list_airbyte_connections' and 'get_airbyte_connection_status'.
Parameter description for 'connection_name' is too brief (17 chars) and does not clarify behavior: 'Name of the connection to check. If not provided, lists all connections.' Does not explain format constraints, case sensitivity, or how to discover valid connection names.
No output schema documented. Callers do not know what fields to expect. Code returns a dict with 'status', 'message', optionally 'connections', 'connection_name', 'connection_id', 'streams', 'details'. LLMs must infer structure, risking parse errors and wasted tokens.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 41 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 40 | - | v1 |
Error handling lacks recovery guidance. When a connection is not found, the tool returns {"status": "error", "message": "❌ Connection 'X' not found"} with no hint to call list_airbyte_connections to discover valid names or suggest similar names. Violates recovery-guide pattern.
No enum constraints on parameter values. Parameter descriptions claim a default behavior ('If not provided, lists all connections') but do not declare this formally. No validation shown that 'connection_name' is a string, or what length/format limits apply.
Credentials exposed in environment variables loaded at module level (AIRBYTE_API_KEY, WORKSPACE_ID, CLIENT_ID, CLIENT_SECRET). While not passed as tool parameters (good), they are hardcoded at import time. Server initialization fails loudly if env vars missing. Consider lazy initialization and better error messages.
Tool description for 'check_airbyte_source' is incomplete (source_check.py file appears truncated). The second tool definition in 'working-tmp.py' ends mid-function declaration. Cannot fully assess schema or behavior of this tool.
No pagination support. If workspace contains hundreds of connections/sources, the list tools return all results in a single response, potentially exhausting token budgets and degrading LLM reasoning.