Loading ToolBench
Thin MCP server for OrionBelt Semantic Layer — delegates to REST API
OrionBelt MCP has 9 well-named tools with consistent verb_noun structure (load_model, remove_model, list_models, etc.). All tools include descriptions and input schemas with typed parameters. However, descriptions are terse (most under 80 chars), parameter descriptions lack detail about constraints and formats, output schemas are not documented, and error handling guidance is absent. The server delegates to a REST API, which is a valid thin-wrapper pattern, but tool definitions do not reflect API response structure or help agents understand what data they'll receive. No tool annotations (readOnlyHint/destructiveHint) despite clear semantic differences (load_model, remove_model are writes; query, list_models are reads). Batch operation (run_batch) accepts array input but output schema is undocumented. Parameter descriptions for query and run_batch do not explain what 'natural language or semantic query' means or what format is expected.
Get detailed information about a model
Get the schema/structure of a model
List fields available in a model
List available models
Load a model into the session for querying
Execute a query against the loaded model
Unload a model from the session
Descriptions are too terse (most <80 chars) and lack context for LLM selection. E.g. 'Load a model into the session for querying' does not explain when to call this vs alternatives, what happens to previous models, or what load_model returns. Baseline for A+ tools: 100 - 250 chars with WHAT, WHEN, and dependencies.
Parameter descriptions are missing or generic. 'The model identifier to remove' and 'The model to query' do not explain format (UUID? string slug?), constraints, or examples. LLMs cannot infer valid input without explicit parameter documentation.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 64 | 2026-07-28+ | v2 |
Execute a batch query operation
Validate a model definition
Output schemas are not documented. Agents cannot plan downstream calls or extract chaining IDs without knowing what fields each tool returns. E.g. does list_models return {id, name, description}? Can query result be paginated? Does run_batch return per-item success/failure or blanket success/error?
No tool annotations despite clear semantics. load_model and remove_model should be marked destructiveHint=true (they modify session state). list_models, query, and describe_model should be readOnlyHint=true. Agents need this metadata to plan side effects and retry safety.
run_batch accepts an array of queries but does not document: What is the schema of each query in the array? Are they strings, objects with fields? What happens if one query fails, does the tool return partial results or fail completely? This ambiguity forces LLMs to guess.
No error handling guidance. Tools do not document what errors are possible (model not found, query syntax error, API timeout), whether they are retryable, or what the LLM should do next. Agents encountering an error have no recovery path.
query parameter 'query' accepts 'Natural language or semantic query' but does not explain what 'semantic query' means, what syntax is supported, or what the API actually receives. This ambiguity invites hallucinated query formats.
No pagination documented for list_models, list_fields, or query results. If these can return large result sets, agents may exceed context limits. Tools should accept limit/offset and return total_count or next_cursor.