Two tools with partial schemas and descriptions. safe_system_metrics has a reasonable description (127 chars) and detailed input schema with proper types, enums, and constraints. coordinate_grid_calculator has a longer description (165 chars) but its schema is problematic: the 'from', 'to', 'point', 'grid', and 'points' parameters lack type declarations in the visible schema (shown as 'object' with properties but no explicit 'type' field in nested objects). Both tools lack documented output schemas, critical for LLM planning. No error handling guidance, no recovery hints. Parameter descriptions are present but generic. No tool annotations (readOnlyHint, idempotentHint). Naming is acceptable (verb_noun style) but not optimized for LLM disambiguation.

• Document the output schema for each tool. Example for safe_system_metrics: 'Returns {ok: boolean, cpu: {usage_percent: number}, memory: {used_mb: number, total_mb: number}, ...}'. This enables LLMs to extract and chain results.
• Fix coordinate_grid_calculator schema: wrap nested objects with explicit 'type: object'. E.g., 'from': {type: 'object', properties: {x: {type: 'number'}, y: {type: 'number'}}, required: ['x', 'y']}.
• Add tool annotations. Mark both tools with 'readOnlyHint: true' since they do not modify state. This signals to LLMs that retries are safe.
• Enhance error descriptions with recovery guidance. E.g., safe_system_metrics: 'If include_top_processes=true fails on non-Linux, retry with include_top_processes=false or check MCP_ENABLE_PROCESS_SUMMARY environment variable.'
• Add per-parameter constraints. E.g., top_process_limit: 'Integer between 1 and 5. Defaults to 5. Higher values may increase latency.' This prevents LLMs from passing invalid values.

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

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