Skip to main content
Glama
Sign In
infinitecampus-mcp

infinitecampus-mcp

by chrischall
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

ic_list_school_days

Read-only

List a student's instructional calendar by term, showing term start/end dates, school days, labelled days off, and comments like early release or holiday. Filter by date range.

Instructions

List a student's school days (instructional calendar) grouped by term. Returns one entry per enrollment, with term boundaries (Q1-Q4 start/end dates) and the school days inside each term — a day carries comments when the calendar labels it (e.g. 'Early Release Day'). Each enrollment also lists its labelled daysOff (e.g. 'Holiday', 'Teacher Work Day', 'Spring Break'), including breaks that fall between terms. Use since/until to narrow the range. An enrollment whose day list the district won't serve comes back with warning 'SchoolDaysUnavailable' (plus campusVersion when known), its terms and days off, and no school days.

Input Schema

NameRequiredDescriptionDefault
viewNoResponse shape: "compact" (default) drops fields the response already carries elsewhere; "full" returns every field this server understands. compact strips image/avatar URLs from the response; "full" returns Infinite Campus's payload untouched. No field projection: this server has no verified record of which Infinite Campus fields matter, and inventing one would risk dropping a field a caller needs.
sinceNoYYYY-MM-DD; include only days on or after this date
untilNoYYYY-MM-DD; include only days on or before this date
districtYes
studentIdYesStudent personID from ic_list_students

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv3.2.1
    • addedInput schema / properties / since / format
      Added value: +"date"
    • addedInput schema / properties / since / pattern
      Added value: +"^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))$"
    • addedInput schema / properties / until / format
      Added value: +"date"
    • addedInput schema / properties / until / pattern
      Added value: +"^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))$"
  2. Changed1 schema field changedv3.0.0
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  3. Addedv2.8.3

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only carry readOnlyHint/openWorldHint, so the description does the heavy behavioral lifting: it discloses the grouped-by-term response shape, that days carry comments when labelled, that labelled daysOff (including between-term breaks) are attached, and the exact 'SchoolDaysUnavailable' warning path with campusVersion. This is rich edge-case disclosure beyond what annotations provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The response-shape detail is front-loaded and each sentence carries distinct information (structure, comments, daysOff, range filter, warning case). It is dense and long, but nothing is redundant; a slight trim of the parenthetical examples would tighten it.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and an openWorld read tool, the description fully compensates by describing the returned entries, term boundaries, daysOff, labels, and the unavailability warning. An agent has everything needed to interpret the result correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 80% (view enum and since/until formats documented in the schema), so a 3 is the baseline. The description adds meaning by explaining that since/until bound the day range, and studentId's schema already points at ic_list_students. It does not add anything for view/district beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('List a student's school days (instructional calendar)') and distinguishes itself from siblings like ic_list_attendance by scoping to the instructional calendar grouped by term. An agent can identify exactly what this returns without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear context ('Use since/until to narrow the range') and implies the read-only listing use case, but never names an alternative sibling (e.g. ic_list_attendance) or states when NOT to use this tool. Clear usage without explicit exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools