Ollqd provides 5 tools with visible input schemas and descriptions. All tools have descriptions (10-100+ chars) and typed JSON Schema parameters. However, multiple quality issues prevent a higher score: (1) Output schemas are undocumented, the rubric requires documented return types for A+ tools, and none are specified in the tool definitions. (2) Error handling lacks guidance, tools do not document recovery paths, error classification, or actionable messages. (3) Parameter descriptions lack detail on constraints, ranges, and format requirements. (4) Some tool names are compound actions (e.g., 'index_codebase' + 'index_documents' show near-duplication of concerns without clear differentiation). (5) Critical security concerns: 'delete_collection' is a destructive operation without adequate safeguards, the 'confirm' boolean is a weak protection pattern vs. proper confirmation flow. (6) Semantic search lacks pagination parameters (top_k=5 default suggests results are capped, but no mention of offset/cursor for traversing beyond top 5). These are typical C-grade issues: schemas present but incomplete, descriptions generic, limited error guidance.

• Document the return schema for each tool. E.g., semantic_search should specify: 'Returns an array of objects, each with {score (float), file_path (string), snippet (string), line_numbers (object with start/end)}.' Include all fields the LLM might need for downstream actions.
• Add 'errors' or 'error_handling' section to each tool definition documenting: (a) what error conditions can occur, (b) whether they are retryable, (c) what the LLM should do next. E.g., 'If root_path does not exist: error 'path_not_found'. Action: verify path exists or call list_collections to see available targets. Retryable: yes after path correction.'
• Replace the 'confirm' boolean in delete_collection with a two-step workflow: (1) add a tool 'confirm_delete_collection' that requires explicit user consent via a confirmation message, OR (2) document that deletion is irreversible and the agent should ask the user first before calling delete_collection.
• Expand parameter descriptions to include constraints. E.g., 'chunk_size: integer, 64-2048 tokens (approximate; ~4 chars per token). Larger chunks reduce retrieval precision; smaller chunks increase indexing overhead. Default 512 recommended for most codebases.' Similar detail for all numeric/enum parameters.
• Add pagination to semantic_search: (a) change top_k to 'limit' with default 20, (b) add 'offset' parameter (default 0), (c) return 'total_results' and 'has_more' in response to enable LLM iteration.
• Clarify the distinction between index_codebase and index_documents. If indexing a codebase of Python files vs. markdown documentation, which tool is correct? Add a decision guide: 'Use index_codebase for source code and code-related files (*.py, *.go, *.js, etc.). Use index_documents for human-written docs, READMEs, and markdown. If in doubt, use index_documents.'