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

With no annotations, the description carries the full burden and does well: it discloses the hard precondition, the refusal-without-network behavior, and the preview-first workflow. It stops short of stating auth requirements, whether repeat calls create duplicate passes, or rate limiting, so it is strong but not complete for a mutation tool.

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?

Front-loaded with purpose, then the gate and the corrective workflow, in three tight sentences with no filler. Minor deduction for the 'HARDC GATE' typo and slightly shouty phrasing that costs polish rather than length.

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?

An output schema exists, so return values need no explanation, and the critical precondition is thoroughly covered. The one gap is that required parameters are reported as zero while the form genuinely needs date/time and a description, which the description only hints at for the reason field.

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%, so all seven parameters are already documented, and the description adds meaning only for 'confirmed' (strict literal true), which the schema also states. Baseline 3 is appropriate since the schema does the heavy lifting.

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 (file) and resource (outpass request) and even names the endpoint, POST /api/chc/request/v2. It clearly distinguishes itself from preview_outpass, the read-only sibling, so an agent can route between them without opening either schema.

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 prescribes the workflow: run preview_outpass with the SAME params first, review the payload, then call this with confirmed=true. It also states the exclusion condition (if confirmed is not literally true, the tool refuses), leaving nothing to inference.

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?

No annotations are provided, so the description carries the full burden. It discloses the returned content in detail (dates, submission state, grades, files), which implies a read-only fetch, but says nothing about permissions, error behavior, or missing-assignment handling. Some value added, key behavioral traits absent.

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?

A single front-loaded sentence with no filler; the field enumeration is dense but informative. Slightly list-like, and partly overlaps what the existing output schema already conveys, but it 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?

An output schema exists, so return values need not be spelled out, and the safety profile is trivial for a read. The remaining gap is parameter semantics at 0% schema coverage with no description-side compensation, leaving the definition just short of complete for a two-required-param tool.

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 0% and both class_id and assignment_id are undocumented in the schema. The description never references either identifier, so it fails to compensate for the coverage gap even though 'one assignment' hints at needing an assignment key.

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 and resource ('Full detail for one assignment') and its singular scope implicitly separates it from the sibling get_assignments. The enumerated fields (dates, submission state, grade fields, submissions) make the retrieval target concrete, so an agent can pick it without opening either schema.

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?

Usage is only implied: 'one assignment' signals a single-record lookup versus the list-oriented get_assignments, but the description never says when to prefer it, what prerequisites exist, or names the alternative. Adequate but leaves routing to inference.

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 no annotations at all, the description must carry the behavioral load. It does disclose the return structure (three buckets, due dates, submission state), which helps, but says nothing about read-only nature, permissions, pagination limits, or whether omitted classes cause extra calls. Partial coverage only.

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?

A single compact sentence with the resource front-loaded and the scoping detail trailing. No filler, though the phrasing is dense enough that the scope clause reads as an afterthought.

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?

An output schema exists so return values need not be explained, and the parameters are fully documented, but with zero annotations the description should have covered at least the read-only/safety profile and pagination-across-classes behavior to be self-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 100%, so the schema already documents page, class_id and per_page fully. The description's 'or one class' aligns with class_id but adds no format or default detail beyond the schema; baseline 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?

States a specific resource (assignments) plus scope (across enrolled classes or a single class) and even the return shape (draft/upcoming/previous buckets with due dates and submission state). It does not explicitly differentiate itself from the singular sibling get_assignment, so it stops short of a 5.

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 when-to-use or when-not-to-use guidance, and no named alternative (e.g. get_assignment for a single assignment, get_calendar_events for due-date views). The parenthetical about one class is scope information tied to the class_id parameter, not usage 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?

No annotations are provided, so the description carries the full burden. 'get' plus the summary framing implies a safe read-only operation, and the description discloses the shape of the aggregate output. However, it says nothing about whether term filtering is required to get meaningful data, whether missing attendance records affect the percentage, or any auth/permission considerations.

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?

A single compact sentence that front-loads the primary output (overall percentage) before the secondary breakdown. Nothing is wasted, though the extreme terseness means it also carries no extra guidance.

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 an output schema present and 100% schema parameter coverage, the description does not need to explain return fields or parameter syntax, which keeps it close to adequate. But for a no-annotation tool with zero usage guidance and no mention of the term-scoping behavior, it is only minimally 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 100%, with both 'term' (including the default-32 meaning) and 'detail' fully documented in the schema, so the baseline is 3. The description adds no parameter-level detail — notably it never explains that 'detail' expands the output into per-session records — so it does not exceed the baseline.

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 the resource (attendance) and specifies exactly what is returned: an overall percentage plus a per-course breakdown with counts and percentages. It is clearly distinguishable from data-oriented siblings like get_results or get_assignments. It stops short of explicitly contrasting itself with a sibling tool, so it lands at 4 rather than 5.

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 statement of when to use this tool versus alternatives (e.g., get_timetable or get_courses), no prerequisites, and no exclusions. The agent must infer usage entirely from the name and return description.

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?

