Server Quality Checklist

Tool Scores

• get_my_group_orderA
  3.6/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It does list return fields (order number, total students, full name, group name) but omits important information about authentication requirements, session dependence ('current student' implies a logged-in user), and potential errors if not authenticated.

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

  Conciseness5/5

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

  The description is a single sentence, front-loaded with the primary purpose and followed by additional return info. It is concise, with no unnecessary words or repetition.

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

  Completeness4/5

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

  For a zero-parameter read-only tool without an output schema, the description fully specifies the return payload and purpose. However, it misses explicit auth/session context, which is relevant given sibling tools include authenticate and check_auth_status, but this is a minor gap for such a simple tool.

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

  Parameters4/5

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

  The schema has 0 parameters, and the description appropriately implies the tool is self-contained. Since there are no params to document, the baseline is 4, and the description does not need to compensate.

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

  Purpose5/5

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

  The description uses a specific verb+resource: 'Get the current student's order number in the group list' – this clearly states what the tool does and distinguishes it from siblings like get_my_profile. The additional detail about return fields further clarifies its purpose.

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

  Usage Guidelines2/5

  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_my_profile, nor any mention of prerequisites (e.g., authentication). The description simply states what it returns without context for invocation.

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

• check_auth_statusA
  3.9/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the burden of behavior. It explicitly states the return value (validity and profile access), which is the primary behavioral outcome. However, it does not explicitly mention side-effect-free nature, network usage, or error conditions. For a simple status check, this is reasonably transparent but not exhaustive.

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

  Conciseness5/5

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

  The description is a single, well-structured sentence that front-loads the purpose and immediately states the output. It contains no fluff or repetition, earning a perfect score.

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

  Completeness5/5

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

  For a zero-parameter tool with no output schema and no annotations, the description completely covers the tool's behavior and return semantics. It is fully adequate for an agent to understand what the tool does and what it returns, given the tool's simplicity.

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

  Parameters4/5

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

  The tool has zero parameters, so the description has no parameter burden. Per the rubric, 0 params earns a baseline of 4. The description adds no parameter-specific detail, which is appropriate given the empty schema.

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

  Purpose5/5

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

  The description clearly states a specific action ('Check') on a specific resource ('current authentication cookies') and defines the output ('whether cookies are valid and can access the GUAP profile'). This distinguishes it from siblings like authenticate (which establishes auth) and get_my_profile (which retrieves profile data).

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It does not mention that it should be used as a precondition for other operations, nor does it explain how it differs from get_my_profile for verifying auth. Usage context is only implied.

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

• submit_reportA
  4.1/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the burden of disclosing behavior. It does disclose important constraints (file must exist, extensions depend on task, optional comment) but does not mention potential side effects (e.g., whether previous submissions are overwritten, whether submission is final, or what the server returns on success/failure). This is useful but incomplete transparency 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.

  Conciseness5/5

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

  The description is three sentences long, front-loaded with the primary action. Each sentence adds relevant context: the action, the file prerequisite and extension constraint, and the optional comment. No wasted words.

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

  Completeness3/5

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

  With no output schema or annotations, the description covers the core purpose and prerequisites, and correctly points to get_task for extension details. However, it omits information about the return value, error conditions, or whether resubmission is allowed. This leaves some gaps for a tool that performs a state-changing submission.

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

  Parameters4/5

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

  Schema description coverage is 0%, so the description must compensate. It implicitly explains each parameter: task_id identifies the task (whose rules determine allowed extensions), file_path refers to an existing local file, and comment is optional. This gives meaning beyond the raw schema property names, though examples or format details are absent.

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

  Purpose5/5

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

  The description starts with a clear, specific verb+resource: 'Submit a report file for a specific task.' It distinguishes itself from the read-only sibling tools (e.g., list_tasks, get_task, download_material) by being the only submission action. The added detail about file existence and task-dependent extensions further clarifies its scope.

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

  Usage Guidelines4/5

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

  The description gives explicit usage context: it tells the agent to 'check get_task first' to learn allowed extensions, which is a clear prerequisite. It also states that the file must already exist locally and that a comment is optional. It does not explicitly exclude other tools, but the context is sufficient for selecting this tool over siblings.

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

• authenticateA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden. It discloses that the tool opens a browser window, navigates to a login page, waits for user credentials, saves session cookies to a file, and has a default timeout. This is substantial behavioral 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.

  Conciseness5/5

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

  The description is three sentences: main action, process details, and cookie persistence/timeout. Every sentence adds value and is front-loaded with the primary purpose.

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

  Completeness4/5

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

  The description covers the workflow (browser, navigation, wait, cookie save) and the default timeout. It lacks details on return values, error handling, or how to verify success, but the cookie-saving outcome is clear and the complexity is manageable.

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

  Parameters4/5

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

  The schema only lists a timeout parameter with a default of 120, but no units. The description adds that the timeout is in seconds and explicitly states '120 seconds by default', providing meaning beyond the raw schema.

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

  Purpose5/5

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

  The description clearly states the verb 'Authenticate' and the target resource 'GUAP', and explains the browser automation process. It distinguishes itself from sibling data retrieval tools by being the authentication step.

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

  Usage Guidelines3/5

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

  The description implies that this tool should be run before subsequent requests, noting that cookies will be used automatically. However, it does not explicitly mention when to use vs alternatives like check_auth_status, nor does it state any exclusions.

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

