Related Servers

Descriptions are unusually diligent about carving boundaries (e.g. list_quiz_questions vs get_quiz_question_responses vs list_new_quiz_items, or list_course_users vs list_students vs list_account_users), which rescues a lot. But the sheer number of near-pairs still creates real misselection risk: get_course_structure vs view_course_structure return the same payload, list_discussions vs list_group_discussions vs list_announcements share an index, and the eight get_outcome_* tools plus three gradebook-history tools are hard to tell apart at a glance. New Quiz vs Classic Quiz pairs are distinguished only by remembering which engine a given ID belongs to.

The dominant pattern is a clean snake_case verb_noun convention (list_*, get_*, create_*, update_*, delete_*, search_*, set_*) applied consistently across ~150 tools. Outliers are few and purposeful — project_grade, explain_grade, explain_grading_policy, check_course_setup, audit_course_links, next_appointment, health_check — where the verb is descriptive rather than CRUD. No mixed casing.

185 tools for one LMS integration is an extreme surface that no agent can select from reliably; the context cost alone is prohibitive. Whole clusters (8 outcome tools, 3 gradebook-history tools, 4 quiz-accommodation tools, 4 appointment-group membership tools, account admin tooling) sit far outside a typical instructor/student workflow. This needs aggressive grouping or profile-based subsetting.

Coverage is remarkably broad — courses, assignments, overrides, submissions, rubrics, both quiz engines, files, modules, pages, discussions, enrollments, groups, outcomes, analytics, accounts, calendar, conversations, peer reviews, migrations, Scheduler, and several cross-cutting audit/advisor tools. Gaps are minor and mostly life-cycle: no delete_course, no folder create/delete, no update_file, no Classic quiz creation, and no group-scoped discussion reply or edit.