No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing beyond the data domain. It says nothing about scope (which academic term/year), whether results are cached or live, or that this is a read-only operation — though read-only is inferable from the name.

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?

A single front-loaded sentence with the resource first and concrete examples in parentheses; there is no filler, hedging, 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 zero parameters and an output schema that already defines the return shape, the description needs little more, and it covers the data domain adequately. However, with no annotations at all, it leaves the read-only/safety profile and the temporal scope of the events unstated.

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 takes zero parameters, so there is no parameter semantics to document and the baseline of 4 applies. The description correctly implies a global, unfiltered listing with no inputs required.

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?

Names a specific resource (institutional calendar events) and enumerates concrete content types — holidays, fests, exams — plus the institution, so an agent knows exactly what it retrieves. It stops short of differentiating itself from adjacent siblings like get_timetable or get_feed, which also return date-oriented institutional data.

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?

Usage is only implied: a zero-parameter institutional info tool is obviously called when global calendar data is needed, and the examples (holidays, fests, exams) hint at the domain. There is no explicit guidance on when this is preferable to get_timetable (personal class schedule) or when not to call 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?

With annotations absent the description carries the burden, and it does disclose one meaningful behavioral trait: published-state filtering and an empty payload when nothing is declared yet. It says nothing about permissions, whose student data is returned, or freshness of the snapshot.

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 resource and scope, with the empty-result caveat tucked in a parenthetical. No filler.

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?

Output schema exists, so return-value detail is out of scope, and the tool is otherwise simple (one required integer). The remaining gap is minor: how to obtain a class_id and whether the "student" is always the caller.

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 0% and the single parameter (class_id) is bare, so the description must compensate. It adds that the id scopes the result to one class's gradebook, but it never says where a valid class_id comes from (e.g., get_courses) or whether a student argument is implied.

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?

Names a specific resource and shape — a gradebook snapshot for one class containing assessment component results and published grades. It is distinguishable from get_assignments/get_results only by inference ("assessment component results", "as published"); no sibling is named 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?

There is no statement of when to use this versus get_results or get_assignments, both of which plausibly return overlapping grade data. Usage is only implied by the word "snapshot"; no prerequisites or exclusions are given.

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?

No annotations exist, so the description carries the burden, but the 'get' prefix implies a read-only operation and 'compact fields' usefully signals a lightweight response rather than a full course record. It still says nothing about permissions, scope of enrollment (current term only?), or pagination, leaving notable gaps for a zero-annotation tool.

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?

A single sentence with zero filler, front-loading the resource scope and then the field list. Nothing could be removed without losing 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?

For a zero-parameter read tool with an output schema, the description covers the essentials, and the field list is a helpful preview even though the output schema already documents the return shape. Only the absence of any usage/routing context keeps it from a 5.

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 takes no parameters, so there is nothing for the description to disambiguate beyond what the empty schema already shows. Baseline 4 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 names a specific resource and scope ('enrolled courses') and enumerates the returned fields, so an agent can tell it apart from get_timetable or get_assignments. It is a noun phrase rather than a verb+resource statement, and it never explicitly says it is a retrieval operation, which keeps it short of a 5.

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 when-to-use guidance, no prerequisites, and no mention of alternative tools such as get_timetable, which overlaps on 'next class times'. The agent must infer the selection criteria entirely from the tool name.

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?

No annotations are supplied, so the description carries the behavioral burden, and it does imply a read-only informational query with no side effects. It says nothing about authentication requirements, quota scoping, or freshness of the figures, but for a trivial no-arg read the remaining risk is low.

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?

A single short sentence, front-loaded with the resource and the comparison it reports. No filler; only the slightly redundant 'Human-readable' qualifier keeps it short of ideal.

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?

An output schema exists, so the description does not need to explain return values, and with no parameters and no annotations there is little else to document. It is adequate for this simple read tool, though it could note whether usage is per-user or per-tenant.

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 takes zero parameters, so there is nothing for the description to clarify beyond the schema. The baseline for a parameterless tool 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 names a specific resource (drive storage usage) and the exact quantities returned (used vs allocated vs free), so an agent can distinguish it from siblings like get_profile or get_hostel_summary. The verb is only implied by the name rather than stated in the description, which keeps it from a 5.

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 on when to call this versus other read tools, nor any stated preconditions. For a zero-parameter read tool the intended use is fairly obvious, but the description provides no explicit context or exclusions.

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?

