OpsPilot exposes a single tool, kb_search, with a well-structured input schema and clear description. The tool name follows verb_noun convention (search_*), and the description (169 chars) explains what it does, when to use it, and what it returns (chunk_id, document_id, content, citation block). Input schema is complete with type definitions, required fields, and constraints (top_k: 1-20, default 5). However, the 'query' parameter description is minimal (22 chars) and lacks guidance on expected format or language support beyond 'zh/en'. Output schema is documented in prose but not formally specified in JSON Schema. No error handling guidance is provided for edge cases (empty results, malformed queries, KB unavailable). The tool is read-only and well-scoped, but lacks the depth expected for production-grade tools.

• Add formal JSON Schema output definition documenting the response structure: {type: 'object', properties: {results: {type: 'array', items: {type: 'object', properties: {chunk_id, document_id, content, citation: {source_path, line_start, line_end, heading_path}}}}, total_count: {type: 'integer'}}}
• Expand 'query' parameter description to 50-100 chars: 'Natural-language query in Chinese or English. Describe the SOP/runbook topic you need (e.g., "database failover procedure"). Queries 5-200 chars work best.'
• Add error handling guidance to tool description: 'Returns empty results if no matching chunks found. If KB is unavailable, returns error with retry guidance. Queries with special characters may be sanitized.'
• Document result limits explicitly: 'Returns up to top_k results (default 5, max 20). If more results exist, consider refining your query or increasing top_k. Each result includes a citation block for source attribution.'
• Consider adding complementary tools: kb_list_documents (discover available SOPs), kb_get_document (retrieve full document), kb_upload_document (add new runbooks) to enable richer agent workflows.