Each tool targets a distinct step in a browsing workflow: listing courses, dumping a course's structure, searching that structure, and reading a specific item. The main risk is get_course_contents vs search_course_contents, but descriptions clarify that one returns the full visible outline and the other searches name/description fields only. read_content is clearly the terminal action for a specific activity or resource.

All four names follow a consistent snake_case verb_noun pattern: list_courses, get_course_contents, read_content, search_course_contents. The verbs are conventional and predictable for the actions they represent, with no mixed conventions or vague names.

Four tools is on the lean side but well-scoped for a read-only LMS browsing server; each tool (list, outline, search, read) earns its place without redundancy. It is slightly thin compared with richer LMS surfaces, but not a mismatch for the stated browsing purpose.

The surface covers the full read-only discovery lifecycle: list enrolled courses, inspect course structure, search the index, and read individual activities/resources with pagination. Minor gaps remain (no user/profile or grade overview, and write actions are explicitly excluded), but core browsing workflows have no dead ends.