Server provides 7 read-only tools with consistent naming (verb_noun pattern) and reasonable descriptions (avg 120 chars). All tools have input schemas with Zod validation. However, parameter descriptions are sparse or missing entirely for several tools (list_docs has empty schema; search_docs lacks query format guidance). Output schemas are not documented, LLMs cannot predict response structure. Error handling is minimal (no recovery guidance, no actionable error messages). Security is solid (read-only, path validation), but composition could be tighter (search_docs and search_corpus overlap in intent).

• Document output schemas for all tools. Example: 'Returns {content: [{type: "text", text: string}]}' or structured list with fields like doc_id, path, package, topic.
• Expand search_docs description to include format constraints: 'Case-insensitive substring match over file paths. Query must be 1-100 characters. Returns up to 100 matches sorted alphabetically.'
• Add error recovery guidance to read_doc and read_corpus_doc: 'If path not found, try search_docs(query) or list_docs() to discover valid paths.'
• Disambiguate search_docs vs search_corpus in descriptions. E.g., search_docs: 'Search repository file paths (skills/, guides/, etc.)' and search_corpus: 'Search normalized SolidJS API corpus with metadata ranking.'
• Add per-tool examples in descriptions showing typical use cases and expected output structure (without hardcoding example values that LLMs might reuse literally).