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

The description discloses a specific failure mode: 'Returns FeatureDisabled if the district has the module turned off.' With destructiveHint=true already present, the description adds useful error-condition context beyond the annotation without contradicting it.

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

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

Three sentences, each earning its place: the action is front-loaded, documentId provenance is clarified, and a relevant error is disclosed. No filler or redundant restatement.

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

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

For a side-effecting tool with destructiveHint=true and no output schema, the description covers the main action and one notable error but leaves overwrite semantics and district selection implicit. This is functional but has clear gaps an agent would need to resolve.

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

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

Schema description coverage is 50%, so the description must compensate for under-documented parameters. It clarifies documentId's provenance, but district and overwrite receive no additional semantic guidance beyond their bare schema types.

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

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

States a specific action ('Download'), a specific resource ('a student's document (PDF)'), and a target ('to disk'). It further ties documentId to ic_list_documents, making the tool's role distinct from the list-oriented siblings.

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

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

The description clearly implies this is the follow-up to ic_list_documents by explaining that documentId comes from that tool's url field. It does not explicitly name alternatives or state when not to use it, but the workflow context is clear.

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

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

Annotations only declare readOnlyHint=true, so the description carries the burden of explaining behavior. It clearly states that false means the feature is disabled, while true or missing means available, and describes the per-enrollment structure. This adds meaningful interpretive behavior beyond the annotation with no contradiction.

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

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

Three sentences, each with a distinct job: what the tool lists, how to interpret the flag values, and when the LLM should use it directly. No filler or redundancy.

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

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

With no output schema, the description appropriately supplies return semantics: enrollments have features objects, values are booleans, and missing means available. The detailed view parameter schema covers projection behavior. It does not mention errors or edge cases, but for a simple read-only capability lookup this is largely sufficient.

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

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

Schema description coverage is 67% (view and studentId are documented), so the baseline is 3. The description adds the per-enrollment context that helps explain studentId and references the district, but it does not document the district parameter format or otherwise compensate for the uncovered parameter.

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

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

Opens with a specific verb and resource: 'List the district's displayOptions feature-flag allow-list for each of a student's enrollments.' It explains the data model (map of ~90 flags to booleans) and distinguishes itself from sibling data-list tools by noting it is exposed for capability questions rather than direct student data retrieval.

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

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

The description gives clear usage context: the tool is used internally to short-circuit disabled features, but exposed so the LLM can answer capability questions directly. This implies when to call it, though it does not explicitly name alternatives or define when not to use it.

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

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

Beyond the readOnlyHint: true annotation, the description candidly warns that fetching may mark the message as read on some district configurations and that the side effect could not be confirmed. This is valuable behavioral context that the annotation alone would not provide.

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

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

Three sentences with no filler: the purpose is front-loaded, the input source and accepted URL forms are next, and the side-effect caveat is last. Every sentence earns its place.

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

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

For a single-message fetch with no output schema, the description provides the parsed return shape, the source of messageUrl, accepted URL forms, and an important side-effect warning. The only notable gap is the unexplained district parameter, which is a minor omission given it is a common campus-wide parameter.

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

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

The schema already describes messageUrl and view thoroughly, and the description largely repeats the messageUrl guidance without adding new meaning. The required district parameter has no description in either the schema or the description, and at 67% schema coverage the description should have compensated for that gap but does not.

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

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

The description opens with 'Fetch the HTML body of an inbox message and return it parsed into { subject, date, body, url }' — a specific verb, resource, and return shape. It clearly distinguishes itself from ic_list_messages by focusing on a single message body rather than listing messages.

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

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

The description clearly states the prerequisite workflow: messageUrl comes from the `url` field in ic_list_messages' inbox section, and it documents accepted URL forms. It does not explicitly list when-not alternatives, but no confusing sibling exists and the list-then-get sequence is strongly implied.

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

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

The readOnlyHint annotation already establishes that this is a safe read operation, and the description does not contradict it. It adds a small behavioral detail (the default date being today), but it does not describe output shape, error behavior, or how view and termFilter affect results. With annotations lowering the bar, this is acceptable but not rich.

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

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

The description is a single 12-word sentence with the action front-loaded. It contains no filler, no repetition of schema details, and every word contributes to the core purpose.

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

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

Given the fully documented schema and the readOnly annotation, the description is sufficient for the obvious invocation path, but without an output schema it does not clarify what fields the schedule response contains. It also relies entirely on the schema to communicate that district and studentId are required and where they come from, making it adequate but not complete on its own.

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

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

Schema description coverage is 100%: date, view, district, studentId, and termFilter each have meaningful schema descriptions, including the compact/full semantics for view. The tool description adds no meaningful parameter-level meaning beyond the schema, so the baseline of 3 applies.

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

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

The description states a specific verb ('Get'), a specific resource ('a student's class schedule'), and a scoping parameter (date, defaulting to today). This clearly distinguishes it from the list-oriented sibling tools like ic_list_assignments, ic_list_grades, and ic_list_school_days, none of which target schedule retrieval.

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

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

The description supplies a clear context: use this when you need a student's class schedule for a date, defaulting to today. There is no competing schedule tool among the siblings, so no explicit exclusion is necessary, though it does not enumerate alternatives or when-not-to-use cases.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds valuable behavioral context: it makes one authenticated request, reports round-trip time, and explicitly states it never returns the credential. This goes beyond the annotations without contradicting them.

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

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

The description is slightly verbose with an awkward phrase ('a your Infinite Campus portal-side problem'), but every sentence contributes information: what it does, what it reports, read-only nature, and when to call. It is front-loaded with the core behavior.

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

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

With no output schema, the description adequately describes what is reported: credential source, acceptance, round-trip time, and a hint. It covers the key aspects an agent needs to interpret the tool's output. Some details like error handling are not mentioned, but they are less critical for a healthcheck.

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

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

The tool has zero parameters, and the schema is empty. The baseline for 0 params is 4, and the description correctly focuses on the operation rather than parameters, so no further explanation is needed.

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

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

The description clearly states the tool's function: it resolves the credential, makes one authenticated request, and reports on credential source, acceptance, round-trip time, and a plain-English hint. It is distinct from sibling tools that list or retrieve specific data (e.g., ic_list_students, ic_get_schedule).

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

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

Explicitly instructs when to use: 'Call this when a real tool fails and you want to know which hop broke.' This provides clear context and differentiates from siblings, which are for data retrieval.

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

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

Annotations declare readOnlyHint=true, and the description complements this by revealing important behavioral details: calendarID is auto-resolved from each enrollment, one entry is returned per enrollment, and field shapes vary by district/test type with pass-through. This goes beyond the annotation without contradicting it.

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

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

Two sentences carry substantial meaning: the first states the core purpose, the second discloses response granularity and variability. No wasted words; the critical behavioral info is front-loaded.

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

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

With no output schema, the description reasonably covers return semantics (one entry per enrollment, pass-through of variable fields). It also surfaces the key hidden behavior of auto-resolving calendarID. A small gap remains around empty responses or error handling, but given the tool's read-only simplicity, the description is sufficiently complete.

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

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

Schema coverage is 67% with a detailed description for 'view' and 'studentId', but 'district' is required and undocumented in both schema and description. The description's mention of auto-resolving calendarID clarifies how studentId is used, but it does not fully compensate for the missing district semantics.

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

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

The description uses a specific verb ('List') and resource ('a student's standardized test scores'), naming state, national, and district tests. It clearly conveys what the tool does, though it does not explicitly distinguish it from sibling tools like ic_list_assignments or ic_list_grades.

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

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

The purpose strongly implies when to use this tool (when standardized test scores are needed), and the description adds context about auto-resolving calendarID per enrollment. However, it does not explicitly state when not to use it or point to an alternative, so usage guidance is merely implied rather than explicit.

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

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

The annotations already declare readOnlyHint=true, so no contradiction. The description adds useful behavioral context beyond that: the endpoint returns the full term history (~hundreds of items) and that since/until/missingOnly filtering is client-side. This is exactly the kind of behavior that affects invocation choices.

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

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

Three tightly-written sentences with no filler. The first sentence states the core purpose, the second surfaces the key behavioral caveat, and the third gives the cross-tool parameter pointer. Everything earns its place.

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

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

For a read-only tool with no output schema and seven parameters, the description covers the main purpose, data volume, client-side filtering behavior, and the non-obvious courseId mapping. It does not detail the response shape or error conditions, but the schema's view parameter already says much about the response, so this is a minor gap.

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

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

With 71% schema description coverage, the description still adds meaning beyond the schema: it explains that filters are applied client-side and identifies courseId as the sectionID from ic_get_schedule. However, district and studentId remain only minimally explained as required fields.

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

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

The description opens with 'List a student's assignments,' a specific verb and resource. It also differentiates itself from the many sibling list tools by naming the resource type and mentioning courseId, which is enough to distinguish it from ic_list_assessments, ic_list_grades, and other list tools.

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

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

The description gives clear context: pass courseId to narrow to a single course, and warns that date/missing filters are applied client-side, so the caller can expect a large payload. It does not explicitly name alternatives or conditions to avoid this tool, but the usage context is unambiguous.

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

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

Annotations already declare readOnlyHint=true, which the description does not contradict (it uses 'List', a read operation). The description adds valuable behavioral context beyond annotations: it auto-resolves enrollmentID from the student record, which could affect failure modes, and it groups results by term. This enriches the agent's understanding of the operation.

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

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

The description is a single, efficient sentence that front-loads the core purpose and immediately follows with the key behavioral nuance (auto-resolving enrollmentID). No filler or redundant information. Every word earns its place.

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

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

For a read-only list tool with no output schema, the description covers the essential behavior: what data is returned (absences/tardies), the aggregation (per-course, by term), and a critical internal step (enrollmentID resolution). Combined with schema details for filters and view, this is sufficiently complete, though it does not describe return field structure or any limits, which are less critical here.

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

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

Schema description coverage is 60% (view, since, until have descriptions; district and studentId do not). The tool description does not add parameter explanations beyond the schema. Since coverage is moderate and the two undocumented parameters are self-explanatory by name, the baseline of 3 is appropriate.

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

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

The description states a specific verb ('List'), a resource ('a student's absences and tardies'), and adds a distinguishing detail ('per-course summary grouped by term') that sets it apart from sibling tools like ic_list_attendance_events. It also mentions auto-resolving enrollmentID, hinting at internal behavior, making the purpose unmistakable.

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

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

The description implies usage for summary-level attendance data ('per-course summary') but does not explicitly mention when to prefer this over alternatives like ic_list_attendance_events or other list tools. There is no 'when-not' guidance or naming of alternatives, so the context is clear but not explicit.

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

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

The annotations already declare readOnlyHint=true, so the description does not need to restate safety. It adds useful behavioral context by noting that enrollmentID is auto-resolved from the student record and by disclosing the event fields returned. It does not mention ordering, pagination, or rate limits, but for a read-only list this is a minor omission.

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

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

Three purposeful sentences: the first states the tool's core purpose, the second describes the output content, and the third covers key behaviors and filtering. There is no filler, tautology, or unnecessary repetition of annotation data.

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

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

Given the absence of an output schema, the description compensates by naming the key event fields (code, description, excuse reason, comments). It also clarifies the auto-resolution behavior and available filters. Minor missing details like default date range and ordering do not block an agent from calling it correctly.

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

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

Schema description coverage is 83%, so the schema already documents most parameters well. The description reinforces the meaning of since/until and excusedOnly but adds little beyond what the schema states. No new parameter-level insight is provided beyond restating filter intent.

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

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

The description states a specific verb ('List') and resource ('individual attendance events'), enumerates the event types (absences, tardies, early releases), and scopes it to a single student. This clearly distinguishes it from siblings like ic_list_attendance by emphasizing event-level detail.

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

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

It gives clear context: use this tool when you need student-level attendance events with codes, excuse reasons, and comments, and it tells the caller how to filter via since/until and excusedOnly. However, it does not explicitly exclude alternatives or state when a sibling like ic_list_attendance should be preferred.

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

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

Annotations already mark readOnlyHint=true, establishing the read-only safety profile. The description adds a meaningful behavioral detail beyond that: it returns FeatureDisabled when the behavior module is disabled, including the detection mechanism. No contradiction with annotations.

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

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

The description is two compact sentences with the purpose front-loaded and the error condition stated efficiently. Every clause adds information, and there is no filler or redundancy.

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

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

No output schema exists, yet the description does not explain the success response shape or the fields of behavior events/referrals. It also leaves since/until semantics and required identifier formats undocumented, so an agent must infer important call details. The FeatureDisabled note is useful but does not close these gaps.

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

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

Schema description coverage is only 20%, covering just 'view', while the description adds no meaning for since, until, district, or studentId beyond their names. With low schema coverage, the description needed to compensate for the undocumented parameters and did not.

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

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

States a specific verb ('List') and a distinct resource ('a student's behavior events / referrals'), making the tool's purpose immediately clear. The resource itself distinguishes it from sibling list tools like ic_list_assessments and ic_list_attendance.

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

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

The description implies it should be used when behavior events or referrals are needed, and it flags the module-off condition. However, it does not explicitly state when to prefer this tool over alternatives or provide exclusionary guidance.

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

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

The readOnlyHint annotation already signals a safe read operation, and the description adds useful behavioral context: it returns only names and base URLs and explicitly states that no credentials are exposed. This goes beyond the annotation by clarifying the non-sensitive nature of the response.

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

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

Two short sentences deliver the purpose, scope, and return content with zero filler. The key action is front-loaded, and the clarifying note about credentials adds real value without bloating the description.

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

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

For a simple read-only list tool with one optional, fully documented parameter and no output schema, the description is complete. It names the resource, the return contents, and the safe scope, so an agent has enough to invoke it correctly.

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

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

Schema description coverage is 100%, and the only parameter, view, is fully documented in the schema with detailed semantics for 'compact' and 'full'. The tool description does not need to repeat parameter details; the baseline of 3 applies because the schema carries the parameter-semantic load.

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

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

The description states a specific verb and resource ('List Infinite Campus districts configured for this MCP server') and immediately tells the caller what to expect ('Returns names + base URLs (no credentials)'). This clearly distinguishes it from sibling list tools such as ic_list_students or ic_list_assessments.

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

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

The description provides clear context: this tool enumerates the districts this server is configured for, which implies its use for discovering available districts. It does not explicitly name exclusions or alternatives, but none are needed since sibling tools target different resources.

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

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

The annotations already declare readOnlyHint=true, so the description adds meaningful behavior beyond that: it returns metadata only, and it states a concrete failure mode ('Returns FeatureDisabled if the district has the module turned off'). This gives the agent useful expectations about response semantics and error conditions.

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

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

Two sentences carry the full definition with no filler. The primary action and scope are front-loaded, the sibling routing is included, and the error condition is stated compactly.

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

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

For a simple read-only list tool with annotations and a partially documented schema, the description covers the essential behavior, the metadata-only return nature, and the feature-toggle error. It does not detail the exact response shape, but without an output schema the examples and sibling distinction provide sufficient calling context.

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

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

Schema description coverage is only 33%, and the description does not compensate for the undocumented district and studentId parameters. It implies studentId via 'a student's available documents' but gives no guidance for district values. The view parameter is already well covered by the schema, so the description adds no parameter-level value.

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

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

The description uses a specific verb and resource: 'List a student's available documents' with clear examples (report cards, transcripts, schedules). It also distinguishes itself from the file-fetching sibling by stating 'Returns metadata only — use ic_download_document to fetch the file.'

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

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

The description explicitly routes file-fetching use to ic_download_document, which clearly separates metadata listing from content download. It doesn't enumerate exclusions for the other list siblings, but the resource type and 'metadata only' qualifier make the intended context clear.

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

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

The description goes well beyond the readOnlyHint annotation by disclosing the dual-endpoint behavior, the FeatureDisabled outcome when both endpoints 404, and the PartialSuccess warning with issues[] when only one endpoint fails. This gives the agent concrete failure-mode expectations.

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

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

Three tight sentences front-load the core purpose, then add the endpoint composition and failure semantics without redundancy. Every sentence adds value.

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

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

The description covers purpose, endpoint combination, and partial-failure behavior, which is substantial given no output schema. It could be slightly more explicit about the exact shape of the returned data, but the mention of fee assignments and totalSurplus provides adequate context for a straightforward list operation.

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

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

With 67% schema description coverage, the description does not add meaningful parameter-level guidance beyond the schema. The `view` parameter is extensively documented in the schema, and `studentId` is explained there too, but the description itself contributes nothing about parameters such as `district`, leaving that parameter under-specified.

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

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

The description states a specific verb ('List') and resource ('a student's fee assignments (charges owed) and running balance/surplus'), making it immediately distinct from sibling tools like ic_list_assignments. It also clarifies the combined nature of the operation by naming both underlying endpoints.

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

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

The usage context is implied: an agent should call this when it needs a student's fee assignments or balance/surplus. However, it does not explicitly state when not to use it or reference any alternative tool, so some inference is required.

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

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

The readOnlyHint annotation already declares the operation is safe. The description adds valuable behavioral context beyond that by disclosing the FeatureDisabled response when the module is off, including the detection mechanisms ('displayOptions or a 404 backstop'). This helps the agent handle an important edge case.

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

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

Two sentences with no filler. The main action and resource are front-loaded, and the second sentence covers the FeatureDisabled edge case efficiently.

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

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

This is adequate for a simple read-only list, and the FeatureDisabled edge is covered. However, with no output schema and undocumented since/until parameters, the agent must infer date-range semantics and the normal response shape on its own.

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

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

Schema description coverage is only 20%, with since, until, district, and studentId left undocumented. The description mentions the student and district in prose but adds no detail about date formats, bounds, or identifier semantics, so it does not compensate for the low schema coverage.

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

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

The description uses a specific verb, 'List', and a clear resource, 'a student's lunch balance and recent food-service transactions.' It is immediately distinguishable from sibling tools like ic_list_fees or ic_list_recent_grades because it names the food-service domain explicitly.

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

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

The description makes the tool's context clear: it is for food-service lunch balances and transactions. It does not explicitly name alternatives or say when not to use it, but the resource is specific enough that an agent can infer appropriate use.

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

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

The readOnlyHint annotation already communicates that this is a safe read operation, and the description is consistent with that. It adds a little context by mentioning both term grades and in-progress course grades, but it does not disclose pagination, empty-result behavior, or response-shape details beyond what the view parameter already covers.

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

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

The description is a single, front-loaded sentence with no filler. It states the action and the resource immediately, making it easy to scan.

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

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

For a simple read-only list tool with a readOnlyHint annotation, the core invocation is mostly clear from the required parameters. However, the lack of differentiation from ic_list_recent_grades and the absence of any termId guidance leave a meaningful gap for tool selection and correct filtering.

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

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

Schema description coverage is only 25%, with only 'view' fully documented. The short description gives some context for studentId and termId ('a student's term grades'), but it does not clarify the meaning of in-progress course grades, whether termId is a filter or required for some modes, or what district refers to beyond its name.

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

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

The description names a specific action ('List') and a clear resource ('a student's term grades and in-progress course grades'), so an agent can tell what the tool returns. However, it does not differentiate this from the closely named sibling ic_list_recent_grades, leaving some ambiguity about which grade-list tool to prefer.

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

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

There is no guidance about when to use this tool versus alternatives such as ic_list_recent_grades, ic_list_assignments, or ic_list_assessments. The description also does not explain when termId should be provided despite it being optional in the schema.

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

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

Annotations already mark readOnlyHint=true, and the description adds valuable behavioral nuance: listing normally does not mark messages as read but some district configs may update read-tracking. It also discloses partial failure behavior, per-section error fields, and that limit only caps prism notifications. This goes well beyond the annotation alone.

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

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

The description is dense but efficient: scope, source breakdown, response shape, error behavior, limit semantics, read-tracking caveat, and alternative tool are all covered in three sentences. There is no filler or repetition of schema details.

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

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

With no output schema, the description appropriately explains section counts/items, error-field behavior, and content types including newMessage/actionRequired flags. It also names ic_get_message for full bodies. It stops short of enumerating item-level fields, but the schema's full/compact view explanation partially covers that.

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

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

Schema descriptions already cover view and limit in detail; the description reinforces that limit applies only to prism notifications and calls it the high-volume source. However, the required district parameter has no description in either schema or description, leaving a meaningful gap at 67% schema coverage.

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

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

The description opens with 'List all parent-visible messages' and enumerates exactly three sources: prism notifications, Messenger 2.0 inbox, and portal userNotice announcements. This precise scope clearly distinguishes the tool from siblings like ic_list_assignments or ic_list_grades, and it even names ic_get_message as the sibling for full HTML bodies.

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

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

It explicitly directs callers to ic_get_message when the full HTML body is needed, and warns that read-tracking may vary by district, which is a meaningful usage caveat. It does not exhaustively enumerate all alternatives, but the message domain is clearly separated from the other list tools.

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

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

With readOnlyHint=true, the safety profile is already clear. The description adds useful behavior—server-side filtering by scoreModifiedDate and a 14-day default cutoff—without contradicting the annotation. It does not cover response shape or pagination, but the annotation lowers the burden.

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

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

Two tightly packed sentences that deliver purpose, filtering behavior, parameter format, and default value with zero waste. Every sentence contributes essential information.

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

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

No output schema exists, so the description carries more responsibility for return-value expectations. It states the result is a list of recently-graded assignments, and the view parameter in the schema describes response shapes. Missing explicit pagination or alternative-tool guidance makes it adequate but not complete.

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

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

Schema description coverage is 50%; view and since have rich schema descriptions, and the description further clarifies since's format and default. district and studentId have no schema descriptions but their names make them self-evident. The description partially compensates for the coverage gap.

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

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

The description clearly states the verb 'List' and the resource 'recently-graded assignments for a student', which is specific enough to distinguish it from generic grade/assignment lists. The term 'recently-graded' and the scoreModifiedDate filter signal the tool's niche, though it does not explicitly name sibling tools.

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

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

The description explains how to set the since cutoff and its default, which is useful operational guidance. However, it does not explicitly state when to use this tool over ic_list_grades or ic_list_assignments, leaving the agent to infer the recency-based usage from the name and filter.

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

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

The description discloses behavioral traits beyond the readOnlyHint annotation: it states the output is grouped by term, returns one entry per enrollment, and includes comments like 'Teacher Workday' or 'Spring Break'. This provides useful context about the shape and content of the response without relying solely on the annotation.

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

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

The description is concise and front-loaded. The first sentence states the primary purpose and output structure; the second sentence offers a practical parameter hint. No filler or redundant content.

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

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

Despite no output schema, the description adequately explains the response shape (one entry per enrollment, term boundaries, school days, comments). It also mentions the since/until filter. It does not cover edge cases like empty results or pagination, but for a list tool with clear output description, it is fairly complete.

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

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

Schema description coverage is 80% (4/5 parameters have descriptions). The description adds minimal new meaning for parameters, only reinforcing the since/until usage. It does not compensate for the missing district description, and it adds no details about the view or studentId parameters beyond what the schema already provides. Baseline 3 is appropriate.

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

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

The description clearly states the action ('List') and the resource ('a student's school days'), and adds specifics about grouping by term and content (term boundaries, school days, comments). This distinguishes it from all sibling ic_list_* tools, which cover different domains like assessments, fees, or attendance.

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

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

The description provides usage context ('List a student's school days') and a parameter tip ('Use since/until to narrow the range'), but it does not explicitly address when to prefer this tool over alternatives or when not to use it. Since no sibling covers the same domain, the usage is implied, but explicit exclusionary guidance is missing.

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

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

The description is consistent with the readOnlyHint annotation and adds useful scoping context: the students are tied to the parent account and a specific district. It does not disclose pagination, ordering, error behavior, or authentication requirements, but the read-only annotation lowers the burden.

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

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

One sentence, front-loaded with the action and resource, with no filler or repetition. It earns every word and leaves the detailed parameter explanations to the schema.

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

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

For a simple list tool with readOnlyHint, one required parameter, and no output schema, the description plus schema provides enough to call it correctly. It could mention pagination or response shape, but the absence is a minor gap, not a blocking one.

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

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

The schema has 100% parameter description coverage, including a detailed explanation of the view enum. The description itself adds no parameter-level meaning beyond restating that a district is needed, so the baseline of 3 is appropriate.

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

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

The description uses a specific verb ('List') and a clear resource ('students'), and scopes it to the parent account and a given district. This distinguishes it from sibling tools like ic_list_assessments and ic_list_teachers even without naming them.

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

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

The description implies when to use the tool: when you need students under the parent account for a district. It does not explicitly state when not to use it or name alternatives, so the usage guidance is present but mostly inferred from context.

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

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

Annotations provide readOnlyHint, so the safety profile is already known. The description adds valuable behavioral context: it combines two endpoints, notes that response field shapes vary by district, and states which core fields are consistent (firstName, lastName, email). This goes beyond the annotation and helps the agent set expectations for the response.

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

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

The description is exactly two sentences with no filler. The main purpose is front-loaded in the first sentence, and the second provides essential context about endpoints and response variance. Every sentence earns its place, making it concise and well-structured.

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

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

For a read-only listing tool with no output schema, the description gives sufficient context: it states the purpose, notes the combined endpoints, and warns about district variance with a consistent core. It does not describe pagination or sorting, but these are likely irrelevant for this simple list. Given the low schema coverage, it could do more, but it provides enough to use the tool correctly for the common case.

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

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

Schema description coverage is low at 33% (only 'view' has a description), and the tool description does not compensate for the undocumented 'district' and 'studentId' parameters. It merely implies studentId identifies the student but gives no format or guidance for district. The 'view' parameter is well-covered in the schema, but the other two are left unexplained, so the description fails to add meaningful parameter semantics.

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

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

The description clearly states the verb (List), resource (a student's teachers and counselors), and specifies it is per enrolled section. It also mentions the two endpoints combined, distinguishing it from sibling list tools that target different domains (assessments, fees, etc.). No ambiguity remains about the tool's core function.

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

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

The purpose is specific enough to imply when to use it: whenever a student's teachers or counselors are needed. However, the description does not explicitly state when not to use it or name alternative tools, though the sibling tools cover distinct domains, making confusion unlikely. It provides clear context without explicit exclusions, so a 4 is appropriate.

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