jvmlens provides 9 JVM profiling tools with consistent schemas across 8 of them. All tools have descriptions (10-80 chars, mostly adequate) and input schemas with proper types. However, descriptions are terse and lack LLM-optimized guidance on WHEN to use each tool or HOW they relate. Parameter descriptions are minimal (e.g., 'Path to a .jfr recording' with no format hints). No output schemas are documented, LLMs cannot predict what fields to extract or chain tools. Error handling is absent from visible code. Tool names are domain-specific but lack action verbs (overview, hot_paths, hot_leaves are nouns, not verb_noun patterns). The 'profile' tool stands out with better parameter variety (enums for engine/report), but others are repetitive. No tool annotations (readOnlyHint, destructiveHint) despite all being read-only operations.

• Rename tools to verb_noun pattern: 'overview' → 'analyze_jfr_overview', 'hot_paths' → 'get_hot_paths', 'hot_leaves' → 'get_hot_leaves'. This helps LLMs parse intent from the name alone.
• Expand tool descriptions to 150-250 chars. Include: what problem it solves, when to use it vs. similar tools, and what the output reveals. Example: 'Analyze CPU hotspots in a JFR recording. Returns top call paths by sample share. Use this first to identify which methods consume most CPU time, then drill down with hot_leaves for self-time breakdown.'
• Document output schemas for all tools. Specify field names, types, and what each field represents. Example: 'Returns {paths: [{method: string, samples: int, percentage: float}], total_samples: int}'.
• Add format hints to parameter descriptions. Example: 'Path to a .jfr recording (Java Flight Recorder file, typically 10MB - 1GB)' and 'Application package prefixes as include-only filters (e.g., ["com.myapp", "org.mylib"])'.
• Add readOnlyHint: true to all tool definitions to signal to agents that these tools are safe to retry and have no side effects.