No annotations are provided, so the description carries the full behavioral burden. It implies recency ordering with 'Latest' and lists returned fields, but omits read-only safety, authentication, pagination, and how n affects results. Since an output schema exists, the field list adds limited behavioral value.

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?

Single front-loaded sentence with no filler. The parenthetical field list is slightly awkward but otherwise efficient 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 simple read tool with an output schema, the description still leaves the sole parameter unexplained and provides no usage context. An agent cannot tell how to control result count or when this tool is preferred over sibling feed-like tools.

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 sole parameter n has 0% schema description coverage and is never mentioned in the description. The description does not explain that n likely controls the number of posts returned, so it fails to compensate for the undocumented schema.

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 the resource clearly: latest posts from the campus feed, and previews returned fields. It does not explicitly differentiate from sibling get_* tools or name a retrieval verb beyond the tool name.

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?

Provides no when-to-use guidance, no alternatives, and no conditions for choosing this tool over siblings like get_notifications or get_assignments. It merely describes the content returned.

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?

No annotations are provided, so the description carries the full behavioral burden. It does disclose useful traits: results are paged, the list can include the service catalogue, and detail mode returns form values and comments. It says nothing about read-only safety, permissions, or result ordering, leaving a gap for a no-annotation tool.

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?

A single semicolon-joined sentence, front-loaded with the resource name and immediately followed by the two-mode distinction. Dense and efficient, though the compressed phrasing borders on telegraphic.

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 an output schema present, return values need not be explained, and the description covers both modes (list with optional catalogue, detail with form values/comments) for a 4-param, 0-required tool. Only the absence of any safety/permission context keeps it from being fully 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 100% (page, per_page, request_id, include_services are all documented in the schema), so the baseline is 3. The description restates the request_id override behavior and the paged nature but adds no syntax or defaults beyond what the schema already provides.

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?

