The Brightspace D2L MCP server has 13 read-only tools with straightforward names (all verb-prefix using 'get_' or 'download_'). However, the source code provided is incomplete, I can only see package.json, tool-helpers.ts (error handling), and partial server.ts. No actual tool implementation files or schemas are visible. Based on the visible code: 1. NAMING: All tools follow verb-noun convention (get_*, download_*), which is positive. Names are clear and action-oriented (e.g., 'get_upcoming_due_dates' vs vague alternatives). 2. DESCRIPTIONS: Tool descriptions are provided in the server spec above and appear reasonable in length (40-100 chars approx). However, I cannot verify parameter descriptions because no parameter schemas are visible in the source. 3. SCHEMAS: CRITICAL ISSUE, No input/output schemas are visible in the provided source code. The files src/tools/get-todo.ts, src/tools/get-my-courses.ts, etc. are referenced but their content is not included. Without seeing the actual tool registration code and schema definitions, I cannot score parameter types, descriptions, or output schemas. ERROR HANDLING: The tool-helpers.ts file shows thoughtful error sanitization with recovery guidance (e.g., AuthRequiredError returns a login command; RateLimitError suggests waiting; NetworkError hints at connectivity). This is positive, but only applies to the response layer, not parameter validation or tool-specific errors. 5. OUTPUT STRUCTURE: The server returns JSON-formatted responses via toolResponse(), which is structured. However, without seeing actual tool implementations, I cannot assess whether output schemas are documented or whether pagination is properly handled for list tools. SCORING LIMITATIONS: Because the actual tool files are not provided, I must score conservatively. I can infer naming from the tool list and see that error responses are well-designed, but I cannot verify: - Parameter schemas (types, enums, constraints) - Parameter descriptions (required for each param) - Output field documentation - Pagination support for list tools - Whether credentials are properly hidden The visible code (error handling, response shaping) suggests professional engineering, but incomplete source visibility forces a low overall score per the rubric's conservative principle.

• Provide complete tool implementation files (src/tools/*.ts) showing input schemas, parameter descriptions, and output types. Current evaluation is limited to tool names and descriptions.
• Add Zod schema definitions to each tool with explicit parameter types, enums for constrained inputs, and per-parameter descriptions. Example: 'course_id: z.string().describe("Unique course identifier (e.g., 'PHYS101-2024F')")'.
• Document output schemas for each tool. List tools (get_announcements, get_assignments, etc.) must document: total_count, limit, offset/next_cursor, and per-item field types. Singleton tools must document all returned fields.
• Implement pagination support for list tools. Accept 'limit' (default 20, max 100) and 'offset' parameters. Return total_count so LLMs know if more results exist.
• Add tool annotations using the MCP SDK to advertise read-only status: tools.register({name: 'get_todo', ..., annotations: {readOnlyHint: true}}).
• Add parameter descriptions to course_id, assignment_id, user_id, etc. Explain: (a) what the ID represents, (b) whether names/emails are also accepted as alternatives, (c) format/examples if not self-evident.
• Enhance download_file error handling to include available file types and storage limits. Instead of generic 'unsupportedType', return: 'PDF/DOCX/XLSX supported. 50 MB max per file.'
• Add discovery hints to tool descriptions where applicable. E.g., get_assignments: 'List assignments in a course. Call get_my_courses first to get course IDs.'

Inferred effective spec: 2026-07-28+.

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