The GeoGebra MCP server has 8 tools with basic schemas and descriptions, but exhibits significant quality gaps. Tool naming is inconsistent (mixing verb-noun patterns with underscores and suffixes). Most descriptions are present but lack the depth needed for LLM tool selection guidance. Critical issues: (1) Several tools have vague or minimal descriptions (e.g., 'ping' is trivial); (2) Parameter descriptions are missing or incomplete across multiple tools; (3) Output schemas are not documented in the visible code; (4) Error handling guidance is absent; (5) The server relies on internal validation functions whose constraints are not exposed in parameter descriptions. The performance_* tools show better structure (enums, ranges) but lack context on when/why to use them. The core GeoGebra tools (echo, ping, server_info) are utility-level and do not represent meaningful domain functionality. Per-tool scores average 41.6, placing this server in the 'D' tier (Poor).

• Expand tool descriptions to 50 - 200 characters. For each tool, answer: (1) What does it do? (2) When should the LLM call it? (3) What does it return? Example for performance_benchmark: 'Run performance benchmarks on GeoGebra operations (basic math, export, rendering). Use this to measure latency and throughput. Returns test results with duration and operation counts.'
• Document output schemas for all 8 tools. Define what fields each tool returns, their types, and what they represent. Use JSON Schema format or a response example in the description.
• Add descriptions to every parameter. For performance_benchmark's testType enum, describe what each option tests: 'basic: simple math operations | command_execution: GeoGebra command parsing | export_operations: file export performance | all: comprehensive suite'.
• Expose validation constraints in parameter descriptions. Reference the validation functions used internally: For performance_warm_up_pool's count parameter, add: 'Must be between 1 and 3 (up to 3 instances can be pre-warmed). Note: exceeding max will be rejected.'
• Add error recovery guidance. For each tool, document common failure modes and recovery steps. Example: 'If pool is exhausted, try performance_clear_metrics to reset state, then retry.'
• Remove or hide utility tools (echo, ping). These test tools add noise. If kept, move them to a separate 'debug' or 'admin' tool namespace and document that they are not for production agents.
• Create a GeoGebra command/rendering tool. The code references extensive GeoGebra functionality (drawing shapes, equations, animations, exports) but no user-facing tools expose this. Define tools like create_geometry, evaluate_expression, export_figure using the GeoGebraInstance class.

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

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