Server defines 6 tools with explicit schemas and descriptions. However, descriptions are domain-specific and terse (avg ~80 chars), lacking LLM-optimized guidance on WHEN to use each tool or HOW to interpret results. Parameter descriptions exist but are minimal ('Narrative manifest JSON text'). No output schemas documented. Tools lack error recovery guidance. Naming is consistent (verb_noun pattern) but domain-jargon-heavy ('narrative_ledger_*', 'dsh_narrative_ledger_*'), which may confuse LLMs unfamiliar with narrative ledger concepts. No tool annotations (readOnlyHint, destructiveHint). One tool (dsh_narrative_ledger_verify) is marked WRITE but lacks confirmation/dry-run pattern.

• Document output schemas for all 6 tools. Example: 'Returns {facts: [{id, predicate, subject, object, canon_hash}], character_knowledge: {[char_id]: [fact_ids]}}'. This enables LLMs to chain tools and extract required fields.
• Expand descriptions to 150 - 250 chars. Add WHEN guidance: 'Use this to inspect manifest structure and entity/predicate schema. Call before verify_inline to validate manifest format. Returns no prose, only structural metadata.'
• Add tool annotations to mcp-server.mjs. Mark narrative_ledger_* tools with readOnlyHint: true. Mark dsh_narrative_ledger_verify with destructiveHint: true and idempotentHint: false to signal that retries risk duplicate reports.
• Implement dry-run for dsh_narrative_ledger_verify. Add optional 'dryRun' boolean parameter (default false). When true, return verification results without writing artifacts. This prevents accidental state changes.
• Enhance parameter descriptions with constraints and error recovery. Example: 'manifestPath: Workspace-relative path to .json manifest file (required, must exist). If file not found, error will suggest available manifests in workspace.'