• download_materialA
  4.2/5.0
  Behavior4/5

  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 automatic session-cookie auth for internal links, handling of Google Drive confirmation pages, the default save directory, and the return fields. It stops short of mentioning overwrite behavior or failure modes, but covers the core behavioral expectations for a download tool.

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

  Conciseness5/5

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

  The description is a single, front-loaded paragraph of three sentences. It immediately states the main action, then efficiently details URL types, save behavior, and return values—no filler words or redundant information.

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

  Completeness4/5

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

  Given the tool's moderate complexity (handles three URL types) and lack of output schema, the description is quite complete: it covers URL handling, authentication, save location, and return values. It omits potential error cases or size limits, but for a download tool, the provided context is sufficient for an agent to select and invoke it correctly.

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

  Parameters3/5

  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 thoroughly explains the 'url' parameter semantics by enumerating accepted URL categories, and the phrase 'by default' hints that save_dir can override the default path. However, it never explicitly names or explains the save_dir parameter, leaving some ambiguity about its expected format or behavior.

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

  Purpose5/5

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

  The description clearly states 'Download a material file by URL' and elaborates on three specific URL types, making the tool's purpose unambiguous. It distinguishes itself from sibling tools like list_materials (which lists) and authenticate (which handles auth) by focusing on the actual file download action.

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

  Usage Guidelines4/5

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

  The description provides clear context on when to use the tool: when you have a material URL (internal, Google Drive, or direct). It does not explicitly name alternatives or exclusions, but given the sibling set, download_material is the only tool for downloads, so the intended usage is well implied.

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

• get_my_profileA
  4.2/5.0
  Behavior3/5

  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 data fields but does not mention behavioral traits such as authentication requirements, potential errors, or data freshness. Since this is a read-only, parameterless getter, the lack of edge-case disclosure is a minor gap but not severe.

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

  Conciseness5/5

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

  The description is a single sentence that front-loads the main purpose and then lists fields in a clear, comma-separated format. Every element carries information, with no filler or redundancy.

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

  Completeness4/5

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

  Given the simple nature of the tool (no params, no output schema, no annotations), the description does well to enumerate the exact fields returned. It could moderately improve by explicitly stating that the data belongs to the authenticated user, but 'current student' already implies this. Overall, it is adequately complete for the tool's complexity.

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

  Parameters4/5

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

  The tool has zero parameters, and the schema is an empty object. The description does not need to explain parameters; instead, it lists the fields in the return value. Per guidelines, the baseline for 0 params is 4, and the description adds value by enumerating the profile contents.

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

  Purpose5/5

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

  The description uses the specific verb 'Get' and the resource 'current student's profile', followed by a comprehensive list of returned fields (ФИО, group, student book number, etc.). This clearly distinguishes it from sibling tools like get_teacher_info and get_subject_info, which target different entities.

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

  Usage Guidelines4/5

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

  The description establishes clear context: it is for retrieving the current student's profile. It does not explicitly name alternative tools or when-not-to-use, but the scope is self-evident and the sibling tools target different resources, so there is little ambiguity.

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

• get_subject_infoA
  4.2/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden of disclosure. It describes the returned fields but does not explicitly state that the operation is read-only, what happens if the ID is invalid, or whether authentication is required. The verb 'Get' implies a safe read, but the description could be more transparent about error responses and side-effect-free behavior.

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

  Conciseness5/5

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

  The description is concise and information-dense: the first sentence states the core purpose, and the second lists return fields and ID sources. Every sentence earns its place, with no redundant wording.

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

  Completeness4/5

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

  For a tool with a single parameter and no output schema, the description covers purpose, expected return content, and how to obtain the input ID. It lacks explicit error-handling or edge-case details, but those are not critical for this straightforward read operation.

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

  Parameters4/5

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

  The input schema provides no description for subject_id, and schema coverage is 0%. The description compensates by clarifying that the ID is numeric and points to which tool results contain such IDs, adding meaningful guidance beyond the schema.

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

  Purpose5/5

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

  The description explicitly states it retrieves detailed information about a subject/discipline by numeric ID, distinguishing it from sibling tools like get_teacher_info and list_tasks. It also lists the specific fields returned, making the purpose concrete and unambiguous.

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

  Usage Guidelines4/5

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

  The description provides clear context for when to use this tool by explaining that subject IDs are available from list_tasks, get_task, and list_materials. However, it does not explicitly mention when not to use it or name alternative tools for excluded cases, so it falls short of a 5.

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

