Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
OrionBelt Analytics presents 26 tools with generally reasonable naming and schema completeness, but suffers from incomplete descriptions, underdocumented parameter relationships, and missing output schema documentation. Tool names follow verb_noun convention well (connect_database, list_schemas, execute_sql_query), but several descriptions are generic or lack actionable context for LLMs. Parameters are typed but many lack detailed format/constraint guidance. No explicit error handling patterns visible in schema. Security consideration: connection parameters passed as objects could mask credential handling risk. The server supports HTTP transport (good), logging (present), and resources/prompts (declared), but lacks tool annotations (readOnlyHint/destructiveHint/idempotentHint) which would clarify intent despite risk labels in metadata.
Missing output schema documentation across all 26 tools. No visible documentation of what fields are returned, their types, or data structure. LLMs cannot reliably chain tools or extract needed values without seeing output schemas.
Add explicit output schema documentation to every tool. For each tool, document: (1) success response schema with all returned fields, types, and descriptions; (2) example output; (3) error response format. Use JSON Schema format in tool definition or extended schema field.
Enhance 'connection' parameter description across all 25 dependent tools. Clarify: Is it a string handle/UUID? How long does it remain valid? Can multiple connections coexist? Example: 'connection: string (UUID returned by connect_database; valid for this session; required for all subsequent operations)'.
Add tool annotations (readOnlyHint, destructiveHint) to the MCP tool schema. Mark read-only tools (discover_schema, list_schemas, get_table_details, etc.) with readOnlyHint=true. Mark destructive tools (cleanup_workspace) with destructiveHint=true. This ensures the LLM sees risk signals in the formal schema.
Document parameter sub-schemas for object/array types. For 'connection_info', provide a typed schema showing required fields per database_type (e.g., PostgreSQL requires host, port, database, username; BigQuery requires project_id, credentials_json). For 'mappings', show expected structure like {original_name: string, semantic_name: string}[]. For 'triples' in add_rdf_knowledge, show [{subject: string, predicate: string, object: string}].
Add error handling guidance to tool descriptions. Examples: 'execute_sql_query: On validation failure, returns {error: string, invalid_statement: string, suggestion: string}. If fan-trap detected, suggests join optimization.' 'connect_database: On auth failure, returns {error: 'auth_failed', reason: string, retry_guidance: string}.'
Incomplete parameter descriptions. Many parameters have type and name but lack actionable constraint guidance (e.g., 'connection' is just 'Connection handle returned by connect_database', what format? Can it be a path string? What's the lifecycle?). 'connection_info' described only as 'Database-specific connection parameters' without database-specific enum or structure.
No tool annotations in schema. All tools carry risk labels (READ_ONLY, WRITE, DESTRUCTIVE, REVERSIBLE) in metadata but these are NOT reflected in the MCP tool definitions as readOnlyHint, destructiveHint, or idempotentHint. LLMs cannot see these risk signals in the formal schema and may misuse destructive tools (cleanup_workspace, delete workspace files) without adequate caution.
No explicit error handling patterns. Tool descriptions lack guidance on what errors can occur, how to recover, or what the LLM should do on failure (e.g., 'execute_sql_query' mentions validation but does not say what invalid_query errors look like or how to correct them; 'connect_database' does not explain what happens on auth failure or how to retry).
Ambiguous 'connection' parameter across 25 tools. The parameter is described as 'Connection handle returned by connect_database' but its actual type (string ID? opaque token? serialized object?) is unclear. If it's a string ID, LLMs need to know the format. If it's a session token, they need to know the lifecycle and whether it expires.
Complex object parameters under-specified. 'connection_info' (connect_database) and 'mappings' (apply_semantic_names), 'model_content' (save_semantic_model), and 'triples' (add_rdf_knowledge) are typed as 'object' or 'array' but lack sub-schema documentation. LLMs cannot construct valid nested payloads without knowing required/optional fields and their types.
Generic tool descriptions. 'discover_schema' described as 'Analyze schema with auto GraphRAG + ontology generation', vague on what the output is, when to call it vs. generate_ontology, or what preconditions are needed. 'reachable_from' and 'measurable_from' lack context on use case and output format.
No pagination support visible for list tools (list_schemas, list_semantic_models). No limit/offset/page_size parameters documented. If schemas are numerous, returning all could exhaust context. Baseline rubric: 'Tools returning lists should accept page/offset and limit parameters and return a total count.'
Credential handling opaque. 'connect_database' accepts 'connection_info' as a bare object, no guidance on whether passwords/API keys should be embedded here or injected via environment. Risk: connection_info could expose secrets in agent logs.
Destructive operations lack confirmation pattern. 'cleanup_workspace' (deletes workspace files) and 'reset_cache' (clears cached data) have no documented dry-run or confirmation step.
cleanup_workspacereset_cache
Implement pagination for list_* tools. Add optional parameters: limit (default 20, max 100), offset (default 0). Return {items: [...], total: number, has_more: boolean, next_offset: number} to enable streaming large result sets.
Clarify credential injection pattern. Document whether 'connection_info' should contain raw credentials (bad) or references to secrets (good). Recommend: passwords/keys passed as references to server-managed secrets, never as plaintext in connection_info object.
Add confirmation/dry-run patterns for destructive operations. For cleanup_workspace, add optional dry_run: boolean parameter. Return {files_that_would_be_deleted: [string], count: number} on dry_run=true; on dry_run=false, actually delete and return {deleted_files: [string], count: number}.
Separate GraphRAG tools by intent. Consider consolidating graphrag_search, graphrag_query_context, graphrag_find_join_path into a unified graphrag_query tool with a 'mode' enum (search|context|join_path) to reduce parameter confusion and simplify LLM decision-making.
Add resource references for long-lived artifacts. Tools like generate_ontology and download_artifact should return resource URIs (mcp://resource/ontology/{connection_id}/{timestamp}) so agents can retrieve results asynchronously without re-running expensive generation.