Names the resource concretely (Campus Help Centre requestable services + the user's help requests) and distinguishes two operating modes: list vs. single-request detail. The implied verb 'get' plus the named resource is unambiguous, though it does not explicitly contrast itself with siblings like get_passes or preview_outpass.

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 the mode switch — call without request_id for the paged list, with request_id for one request's detail — which is genuine usage guidance. It stops short of stating when this tool should be chosen over related tools or any preconditions, so guidance remains 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?

With no annotations, the description must carry the behavioral burden; the 'get_' name and 'snapshot' framing imply a read-only composite read, which is reasonable. It usefully discloses that attendance is returned as yes/no per date, but says nothing about permissions, rate limits, or paging, so it stops short of full disclosure.

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?

A single dense sentence that front-loads the 'Hostel snapshot' identity and then lists the three payload parts in order of importance. No filler, though the parenthetical detail makes it slightly heavy.

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?

An output schema exists, so return details need not be explained, and the description still usefully previews the three returned sections. For a single-optional-param read tool this is largely sufficient, with only usage routing left unaddressed.

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 0% for the single `days` parameter, so the description must compensate, and it does: 'the last `days` days (yes/no per date)' explains both the meaning and the return granularity. It does not restate the schema default of 14, but that is already in the schema.

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 concrete verb+resource ('Hostel snapshot') and enumerates the three payloads it returns: allotment with hostel/room/status/dates, a per-date attendance roll, and profile hostel data. This lets an agent distinguish it from get_attendance_summary and get_profile, though it never explicitly names those 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?

No guidance on when to choose this over get_attendance_summary (general attendance) or get_profile (general profile data), even though the description's scope overlaps both. No prerequisites, exclusions, or call conditions are stated.

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?

No annotations are provided, so the description carries the full disclosure burden, and it says nothing about permissions, whether the call is scoped to the authenticated student, or what happens when no mentor is assigned (a plausible empty case for a faculty-mentor relationship). It only restates the field list, which the output schema 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?

A single compact fragment with zero waste and the key qualifier ('Assigned') front-loaded. It is terse to the point of being clipped rather than a complete sentence, but nothing is padded.

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 tool is simple, parameterless, and has an output schema, so the description need not explain return values. However, for a relationship-derived lookup it omits the one thing an agent would want to know: behavior when no mentor exists and whether results are scoped to the current user.

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 takes zero parameters, so the baseline is 4. The word 'Assigned' usefully implies the mentor is derived from the caller's identity rather than a passed identifier, which is a small but real addition.

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 resource (the assigned faculty mentor) and enumerates the returned fields (name/salutation, contact, department), making it distinguishable from siblings like get_profile or get_courses. It is a noun phrase rather than an explicit verb+resource, but the tool name supplies the verb and there is no ambiguity about what this returns.

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 on when to call this versus get_profile (which likely also carries personal/contact data) or any other sibling. No preconditions, no mention of the zero-argument behavior, and no exclusions are stated.

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 no annotations, the description carries the full behavioral burden, and it delivers the single most consequential trait: reads never mark notifications as seen. That preempts a real agent mistake (calling it repeatedly expecting the unread count to clear). It omits auth requirements, rate limits, and pagination behavior, which keeps it short of a 5.

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 tight sentences with the scope stated first. The trailing pointer to 'the policy comment in server.py's implementation' is mild filler an agent cannot act on, but it does reinforce the non-mutation claim.

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 one-parameter read tool with an output schema covering return values, the description supplies scope and the key non-mutation guarantee. It is adequate, though an agent still has no guidance on volume, freshness, or when this overlaps with get_feed.

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 100% and the single `limit` parameter is fully documented in the schema, so the baseline of 3 applies. The description adds nothing about the limit, its default, or the max of 50.

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 concrete verb and resource ('list-only' notifications) plus the payload shape (unread count + latest rows), so an agent knows exactly what comes back. It does not differentiate itself from the closest-looking sibling, get_feed, but the resource is unambiguous.

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?

Usage is only implied: an agent infers it should call this to check the notification bell. There is no statement of when to prefer this over get_feed or other read siblings, and no prerequisites or exclusions are given.

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?

No annotations are provided, so the description carries the full behavioral burden. It does disclose the fallback merge and that results are paged and include hostel identity, but says nothing about read-only status, auth/permission requirements, or what happens when include_fallback is false while the console is empty.

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?

It is a single tightly packed sentence with no filler, and the primary resource ('My-passes console') is front-loaded. The trailing 'plus, when... fallback' clause is slightly tangled but every part carries 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?

With an output schema present, return values need not be explained, and all three parameters are covered. However, for a read tool with zero annotations, the description omits permission/auth context and the exact conditions under which the fallback is suppressed, leaving modest 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 100%, with page, per_page, and include_fallback each documented in the schema itself, so the baseline is 3. The description only restates pagination and the fallback flag, adding no syntax or interaction detail beyond what the schema already provides.

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 concrete resource and scope: the caller's own pass requests from the 'My-passes console', plus hostel identity, with a named fallback to help-centre outpass requests. An agent can distinguish it from create_outpass/preview_outpass, though it does not explicitly contrast with the sibling get_help_requests, which covers overlapping data.

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 fallback condition ('when the pass console has no rows') gives some contextual guidance, but that is the tool's internal behavior rather than a when-to-use rule for the agent. It never states when to pick this tool over get_help_requests or preview_outpass, leaving the choice 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?

No annotations are provided, so the description carries the full behavioral burden. It does disclose an important scope constraint (the profile is always the authenticated student, not an arbitrary user) and that the payload is a compact summary, but it says nothing about authentication failure behavior, caching/staleness of 'pending stats', or whether the data is read-only in practice.

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 with the resource front-loaded and the field breakdown in a tight parenthetical. Nothing is wasted, and an agent can read the whole contract at a glance.

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?

An output schema exists, so return values need not be explained, yet the description still summarizes the payload and its self-scoped nature. For a zero-parameter read tool this is nearly complete; only edge behavior (unauthenticated calls, refresh semantics for 'pending stats') is unaddressed.

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 zero parameters, so parameter semantics baseline is 4. The description reinforces this by anchoring the tool to 'the authenticated student', clarifying that no user identifier is accepted or 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?

States a specific verb+resource: it returns an identity card for the authenticated student, and enumerates what that contains (ukid, user type, tenant/college, pending stats). It is clearly distinguishable from the subject-matter siblings (get_calendar_events, get_drive_usage, etc.), though it never explicitly contrasts itself with 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?

Usage is implied rather than stated: 'the authenticated student' signals this is a self-scoped call needing no arguments and no target identifier. There is no explicit when-to-use guidance, no mention of when another tool would be preferable, and no prerequisites or exclusions.

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?

No annotations are supplied, so the description carries the full burden, and it is a clearly read-only get operation with modest risk. It discloses the declaration-state dimension of the data, but says nothing about permissions, pagination, or freshness of results. With an output schema present, return shape need not be covered, so this is adequate but thin.

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?

A single dense sentence with the primary payload first and the two modes parenthetically flagged; nothing is wasted. The parenthetical compression makes it slightly harder to scan than a clean two-sentence split would be.

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 one-optional-parameter read tool with an output schema, the description covers both invocation modes and the meaning of the only branching decision. Nothing an agent needs to call it correctly is missing.

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 100% and the schema already defines term_id in detail, including the examId cross-reference and null-grade behavior for undeclared terms. The description goes beyond that by explaining the mode switch the parameter triggers (rollup vs per-course), which is genuine added meaning, though the schema still does the heavy lifting.

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 the resource (semester results) and spells out the two distinct payloads it can return: an overall CGPA/percentage rollup plus per-term declaration state, or per-term course grades. That is far more specific than a tautology and lets an agent distinguish it from get_courses or get_class_assessments, though it never names those siblings 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?

It gives an explicit mode-selection rule tied to a parameter: omit term_id for the rollup view, supply term_id for per-course grades. That is actionable conditional guidance, but no alternative tool is named for cases where this one is the wrong choice.

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?

No annotations are provided, so the description carries the full burden. It notes the time horizon and lists some returned fields, but says nothing about required permissions, data freshness, pagination, or potential side effects. For a read-only list tool this is a significant gap.

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?

It is a single, front-loaded sentence that states the core purpose and lists return fields efficiently. It is appropriately sized for a simple list tool.

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?

An output schema exists, so return values need not be fully explained. However, for a tool with no annotations and an undocumented parameter, the description leaves key behavioral questions unanswered, making it only minimally adequate.

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?

There is one parameter 'days_ahead' with 0% schema coverage and a default of 7. The description merely places it in backticks without explaining units, allowed range, or behavior for zero/negative values. The schema itself provides no description, so compensation 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 begins with a specific verb and resource: 'Upcoming scheduled lessons across all enrolled courses.' This distinguishes it from generic calendar tools like get_calendar_events, although it does not explicitly name a sibling tool.

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 (fetch upcoming lessons within a time horizon) but does not state when to choose this over get_calendar_events or other tools, and no exclusions or alternatives are mentioned.

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?

No annotations are provided, so the description carries the full behavioral burden. It does add one non-obvious trait beyond the schema: the response mixes two data sets (self bookings plus bookable infrastructure types), which an agent might not expect. However, it says nothing about read-only safety, authorization scope, or that results are paginated, and an output schema exists to document the return shape.

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 with two clauses; nothing is padded and the core resource is front-loaded. The parenthetical brand name and the trailing 'plus' clause make it slightly denser than necessary, but there is no filler.

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 low-complexity, zero-required-parameter read tool with an output schema, the description supplies the essential scope (self, selected period) plus the secondary payload. Only the pagination/response-size caveat and the absence of annotations leave 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?

Schema description coverage is 100%, so the schema already documents page, size, and the period enum values. The description only echoes the period-window concept without adding syntax, defaults, or constraints beyond what the schema states. Baseline 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 names a specific verb+resource combination ('My venue bookings (Book-a-Venue)') and clearly scopes it to 'self bookings in the selected period window,' which no sibling covers. It also discloses a second payload element ('infrastructure types a student may book direct'), which makes the resource slightly broader than the name implies. It is unambiguous, though it never names a sibling for disambiguation because none competes.

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 when-to-use guidance, no prerequisite, and no alternative tool named or excluded. The phrase 'self bookings in the selected period window' implies scope, but an agent gets no signal about when this tool is the right call versus e.g. get_calendar_events or preview_outpass. Implied context only.

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 no annotations, the description carries the behavioral burden and does so for the critical trait: it is preview-only, mutates nothing, and performs no network call to the campus API. It omits other traits such as auth requirements or whether the preview validates inputs, which keeps it from a 5.

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, zero filler, and the most decision-relevant fact ('PREVIEW ONLY (no mutation)') is front-loaded in caps. The endpoint and output shape follow immediately.

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 no-side-effect preview tool with a full output schema, the description covers what an agent needs: what it builds, where it would go, and that nothing is transmitted. It could be marginally richer about prerequisites, but nothing essential is missing.

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%, so all six parameters (out_date, out_time, service_id, description, return_date, return_time) are already documented in the schema. The description adds no syntax, defaults, or format meaning beyond that, so the baseline 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?

States a specific verb (build/preview) plus the exact resource (the JSON payload create_outpass would POST to /api/chc/request/v2) and the expected output (JSON + human summary). It explicitly distinguishes itself from the sibling create_outpass.

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?

By naming create_outpass as the mutating counterpart and stating 'Nothing is sent to the campus API', it makes the dry-run-before-create use case clear. It stops short of an explicit 'use this when you want to verify before submitting' instruction, but the routing is unambiguous.

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