Server exposes 22 tools with significant definition gaps. Most tools lack proper input schemas (only 6 of 22 have visible, complete JSON Schema definitions with types and descriptions). Descriptions are present but often generic (avg ~80 chars, below 194-char baseline). Parameter descriptions are sparse or missing entirely. No output schemas documented. Error handling is absent from tool definitions. Tool naming is inconsistent: some use verb_noun (search, ingest), others use REST paths (documents/:id, license/validate). Several tools combine multiple concerns (ingest/batch, reflect/batch, mcp/tools + mcp/call). No evidence of idempotency, pagination, or recovery guidance in definitions.

• Rename all REST-style tools to verb_noun format: delete_document, update_document_metadata, validate_license, create_license, list_licenses, revoke_license, get_stats, get_public_stats, get_openapi_spec, list_mcp_tools, call_mcp_tool, run_benchmark, get_benchmark_results.
• Document output schemas for all tools. Specify which fields are returned, their types, and which are required for downstream tool calls. Example: search returns [{document_id, chunk_id, score, content, metadata}].
• Split composite tools: ingest_batch should be separate from ingest; reflect_batch should be separate from reflect; mcp_tools and mcp_call should remain separate (discovery vs execution).
• Add error handling guidance to descriptions: 'On failure, returns error code and recovery hint. Retryable errors: timeout, rate_limit. User-fixable: invalid_license_key (try validate_license first). Fatal: permission_denied.'
• Add confirmation/dry-run support to destructive tools. Example: delete_document should accept a dry_run=true parameter that returns 'Would delete document X with Y chunks' without executing. Require explicit confirmation for irreversible operations.