Two tools with minimal documentation. execute_query has a basic description (89 chars) but lacks parameter descriptions and output schema documentation. vec_ops similarly lacks parameter detail and output structure. Neither tool declares what fields are returned, making it impossible for LLMs to plan downstream operations. No error handling guidance. Parameter descriptions are present but generic ('Target cell name or path' is vague about format/constraints). No enum constraints, no pagination guidance for vec_ops despite returning 'results'. Missing idempotency declarations and security context (are these read-only truly safe for all users?).

• Document execute_query output schema: return {rows: [{col1: any, col2: any, ...}], row_count: int, execution_time_ms: int}. Specify whether NULL values are included and how to interpret empty result sets.
• Add parameter constraints to execute_query: 'SQL query (SELECT/WITH only; max 10000 chars; no INSERT/UPDATE/DELETE)' and 'cell: alphanumeric + underscore, 1-255 chars, e.g. "my_cell" or "path/to/cell"'.
• Document vec_ops output schema: return {results: [{id: string, text: string, similarity: float, metadata: object}], total_available: int, limit_applied: int}. Clarify similarity score range (0-1?).
• Add error recovery guidance: 'If execute_query returns "cell not found", call list_cells() first. If SQL syntax error, check cell schema with describe_cell(). If permission denied, verify user has read access.'
• Rename vec_ops to semantic_search or vector_search to clarify the action. Add description: 'Search embeddings in a cell using semantic similarity. Returns ranked results ordered by relevance score (0-1). Use limit to control result count; default 20, max 100.'