Static source inference · medium confidence · evidence: Streamable HTTP
Current-spec patterns detected
Summary
Canvas LMS MCP provides 14 well-named, read-only tools with consistent schema structure. All tools have descriptions and explicit input schemas with typed parameters. However, descriptions are generic and lack action guidance (average ~50 chars, below 72-char baseline for param annotations). Parameter descriptions are minimal, most are single phrases like 'Course ID' without explaining when to use the tool or what the agent should expect. Output schemas are completely undocumented; LLMs cannot see what fields to expect in responses. Error handling is absent from visible code. All tools are read-only (low risk), but composition is weak: 14 separate tools with overlapping responsibilities (e.g., get_course, get_course_modules, get_course_syllabus) force agents to reason about which discovery tool to call first. Naming is consistent (verb_noun pattern), but parameter naming could be improved: bare integer parameters like 'course_id' and 'assignment_id' lack context for LLM input validation. No per-tool audit issues detected, but schema quality is uneven.
Output schemas completely undocumented. No return type specifications visible for any of the 14 tools. LLMs cannot plan downstream operations or extract required fields for chaining.
Tool descriptions are generic and lack action guidance. Examples: 'Get a single assignment by ID' (40 chars), 'Get a course's syllabus' (24 chars). None explain WHEN to use each tool, what the LLM should expect, or dependencies on other tools. Below 194-char baseline for tool descriptions.
Document output schemas for all 14 tools. For each, define the structure: field names, types, and descriptions. Example for get_course: 'Returns: {id: integer, name: string, created_at: ISO8601 string, enrollments: array of {user_id, role}, ...}'. This is critical for LLM planning.
Expand tool descriptions to 50 - 200 characters, following the pattern: 'ACTION: [verb phrase]. USE WHEN: [when to call]. RETURNS: [what data]. DEPENDENCIES: [prerequisite tools if any].' Example: 'Fetch a course by ID. Use after list_courses() to explore course details including enrollment status. Returns course metadata, start/end dates, and term info.'
Add full descriptions to every parameter. Do not use bare 'Course ID', explain: 'course_id (integer, required): The Canvas course ID. Obtain via list_courses().' For optional params with enums (bucket, order_by in list_assignments), document the valid values and the semantic meaning of each.
Add enum constraints for course_id and assignment_id parameters if possible, or explain how to discover valid values (e.g., 'course_id must be obtained from list_courses()'). This prevents LLM hallucination of invalid IDs.
Create a composite 'get_course_overview' or 'describe_course' tool that returns course metadata + syllabus + module list in a single call, eliminating the need for 3 sequential lookups. Alternatively, document in each tool description the recommended discovery order.
Document pagination behavior explicitly: 'Returns paginated results with max 100 items per page. Omit page/items_per_page for defaults. Response includes total_count; use to calculate next page_num.' Ensure list_files clarifies the mutual exclusivity of course_id and folder_id.
Parameter descriptions are minimal. Most parameters have single-phrase descriptions like 'Course ID' or 'Assignment ID' with no context for validation, format, or type validation rules. No descriptions explain ranges, constraints, or expected formats.
Weak composition: get_course, get_course_modules, and get_course_syllabus are separate tools that agents must discover and reason about sequentially. This forces multiple round-trips for a common use case: 'show me the course info and syllabus'. Consider a composite tool or better documentation of discovery order.
No error handling guidance. No visible error recovery patterns, retry logic, or actionable error messages. If a tool fails, the LLM has no recovery path documented.
Pagination parameters inconsistent: list_assignments uses 'page' and 'items_per_page', list_courses uses 'page' and 'items_per_page', but list_files uses 'page' and 'items_per_page' with optional course_id/folder_id. No documentation of total_count or next_cursor availability in responses.
list_files accepts either 'course_id' OR 'folder_id' but this mutual-exclusivity is not documented. Parameter descriptions do not indicate that at least one must be supplied, leading to ambiguous LLM invocations.
list_files
Add error recovery guidance to tool descriptions: 'If course_id is invalid, call list_courses() first to find the correct course ID. Returns HTTP 404 with message: Course not found, available course IDs: [list].'
Ensure all parameter types (integer, string, array, enum) are explicitly declared in schemas. The current schemas appear complete, but descriptions should mirror the JSON Schema type to reduce LLM confusion.
Consider adding idempotency hints or read-only annotations if the server supports them. All 14 tools are read-only (safe to retry), so marking them as such would help agents optimize retry strategies.