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

With no annotations provided, the description carries the full burden and does well: it discloses the default save location, automatic directory creation, non-overwrite behavior with counter suffixes, and the return dictionary fields. It omits error handling and permission requirements, but the key side-effecting behaviors are clearly exposed.

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 well-structured with a concise opening, a behavior paragraph, parameter list, return type, and two examples. Every section earns its place and the most important behavioral caveat (no overwriting) 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?

For a file-writing operation with no annotations, the description covers the default path, concurrency-safe file naming, return values, and example invocations. The reference to get_attachments supplies the necessary precondition, and the output schema exists to document return structure further.

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%, so the description fully compensates. It explains message_id as the containing message, file_id as the attachment ID from get_attachments, and save_path as an optional target directory—adding meaningful semantics beyond the 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?

The description opens with a specific verb and resource: "Download a specific attachment from a message." It clearly distinguishes this from sibling tools like download_homepage_image and get_attachments by scoping to message attachments and naming get_attachments as the source for file IDs.

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 for when to use the tool: downloading an attachment from a message. It also implicitly provides the workflow by stating file_id comes from get_attachments. However, it does not explicitly state when not to use this tool or name alternatives such as download_homepage_image, so it lacks formal 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?

With no annotations, the description carries the behavioral burden and does well: it documents the default save directory, the host restriction, and the return shape. It does not cover edge behaviors like overwriting or directory creation, but for a simple download tool the key behavioral facts are present.

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 compact and front-loaded with the core action, immediately followed by the crucial usage pointer and constraint. The Args/Returns formatting is economical and 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 tool is simple with only two parameters, and the description supplies the source of the URL, the required host condition, the default save location, and the return value. The only minor gaps are filename derivation and overwrite behavior, which are not essential for basic invocation.

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%, so the description must compensate. It does: image_url is tied directly to get_homepage_blocks output, and save_path gets its optionality, default value, and meaning ('directory to save into'). This fully covers both parameters.

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 ('Download') and resource ('image embedded in a homepage block'), and differentiates from siblings like download_attachment by scoping to homepage block images with a specific source API. The reference to get_homepage_blocks makes what it operates on 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?

Explicitly tells the agent where to obtain the URL (get_homepage_blocks()['blocks'][*]['images']) and imposes the allowed-host constraint. It provides clear context for when to use it, though it does not explicitly state when not to use it or mention alternatives such as download_attachment.

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 provided, the description carries the behavioral burden and does disclose the return shape: a dictionary with file names, sizes, and IDs for downloading. It also implies a read-only listing operation. It stops short of covering edge cases or authentication, but it is still reasonably transparent for a simple list 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?

The description is front-loaded with a clear one-sentence purpose, followed by compact Args, Returns, and Examples sections. Every part adds value, and the example makes the usage immediately concrete without any 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 single-parameter tool with an output schema, the description covers the input source, returned data, and the downstream use of the IDs for downloading. Minor omissions like empty-result behavior or auth requirements are not critical here, but the description also does not explicitly route the agent to download_attachment.

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 the description compensates well by explaining message_id as 'The ID of the message to get attachments for' and specifying it comes from get_messages results. The example reinforces the expected integer format, adding meaning beyond the bare schema type.

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 all attachments for a specific message.' This clearly identifies the operation and scope, though it does not explicitly differentiate from the sibling tool download_attachment.

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 a useful context cue by saying message_id comes 'from get_messages results,' which implies when this tool is relevant. However, it does not explicitly explain when not to use it or when to prefer download_attachment instead, leaving the decision partly 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 of behavioral disclosure. It does state that the tool retrieves all available courses and returns a list with teacher information, implying a read-only operation. However, it does not mention authentication requirements, ordering, pagination, or what 'available' means in context.

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 short sentences with no wasted words. The main action is front-loaded, and the return shape is stated compactly. Every sentence contributes useful 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 tool with an output schema present, the description is mostly complete: it names the resource and the return content. The only notable gap is the absence of usage context regarding when to choose this tool over sibling get_* tools, but this is not critical for actual invocation.

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, so there is nothing for the description to explain about parameter usage. The baseline for zero-parameter tools is 4, and the description appropriately avoids inventing unnecessary parameter details.

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 ('Retrieve') and resource ('courses'), and specifies the result content ('with their teachers'). It is clear what the tool does and is distinguishable from siblings like get_schedule, get_results, or get_periods, which concern different resources.

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 use this tool versus alternatives such as get_results or get_planned_elements. No exclusions, prerequisites, or conditional selection criteria are provided, leaving the agent to infer usage entirely from the tool name and generic 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?

