KGFlow exposes 10 tools via FastMCP with basic descriptions and parameter types, but lacks depth in LLM-optimization. All tools have descriptions (10-100 chars, mostly under 50), and parameters include types and some descriptions. However, descriptions are terse and lack actionable context (e.g., 'Find all methods/classes/config affected' doesn't explain WHEN to use this vs. call_chain). No output schemas documented. Error handling delegates to subprocess stderr parsing with minimal recovery guidance. Parameter descriptions are sparse (e.g., 'Query depth (default: 3)' lacks range/rationale). No enum constraints on direction/label parameters. Tools follow verb_noun naming (kgflow_query_*, kgflow_generate) but lack clarity on mutual exclusivity (e.g., kgflow_diff accepts from_latest OR from_run, undocumented). Composition is sound, each tool has one responsibility, but chaining is unclear (no documented output fields to feed downstream calls).

• Document output schemas for all tools. Example: kgflow_query_impact should return {affected_methods: [{name, type, impact_score}], total_count, query_time_ms}. This enables LLMs to chain tools and extract the right fields.
• Expand parameter descriptions to 50-100 chars with actionable context. E.g., 'depth: Query depth (1-10, default 3). Higher values trace deeper call chains but increase latency. Use 5+ for impact analysis across layers.'
• Rewrite tool descriptions to include WHEN/WHY. E.g., kgflow_query_impact: 'Find all methods, classes, and config affected by changing given methods. Use this to assess blast radius before refactoring. For call chains, use kgflow_query_call_chain instead.'
• Add enum constraints to direction parameter in kgflow_query_call_chain: direction: {type: 'string', enum: ['up', 'down'], description: 'Direction: up (callers) or down (callees)'}.
• Implement error classification in _run() helper. Return {error: true, code, detail, retryable: bool, guidance: 'Try X next'} so LLMs know whether to retry, ask user, or abort.