Loading ToolBench
A Model Context Protocol (MCP) server for Bullhorn CRM that provides tools to query and retrieve data from Bullhorn CRM via JDBC. Supports SQL queries, table metadata retrieval, and column information discovery.
This is a three-tool SQL data connector for Bullhorn CRM. Tools are well-named with clear action verbs (get_, run_) and have basic descriptions. However, schemas are visible but incomplete in several respects: parameter descriptions are minimal (catalog/schema lack guidance on when they're needed), output structure is not formally documented (tools return CSV format but no schema for what columns/rows structure looks like), and error handling is absent (exceptions are caught but no actionable recovery guidance is returned to the LLM). The tool descriptions mention output format in prose ('CSV format, with the first line containing column headers') but this is not machine-parseable. Parameter constraints are missing, for example, the 'sql' parameter in run_query accepts arbitrary SELECT statements but provides no validation guidance or examples of valid dialects/clauses in the description itself (though the tool description mentions 'SQL-92' and lists valid clauses, this belongs in the parameter description). All three tools are read-only which is good for safety, but this is not formally declared via toolAnnotations (readOnlyHint). Tool composition is reasonable, three tools (discovery/inspect/query) form a logical chain, but the intermediate outputs (tables, columns) are not formally documented as enabling downstream tool calls.
Retrieves a list of fields, dimensions, or measures (as columns) for an object, entity or collection (table). Use the `{prefix}_get_tables` tool to get a list of available tables. The output of the tool will be returned in CSV format, with the first line containing column headers.
Retrieves a list of objects, entities, collections, etc. (as tables) available in the data source. Use the `{prefix}_get_columns` tool to list available columns on a table. Both `catalog` and `schema` are optional parameters. The output of the tool will be returned in CSV format, with the first line containing column headers.
Execute a SQL SELECT statement.
Output schemas not documented. All three tools return CSV strings, but LLMs cannot parse the structure from prose description alone ('CSV format, with the first line containing column headers'). A formal response schema showing expected field types, counts, and structure would enable downstream tool integration and result validation.
Parameter constraints under-specified. The 'catalog' and 'schema' parameters in get_tables and get_columns lack descriptions explaining when they are required vs optional (the tool description says 'optional parameters' but the schema shows required=[] with no per-param guidance). The 'sql' parameter in run_query references 'SQL-92' dialect and 'valid clauses' in the tool description but not in the parameter description itself, forcing LLMs to parse prose instead of relying on formal constraints (enums, patterns, or length limits).
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 50 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 34 | - | v1 |
No error handling or recovery guidance. The source code shows exceptions are caught and re-thrown as RuntimeException('ERROR: ' + ex.getMessage()). This stack-trace-style error response provides no actionable guidance to the LLM: it doesn't classify the error as retryable or user-fixable, doesn't suggest an alternative tool, and doesn't help the agent understand what went wrong. Per pattern:recovery-guide, errors should tell the agent what to do next.
No tool annotations. All three tools are read-only (safe, non-destructive) but this is not formally declared via toolAnnotations (readOnlyHint). This forces the LLM to infer safety from the description text alone, which is fragile and error-prone.
Parameter descriptions are generic. 'The catalog name' and 'The schema name' are minimal, they do not explain what a catalog or schema is in the context of Bullhorn CRM, when to use them, or how to discover valid values. Descriptions should answer: what is this, when do I use it, and how do I find valid values?
Tool descriptions lack dependency/prerequisite guidance. The tools mention 'Use [other tool] to...' but don't explicitly state: 'Call get_tables first to discover available tables, then get_columns to inspect table structure before writing SQL.' This would help LLMs plan multi-step discovery workflows.