With no annotations provided, the description must carry the burden of behavioral disclosure. It states that it returns a dictionary organized by date and course, which is useful, but it does not disclose potential side effects, data freshness, or pagination behavior. This is a mild gap given that the tool appears to be a simple read 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 brief and front-loaded with the key purpose, followed by a concise return format note. The 'Returns' section adds value without wasted words. It could be slightly more detailed on edge cases, but it is appropriately sized.

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 tool's simplicity (zero parameters) and the explicit output schema, the description is mostly complete. However, it could clarify whether 'future tasks' includes assignments only or also other task types, and whether it respects date filters or course filters. These gaps could lead to incorrect invocation in ambiguous contexts.

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, so there is no need for parameter documentation. The description clearly states the return structure (dictionary by date and course), which is a high baseline for parameter semantics since there is nothing to clarify.

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 the verb and resource ('Retrieve upcoming assignments and tasks') and implies a focus on future items, which distinguishes it from generic task retrieval. However, it lacks specificity about which courses or date ranges are included, and does not explicitly differentiate it from siblings like get_courses or get_planned_elements.

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 tool is for fetching future tasks, but it does not provide explicit guidance on when to use it versus alternatives like get_planned_elements or get_schedule. The presence of a 'Returns' section hints at typical usage but omits any exclusions or alternative routing.

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 provided, the description carries the full burden of behavioral disclosure. It goes beyond a simple return statement by revealing that content is frequently an embedded image rather than text, that images is usually where the information lives, and that include_html returns raw inner HTML. It also clearly describes the return structure and provides an example.

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 well-structured with a front-loaded purpose, a brief context paragraph, and clearly labeled Args/Returns/Examples sections. Every sentence adds value – no filler or repetition of 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 tool with one optional parameter and no annotations, the description covers purpose, usage context, return format, parameter semantics, and an example. It is complete enough for an agent to select and invoke the tool correctly without additional information.

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 only describes include_html as a boolean with default false. The description adds substantial meaning: it states that the flag makes the tool 'also return each block's raw inner HTML' and shows usage in the example. With 0% schema description coverage, the description fully compensates.

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 ('Retrieve') and resource ('the 'in de kijker' blocks pinned to the Smartschool homepage'). It also distinguishes this tool from siblings by explaining the unique nature of these blocks: recurring content that is never sent as a message and never lands in a document module.

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 for when to use the tool (recurring homepage content like monthly menus, calendars, announcements) and explicitly states what these blocks are not (messages or document module content), effectively excluding get_messages and get_attachments. However, it does not name alternative sibling tools directly.

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. It discloses useful details such as include_body defaulting to False for performance, case-insensitive search and sender filter behavior, partial matching, and that the return is a dictionary with messages and pagination info. It does not cover auth or errors, but for a read-only listing tool this is solid.

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 well-organized with Args, Returns, and Examples sections. It is front-loaded with the core purpose and each sentence adds value, including compact examples that clarify common calls without 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?

For a six-parameter read-only tool with an output schema, the description covers essential semantics, defaults, and return shape. It could mention error conditions or authentication expectations, but nothing critical is missing for an agent to invoke the tool 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?

The input schema provides only types, titles, and defaults with 0% description coverage. The description compensates fully by explaining every parameter: limit, offset, box_type with the exact allowed values, search_query scope, sender_filter matching, and include_body's behavior and performance rationale.

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 a specific verb and resource: 'Retrieve messages from the specified mailbox with filtering options.' It clearly identifies the tool's function and distinguishes it from sibling tools like get_courses or get_schedule, which concern different resources.

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 through the action word 'retrieve' and the examples, but there is no explicit guidance on when to prefer this tool over alternative siblings such as get_attachments or download_attachment. 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 present, so the description carries the transparency burden. It clearly signals a read-only retrieval and discloses the return shape (list with name, dates, and active status). It does not mention sorting, filtering, or edge-case behavior, but for a zero-parameter getter this is minimally adequate.

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 short sentences with no filler. The action and scope are front-loaded, and the return summary is presented as a compact labeled block.

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 parameterless list-retrieval tool with an output schema, the description provides enough to invoke the tool correctly: what it returns and its scope. No additional context such as pagination or permissions is necessary at this complexity level.

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 already covers everything, so the baseline is 4. There is no parameter information the description needs to add.

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 a specific verb and resource: 'Retrieve academic periods/terms for the current school year.' This is clearly distinct from sibling tools like get_courses, get_results, and get_schedule, and it adds a scope qualifier (current school year).

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 intended use is implied by the purpose: call when academic period/term definitions are needed. However, the description does not state when to prefer this over get_schedule or other siblings, nor does it provide explicit exclusions or alternatives.

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 are absent, so the description must carry the full burden of behavioral disclosure. While 'retrieve' implies a read-only operation, it does not explicitly state this, nor does it mention auth needs, rate limits, pagination, or any side effects. The return-type summary adds a little context but does not compensate for the missing safety profile.

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 well-structured: a one-sentence purpose statement followed by clear 'Args' and 'Returns' sections. Every sentence adds value and there is no redundant or filler 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?

For a simple tool with one parameter and an output schema, the description covers the basic invocation. However, it lacks comparative context with sibling tools and explicit behavioral notes, leaving an agent uncertain about when this tool is the preferred choice.

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 only 0% schema description coverage, the description effectively explains the sole parameter: 'days_ahead: Number of days ahead to fetch (default: 34).' This adds meaningful semantic information beyond the raw schema, though it could be slightly more detailed about range or behavior.

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 and resource: 'Retrieve planned assignments and to-dos from the Smartschool planner.' This distinguishes the core function, but it does not explicitly differentiate from similar siblings like get_future_tasks, so it falls 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?

