Server has 23 tools with complete input schemas and descriptions present for all. Naming follows verb_noun convention (async_read, async_write, async_delete). However, descriptions are generic and lack LLM-optimized guidance on WHEN to use each tool vs. alternatives. Parameter descriptions exist but are minimal (avg ~40 chars vs. baseline 72). No output schemas documented. Error handling is present but lacks recovery guidance. Batch tools (async_batch_read, async_batch_update, async_batch_write) are well-composed, but transaction tools (async_commit, async_amend, async_abort, async_txn_status) lack context on transaction lifecycle and prerequisites.

• Document output schemas for all tools. Specify response fields, types, and pagination (e.g., async_list returns {items: [{path, size, type}], total: int, next_cursor?: string}). This enables LLMs to chain tools and extract correct data.
• Expand transaction tool descriptions to explain lifecycle: 'Start a transaction with async_write/async_delete, then call async_commit to persist or async_abort to discard. Use async_txn_status to check pending changes.' Include error recovery (e.g., 'If async_commit fails, call async_abort to release locks.').
• Rewrite descriptions as LLM-optimized prompts (50-200 chars). Example: 'Read file contents. Use for single files; call async_batch_read for multiple. Returns error if file missing, try async_search() first.' Include WHEN/WHY context and cross-references.
• Add error recovery guidance to tool descriptions. E.g., async_delete: 'Deletes files permanently (or to recycle bin if to_recycle=true). If path not found, try async_search() to verify it exists. Errors are retryable unless path is invalid.'
• Specify per-item error handling for batch tools. E.g., async_batch_read: 'Returns {items: [{path, content, error?}], failed_count: int}. Partial failures are allowed, agent can retry failed items individually.'

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry