Descriptions lack LLM-optimization guidance. Most are under 100 characters and omit WHEN to call the tool, WHAT it returns, and prerequisite conditions. For example, 'Perform a semantic search for documentation' does not explain when semantic search is preferred over listByPackage or what fields are returned.

Output schemas are not documented in the visible code. The tools return JSON responses but the structure, field names, types, and cardinality are not declared. LLMs cannot plan downstream tool calls without knowing what fields to expect.

Parameters lack constraints and enums. For example, 'docType' is a free-form string with no enumeration of valid values (e.g., 'function', 'class', 'module'). This invites hallucinated invalid values. Similarly, no regex patterns, ranges, or format specifications guide valid input.

get_selected_elements and clear_selected_elements have empty input schemas (no parameters). The description for get_selected_elements is too brief (under 50 characters) to guide LLM selection. This violates the minimum 10 - 1024 character guideline and the 100% baseline for A+ tool params to have descriptions.

Error handling in source code (src/MicroFoxDocsAssist/server.ts) returns generic error messages without actionable guidance. E.g., 'Error listing by package: <error>' does not tell the LLM whether to retry, ask the user, or fail the task. No error classification (retryable, user-fixable, fatal) is present.

Tool naming uses inconsistent conventions. Some tools use camelCase (listByPackage, semanticSearch) while others use snake_case (get_selected_elements, clear_selected_elements). This inconsistency slows LLM disambiguation and suggests incomplete design review.

Pagination parameters (limit, default=10) are present in listByPackage and semanticSearch but no total_count or next_cursor is documented in output schema. Without a total count or pagination cursor, agents cannot determine if results are truncated or plan for follow-up queries.

The fetch tool accepts a maxLength parameter but the description does not specify the unit (bytes? characters?), the minimum, or the maximum. Similarly, startIndex is undocumented as to what it indexes (characters? bytes? lines?). This ambiguity will cause LLM confusion when slicing content.

Tool clear_selected_elements modifies state (WRITE risk) but has no dry-run or confirmation mechanism. Agents may accidentally clear selected elements. The tool description does not warn of irreversibility or provide guidance for recovery.

No tool accepts natural identifiers (e.g., human-readable function names as fallback). getFunctionDoc requires a functionName string but does not clarify if it accepts partial matches, case-sensitivity, or namespace prefixes. Users say 'get docs for the parseJSON function' but the tool may expect 'module.parseJSON' or 'parseJSON:es5'. This forces unnecessary disambiguation calls.