No guidance is given on when to use this tool versus alternatives such as get_future_tasks or get_schedule. The description provides no contextual cues about selection criteria, exclusions, or prerequisites.

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 transparency burden. It does convey that this is a read-only retrieval action and specifies the returned fields, but it does not address authentication, data availability, ordering, or possible absence of results. Behavioral disclosure is partial, not thorough.

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 short sentences with the action front-loaded and the return summary separated for readability. 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 no-parameter list tool with an output schema, the description is minimally viable, but it lacks any guidance relative to sibling tools and does not mention important retrieval context such as authentication or available data scope. It is complete enough to call but not fully contextual.

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 schema is already complete and the description has nothing to add. Baseline 4 applies because there are no parameter semantics to document.

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 clear verb ('Retrieve') and a specific resource ('academic report cards'), and lists the returned fields so an agent knows what the tool provides. The resource is distinct from sibling tools like get_results and get_courses, so the core purpose 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?

The description gives no guidance about when to use this tool versus siblings, no prerequisites, and no exclusions. 'Retrieve available academic report cards' implies a use case but does not help an agent choose between this and alternatives such as get_results or get_attachments.

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. It discloses pagination behavior via limit/offset, notes that include_details saves API calls, and states that the return value includes a results list and pagination info, adding meaningful context beyond the schema.

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 well-structured and front-loaded with the core purpose, followed by args, returns, and examples. A few examples are somewhat redundant with the parameter list, but they add practical clarity without excessive bloat.

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 simple 4-parameter tool with an output schema present, the description covers all necessary invocation details: parameters, defaults, behavior, return shape, and performance considerations. Nothing critical is missing for an agent to call this tool 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 0%, and the description fully compensates by explaining every parameter: limit, offset, course_filter's partial match/case-insensitive behavior, and include_details' trade-off of API calls for detailed fields like teacher, average, and median. It also provides concrete examples that illustrate parameter usage.

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 purpose: retrieving student results/grades with detailed information. It distinguishes itself from siblings like get_courses and get_reports by naming the specific resource type, though it does not explicitly contrast itself with get_reports.

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 examples and argument descriptions imply when to use the tool, such as filtering by course or suppressing details for faster responses. However, it does not explicitly state when to prefer this over sibling tools like get_reports or get_periods, nor does it mention any exclusions or prerequisites.

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 provided, the description carries the burden of disclosing behavior. It states 'Retrieve' and 'Returns: Dictionary', which implies a read-only operation and describes the output type. However, it does not disclose whether there are side effects, permission requirements, or behavior for dates with no lessons. The description is sufficient for a simple read but omits potential edge-case behaviors.

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, with a clear one-sentence purpose followed by an Args/Returns breakdown. It is front-loaded and each sentence adds value. The docstring style is slightly verbose but acceptable for clarity.

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 tool with one optional parameter and no annotations, the description covers the essential behavior: retrieving a schedule and returning a dictionary. It does not detail error handling or define the structure of the returned dictionary, but given the tool's simplicity and the presence of an output schema (indicated by context), this is adequate. The description could mention behavior for invalid offsets, but that 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?

The schema only provides a title and default for date_offset, with no description. The description fully explains the parameter: 'Days from today (0=today, 1=tomorrow, -1=yesterday, default: 0)'. This adds meaningful context beyond the schema, compensating for the 0% 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 states a specific verb ('Retrieve'), a resource ('lesson schedule'), and a scope ('for a given day'). It clearly distinguishes this from siblings like get_courses and get_periods, which likely handle different data. An agent can understand its purpose without ambiguity.

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 retrieving a day's schedule and specifies date_offset semantics, but it does not explicitly mention when to use this tool versus alternatives like get_periods or get_future_tasks. There is no statement of exclusions or conditions that would route the agent appropriately.

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. It does communicate that the action is a read-only retrieval and that only 'visible' links are returned, listing the response fields. However, it does not mention auth requirements, empty-list behavior, or failure handling, which leaves a moderate transparency 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?

The description is two short sentences with no filler. It front-loads the action and resource, then lists the exact return fields, making it efficient for an agent to parse.

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 getter with an output schema, the description is essentially complete: it names the resource and the returned fields. It could add a note about empty or hidden results, but the simplicity of the tool makes that a minor omission.

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 no parameters, so there is no schema or description detail needed about argument semantics. The zero-parameter baseline of 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 states a specific verb ('Retrieve') and resource ('student support links'), and explicitly names the return fields (name, description, URL). The tool is also clearly distinct from all sibling tools, so an agent can identify it as the support-links getter without ambiguity.

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 explicit when-to-use guidance or mention of alternatives is provided. The intended use case is implied by the clear resource name and zero-parameter design, but the description never directly states when to choose this tool over siblings; still, misuse is unlikely because no sibling covers support links.

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