No user-submitted related servers found.
Scored across 20 tools
Most tools map to a single distinct resource (schedule, grades, behavior, fees, documents, messages), and descriptions explicitly cross-reference each other (e.g. ic_download_document takes the url from ic_list_documents, ic_get_message takes the url from ic_list_messages). The main overlaps are ic_list_attendance vs ic_list_attendance_events (one is a per-course term summary, the other individual events with excuse codes and date filters) and ic_list_grades vs ic_list_recent_grades vs ic_list_assignments; descriptions do distinguish them, but an agent must read carefully to pick correctly.
Almost everything follows a strict ic_ + verb + noun pattern (ic_list_*, ic_get_*, ic_download_*), and the shared prefix makes the tool family obvious. The one deviation is ic_healthcheck, which drops the verb_noun shape and reads as a diagnostic noun, but the inconsistency is minor and only affects a single tool.
At 20 tools this is on the heavy side, but each one maps to a genuinely separate Infinite Campus module (schedule, grades, assignments, attendance, behavior, food service, messages, documents, calendar, teachers, assessments, fees, features) plus the district/student/health scaffolding. There is little obvious redundancy, though the two attendance tools and the grades/recent-grades pair could conceivably be collapsed.
The read surface is broad and well covered for a parent portal: roster, grades, assignments, two attendance views, behavior, food service, messages (list + body fetch), documents (list + download), calendar, teachers, assessments, fees, and feature flags, with sensible partial-failure semantics. Gaps are mostly around depth rather than breadth — no per-assignment detail, no student profile/contact tool, and no write operations (submitting work, paying fees, sending messages), which may be intentional but leaves lifecycle dead ends.