• get_teacher_infoA
  4.3/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries full burden. It discloses the return content but does not explicitly state that it's a read-only operation, whether authentication is required, or how errors (e.g., invalid teacher_id) are handled. This is a moderate gap for a 'get' tool.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the purpose, and every sentence adds value: first states action and parameter, second details return structure and ID sourcing. No redundancy or fluff.

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

  Completeness4/5

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

  For a single-parameter get tool with no output schema, the description adequately covers input source and return shape. It omits error behavior and auth prerequisites, which would elevate it to fully complete.

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

  Parameters5/5

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

  With 0% schema description coverage, the description compensates fully by explaining that teacher_id must be a 'numeric profile ID' and that IDs come from specific endpoints. This adds actionable meaning beyond the bare schema.

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

  Purpose5/5

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

  The description explicitly states 'Get information about a teacher' and specifies the resource (by numeric profile ID) plus the exact return data (full name, degree/rank, positions). This clearly distinguishes it from sibling tools like get_my_profile and get_subject_info.

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

  Usage Guidelines4/5

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

  The description provides concrete guidance on when to use by explaining that teacher IDs are available from list_tasks, get_task, and list_materials results. It does not explicitly compare alternatives, but the tool's purpose is unique enough that this is sufficient context.

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

• list_tasksA
  4.3/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden. It discloses the default semester scope and explains filter behaviors, which adds value. However, it does not explicitly state that the operation is read-only, nor does it mention pagination, ordering, or authentication requirements. Some gaps exist, but the key behavioral aspects are covered.

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

  Conciseness5/5

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

  The description is dense but well-structured: first the core purpose and return fields, then parameter details. Every sentence adds information, and the parameter mappings are comprehensive without redundancy. No fluff.

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

  Completeness4/5

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

  The description covers all parameter semantics and defaults, making the tool usable without deeper investigation. The return field list is also mentioned, though the output schema exists. Minor gaps like pagination or empty-list behavior are not addressed, but overall completeness is high.

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

  Parameters5/5

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

  The schema has 0% description coverage, so the description must fully compensate. It does so excellently by explaining each parameter's meaning, providing an example for semester, and listing complete numeric code mappings for task_type and show_status. This is far beyond baseline.

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

  Purpose5/5

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

  The description begins with a specific verb and resource: 'List tasks assigned to the student.' This clearly distinguishes it from siblings like get_task (which likely retrieves a single task) and list_materials. The 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.

  Usage Guidelines4/5

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

  The description states that all filters are optional and default to showing everything for the current semester, giving clear context for typical usage. However, it does not explicitly mention alternatives or when not to use this tool, but the context is sufficient for basic tool selection.

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

• get_taskA
  4.4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the disclosure burden. It lists the exact fields returned (description, file extensions, extra materials, deadline, submitted reports), giving transparency into the tool's behavior. It does not mention read-only nature or auth, but for a simple get, this is adequate.

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

  Conciseness5/5

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

  The description is a single sentence that front-loads the purpose and immediately lists the included details. It is concise, with no filler or redundant information.

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

  Completeness4/5

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

  The description lists the key return fields, which is helpful given no output schema. It does not cover error scenarios or how to obtain the task_id, but for a simple get tool with one parameter, it is fairly complete. A slightly richer description of the report statuses or potential errors would earn a 5.

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

  Parameters4/5

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

  The schema only has 'task_id' as a string, but the description adds that it is a 'numeric ID', providing extra semantic detail. This is meaningful given the 0% schema coverage, though it could clarify the format (string of digits) to avoid confusion.

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

  Purpose5/5

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

  The description clearly states the action (get full details) and the specific resource (a task) with a scope limitation (by numeric ID). It distinguishes itself from list_tasks, which likely lists all tasks, making it clear this tool targets a single task.

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

  Usage Guidelines4/5

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

  The description implies usage when needing details for a specific task, contrasted with list_tasks for listing. However, it does not explicitly mention alternatives or when not to use the tool, so it lacks an explicit 'use this instead of...' guidance.

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

• list_materialsA
  4.6/5.0
  Behavior4/5

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

  With no annotations, the description carries the full behavioral disclosure burden. It reveals output structure (name, discipline, date added, teacher, URL types), default semester behavior, and parameter effects. Though it doesn't explicitly state the operation is read-only, the verb 'list' implies no side effects, and the added details provide good transparency.

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

  Conciseness5/5

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

  The description is three sentences without fluff, front-loaded with the core purpose, and each subsequent sentence adds specific value (output fields, defaults, parameter semantics). It is concise and well-structured.

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

  Completeness5/5

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

  For a simple list tool with two optional parameters and an output schema, the description covers the purpose, output fields, defaults, and parameter meanings. No critical information is missing, and the low complexity makes this description complete.

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

  Parameters5/5

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

  The schema parameters have only integer/null types with no descriptions, while the description fully explains both: semester with an example ID and subject_id as a discipline filter. It also clarifies that they are optional and default to current semester, adding meaning far beyond the schema.

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

  Purpose5/5

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

  The description uses a specific verb 'list' and clearly identifies the resource as 'learning materials available to the student'. It enumerates output fields and distinguishes itself from sibling tools like download_material by focusing on listing rather than fetching a specific file.

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

  Usage Guidelines4/5

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

  The description clarifies that all filters are optional and default to the current semester, giving context for typical usage. It explains each filter's purpose but does not explicitly mention when not to use the tool or name alternatives, though the context implies it is the first step before downloading.

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