On-premise database agent for Kyomi — connects your data warehouse securely via WebSocket to the Kyomi platform
Kyomi Connect exposes 4 database query tools with reasonable naming (all verb-noun format: execute_query, test_connection, dry_run). Descriptions are adequate but generic. Input schemas are present and typed, but lack critical detail on constraints, error conditions, and output structure. Parameter descriptions are minimal. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite all tools being read-only. Output schemas are entirely undocumented, no specification of what fields execute_query returns, what the Arrow stream format is, or what test_connection responds with. Error handling and recovery guidance are absent. All tools appear safe (READ_ONLY risk), but the interface lacks the LLM-optimizing patterns expected of production agent tools.
Perform a dry-run validation of a SQL query without executing it fully
Execute a SQL query against the connected datasource and return results as JSON
Execute a SQL query and stream results in Apache Arrow IPC format
Test the connection to the configured datasource
Output schemas completely undocumented. No specification of return types for any tool (e.g., execute_query response format, field names, data types). LLMs cannot plan chaining or extract required fields for downstream calls.
Parameter descriptions are minimal and lack actionable constraints. E.g., 'limit' says 'Maximum number of rows to return (optional)' but omits bounds, default, and behavior when total rows exceed limit. 'offset' lacks pagination semantics.
No tool annotations despite all tools being read-only. MCP 2026-07-28 spec supports readOnlyHint, destructiveHint, idempotentHint to signal safety and retry semantics. This metadata helps LLMs decide whether to retry on transient failures.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 55 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 27 | - | v1 |
No error handling or recovery guidance. No specification of how tools respond to invalid SQL, connection failures, timeout, or authorization errors. LLMs cannot self-correct or know whether to retry.
execute_query_stream_arrow declares Arrow IPC format but provides no documentation of schema or how to parse the stream. LLMs cannot reason about streaming results or know what columns will be present.
'include_total' parameter in execute_query lacks clear semantics. Does it return a separate 'total' field? Is pagination cursor-based or offset-based? Without documentation, LLMs cannot handle large result sets safely.
Tool descriptions are generic and under-optimized for LLM selection. E.g., execute_query says 'Execute a SQL query...and return results as JSON' but omits: when to use vs dry_run, result size limits, SQL dialect support, or prerequisite connection checks.