The server exposes only a single tool 'ping' with a trivial implementation. The tool has a minimal description ('Reply with pong') that is under 20 characters and provides no actionable context for LLM selection. No parameter descriptions exist. The tool does not follow verb_noun naming conventions (should be 'send_ping' or similar). No output schema is documented. This is a minimal proof-of-concept MCP server, not a production tool surface. The codebase shows infrastructure for a real NTU COOL Canvas-LMS client (cool-api, cool-tools, cool-cli), but the MCP surface is essentially a stub.

• Expand the tool description to 50 - 200 characters explaining what the tool does and when to use it. Example: 'Check server health and connectivity. Returns pong if the MCP server is running and responsive.'
• Document the output schema. Specify what fields the response contains (e.g., { 'status': 'string', 'timestamp': 'ISO 8601 string' }).
• Rename 'ping' to a more descriptive action verb, such as 'check_server_health' or 'verify_connectivity'.
• Expose the real NTU COOL Canvas-LMS tools from cool-tools (e.g., list_courses, get_assignments, download_file, search_announcements). The infrastructure exists but is not wired into the MCP server.
• Add parameter descriptions and type constraints for any future tools. Use enums for fixed sets of values (e.g., course_type: ['lecture', 'lab', 'seminar']).

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

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