Server Quality Checklist

Tool Scores

• list_assignmentsC
  2.6/5.0
  Behavior2/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 behavioral disclosure. It states what is returned (assignments with deadline and description) but does not mention read-only nature, pagination, sorting, or whether past assignments are excluded by default (even though the include_past parameter hints at this). No side effects or limitations are disclosed, leaving significant ambiguity for an agent.

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

  Conciseness3/5

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

  The description is concise at two sentences, but it is terse to the point of omitting necessary information. It front-loads the main purpose, which is good, but the second sentence could be integrated with more detail. It is appropriately sized for a simple tool but sacrifices completeness for brevity.

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

  Completeness2/5

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

  For a tool with 2 parameters, no output schema, and no annotations, the description should fully specify the operation. It covers the return fields and cv_cid, but omits include_past semantics, any mention of sorting or pagination, and does not clarify the default scope (all assignments vs. upcoming). This leaves an agent uncertain about the tool's full behavior, making it incomplete for reliable invocation.

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

  Parameters2/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 explain all parameters. It explains that cv_cid filters to one course, but it does not mention include_past at all. The parameter's meaning is not self-evident from the name alone, so the absence of explanation is a notable gap. The description partially compensates for one parameter but fails for the other.

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

  Purpose4/5

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

  The description clearly states the tool returns assignments with deadline and description, identifying the resource and verb. However, it does not distinguish itself from the sibling tool 'list_upcoming_deadlines', which could overlap in scope. The mention of cv_cid filtering adds specificity but the overall purpose is clear enough without explicit differentiation.

  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 like list_upcoming_deadlines or list_courses. It does not state whether this is the default assignment list or how it differs from upcoming deadlines. An agent would have to infer usage context from the tool name alone, which is insufficient.

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

• list_materialsC
  2.6/5.0
  Behavior2/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 of behavioral disclosure. It only describes the output format (folder, name, URL) and does not state whether this is a read-only operation, whether authentication is required, or any side effects. It also doesn't explain how the optional cv_cid parameter affects behavior. This is a significant transparency gap for a tool with no annotation support.

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

  Conciseness4/5

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

  The description is a single concise sentence with no filler. It front-loads the core action and result. However, it is under-specified, but that is a completeness issue rather than a conciseness issue. It is appropriately short for a simple tool, though it omits crucial parameter context.

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

  Completeness2/5

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

  The tool has one optional parameter, no output schema, and no annotations, so the description must provide enough to call it correctly. It fails to explain the meaning of cv_cid, which is essential for filtering. It also doesn't elaborate on the context of 'MCV' or clarify if materials are from a single course or multiple. Overall, the description is incomplete for an agent to use confidently.

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

  Parameters1/5

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

  The schema provides zero description for the cv_cid parameter (0% coverage), and the tool description does not mention it at all. An agent has no way to know that cv_cid likely stands for course ID and filters the materials list. The description adds no meaning beyond the schema, which itself is opaque.

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

  Purpose4/5

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

  The description states a clear verb ('list') and resource ('course materials') and specifies the return fields (folder, name, URL). It distinguishes from siblings like download_material (which implies downloading rather than listing) and list_assignments (which lists assignments). However, it doesn't explicitly name a sibling or state scope (e.g., per course), leaving some ambiguity about whether it lists materials for all courses or a specific one.

  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. It does not mention that this is for listing materials while download_material is for downloading, nor does it specify any conditions or prerequisites. The purpose implies usage, but no explicit when-to-use or when-not-to-use guidance is provided.

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

• list_coursesB
  3.2/5.0
  Behavior2/5

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

  Annotations are absent, so the description carries the full burden of disclosing behavior. It only states the basic purpose and the yearsem filter. It doesn't mention return format, pagination, ordering, default behavior when yearsem is omitted, or any side effects. For a read-only list tool this is minimal, but the lack of any behavioral detail beyond the core function leaves the agent guessing about output and edge cases.

  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, efficient sentence. It front-loads the core purpose ('Enrolled courses') and then explains the optional parameter with an example. There is zero waste and every word earns its place.

  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?

  For a simple tool with one optional parameter and no output schema, the description is adequate for a basic call: it names the resource and the filter. However, it omits default behavior (what happens if yearsem is not provided) and any indication of the response shape (likely a list of course objects). Given the absence of an output schema, a bit more detail about return structure or defaults would make it complete.

  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 provides no description coverage (0%), so the description must explain the parameter. It does: 'yearsem filters to one semester, e.g. \'2568/1\''. This adds meaning about the purpose and format of the parameter, which the schema alone lacks. It doesn't explain what happens if omitted, but for a single optional parameter this is a useful addition.

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

  Purpose4/5

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

  The description clearly indicates the resource (enrolled courses) and the purpose (listing them), even though it uses a noun phrase 'Enrolled courses' rather than an explicit 'List...'. It's distinguishable from siblings like list_assignments and list_grades which target different resources, so an agent can infer what it does from the name plus description.

  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?

  No guidance is given for when to use this tool versus alternatives. It doesn't mention that it should be used for viewing course enrollment, nor does it contrast with sibling tools. The agent must infer its role from the name and description alone, without any contextual cue about when to prefer it.

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

• list_upcoming_deadlinesB
  3.3/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full responsibility for behavioral disclosure. It does mention the sorting ('soonest first'), a useful detail, but it omits critical behavior such as how the include_undated parameter affects results (defaults to true) and does not explicitly state that this is a read-only operation. The description is too thin to fully inform an agent about what to expect when calling the 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 sentence that is tightly worded with no redundancy. It front-loads the primary action and the key detail (time window) and keeps the sorting information concise. Every word earns its place, making it highly efficient for an agent to parse.

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

  Completeness2/5

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

  Given the tool's simplicity (two parameters, no output schema, no annotations), the description should provide enough context for correct invocation. It explains the filtering window but completely ignores the include_undated parameter and any potential results format. An agent would not know how to interpret the boolean parameter or what the response looks like, leaving the definition incomplete.

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

  Parameters2/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 does loosely explain within_days via 'within the next N days' but fails to mention the default value of 7 or the semantics of include_undated. Since one parameter is entirely undefined in the description, the agent cannot understand the full behavior without external inference. This is insufficient for a tool with zero schema descriptions.

  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 'Assignments due within the next N days, soonest first.' uses a specific verb ('list' implied by the tool name) and resource (assignments with upcoming deadlines), and clearly distinguishes itself from the sibling list_assignments by focusing on a time window and sorting order. An agent can immediately understand what this tool does and how it differs from a general assignment list.

  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 usage context (when you need deadlines within a time range) but provides no explicit guidance on when to use this tool versus alternatives like list_assignments or get_assignment. It lacks any 'use X instead when...' or exclusions, leaving the decision to the agent's inference. As a simple filtered list, the purpose is fairly obvious, but the absence of alternative routing makes it a 3.

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

• whats_newB
  3.3/5.0
  Behavior2/5

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

  No annotations are provided, so the description must carry the full burden. It describes a read operation ('what appeared or changed') but does not explicitly state read-only behavior, auth requirements, rate limits, or what the response looks like. It only mentions parameters and defaults, lacking transparency about side effects or output format.

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

  Conciseness4/5

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

  The description is concise: a single purpose sentence followed by a clear argument list. It is front-loaded with the core purpose and efficiently explains each parameter without unnecessary detail. The structure is clean and easy to scan.

  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?

  The description covers purpose and parameters adequately but lacks details about the return format, pagination, or error behavior. Given no output schema and no annotations, an agent would benefit from knowing what the response contains (e.g., a list of events with fields). However, for a relatively simple feed tool, it is sufficient to call correctly, so this is a moderate gap rather than a critical one.

  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 description adds substantial meaning beyond the input schema. It explains 'since' accepts ISO dates, relative spans like '3d'/'12h', or 'yesterday', with a default of 7 days; 'kinds' is a comma-separated filter with an example; 'limit' is a max event count. With schema description coverage at 0%, this compensation is valuable, though a full list of allowed 'kinds' values would make it even stronger.

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

  Purpose4/5

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

  The description clearly states the tool's purpose: 'What appeared or changed on MyCourseVille recently.' This is a specific verb+resource that distinguishes it from listing tools like list_assignments or list_grades, though it doesn't explicitly name alternatives. The intent is immediately understandable.

  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 purpose implies usage: if an agent needs recent activity, this is the tool. However, there is no explicit guidance on when to use this versus siblings, no exclusions, and no mention of scenarios where other tools would be preferred. The usage is implied but not directly stated.

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

• auth_statusB
  3.4/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 of behavioral disclosure. It does disclose what the tool reports (credential presence, session state, sync result, row counts), which is substantive. However, it omits whether this is a read-only diagnostic (likely but unstated), whether it makes external calls, or what the output format looks like, leaving the agent to infer safety and interpretability.

  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?

  A single, front-loaded line that opens with the purpose category ('Diagnostics:') followed by a tight list of the four report items. Every word earns its place and there is zero redundancy or filler.

  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?

  For a zero-parameter status tool with no output schema, the description covers the report categories but not the return format or structure. An agent calling this for diagnostics will not know how to parse the response the tool returns. This is a moderate completeness gap for an otherwise 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 tool has zero parameters and the schema is empty, so the baseline of 4 applies. There is nothing for the description to add regarding parameter semantics, and no gap exists for it to compensate for.

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

  Purpose4/5

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

  The description clearly states a diagnostic purpose and enumerates the specific items reported (credentials present, session state, last sync result, row counts). It is readily distinguishable from all sibling tools, which are list/get/download/sync operations rather than diagnostics, so an agent can tell it apart without opening any schema.

  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 explicit guidance on when to use this tool versus alternatives. The purpose makes it self-evident for checking auth/session state, and sync_now is a related sibling (the 'last sync result' item ties to it), but no when-to-use or when-not-to-use routing is given. The 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.

• get_assignmentB
  3.4/5.0
  Behavior2/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 behavioral disclosure. It only states it returns 'full detail' but reveals nothing about side effects, permissions, error behavior, or whether it is a read-only operation. This is a significant gap for a tool with zero annotation coverage.

  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?

  Two concise sentences with no wasted words. The critical parameter format is front-loaded in the second sentence, and the entire description is efficiently structured.

  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?

  For a simple fetch-by-id tool with one parameter and no output schema, the description covers the essential detail (parameter format). However, it does not mention what 'full detail' includes, any prerequisites (e.g., auth), or error conditions. Given no annotations, this leaves gaps that could cause an agent to misuse it, but the tool's simplicity keeps it at an adequate level.

  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. The explanation of assignment_id format ('<cv_cid>:<item_id>') adds meaning beyond the bare 'string' type in the schema. Though it doesn't describe other potential aspects, it fully clarifies the single required parameter.

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

  Purpose4/5

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

  The description states a clear verb+resource: 'Full detail for one assignment.' It is unambiguous about the tool's purpose. However, it doesn't explicitly distinguish itself from the sibling list_assignments, though the singular 'one assignment' implies that distinction. Still, it is clear and specific.

  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 when to use it (when you need full detail for a single assignment), but it does not explicitly state when not to use it or mention alternatives like list_assignments for listing. It provides no exclusions, so it falls under 'implied usage' rather than explicit guidance.

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

• download_materialA
  3.5/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 disclosure burden. It reveals that the tool downloads a file to the local downloads folder, which implies a write operation. However, it omits details like file overwrite behavior, failure handling, permission requirements, or whether the download is synchronous. The extract_text note is useful but the description falls short of explaining side effects or the operational context beyond the basic action.

  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, with two sentences. The primary action is front-loaded, and the explanation of extract_text is placed after the main action, which is logical. Every sentence earns its place, and there is no redundancy or filler.

  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?

  Given the tool's simplicity (two parameters, no annotations, no output schema), the description covers the essential purpose and one parameter. However, it lacks details on return values, error behavior, or any operational side effects. For such a straightforward tool, this is adequate but leaves room for improvement, especially since behavioral transparency is low.

  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?

  The schema description coverage is 0%, so the description must compensate. It explains extract_text well, stating that it pulls readable text from PDFs for summarization. It does not explain material_id, but that parameter's name and context make its purpose self-evident. The description adds meaning for one parameter but leaves the other implicit, providing partial compensation for the coverage gap.

  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 (download), the resource (one material), and the destination (local downloads folder). This distinguishes it from sibling tools like list_materials and get_assignment, which respectively list and retrieve details rather than download. 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 Guidelines3/5

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

  The description does not explicitly state when to use this tool versus alternatives or provide exclusions. It implies usage by naming the action, but there is no guidance on when one might choose this over listing materials or other tools. The mention of extract_text for PDFs gives some context but not a clear decision framework.

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

• sync_nowA
  3.7/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 reveals the 'full' parameter behavior but omits whether the operation is destructive, requires authentication, has side effects (e.g., overwriting local data), or could be long-running. For a sync action, this lack of transparency 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.

  Conciseness5/5

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

  Two sentences, no fluff. The main action is front-loaded, and the parameter clarification is placed second. Every word earns its place, making it highly efficient and scannable.

  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?

  For a tool with only one optional parameter, no output schema, and no annotations, the description covers the core purpose and parameter behavior. However, it omits potential side effects, return behavior, or error conditions. Given the simplicity, it is minimally viable but could benefit from noting what happens after sync (e.g., confirmation, refreshed data availability).

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

  Parameters4/5

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

  Schema coverage is 0%, so the description must explain the parameter. It does: 'full walks every semester, not just the current.' This adds meaning beyond the schema's type/default and clarifies the semantic distinction. It's concise and functional, though it doesn't elaborate on edge cases or performance implications.

  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 states a clear action ('Refresh from MyCourseVille') with a specific resource and purpose. It distinguishes itself from sibling read-only tools (list_*, get_*) by being a synchronization operation, though it doesn't explicitly name an alternative. The verb 'Refresh' and resource 'MyCourseVille' make the purpose unambiguous.

  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 usage (use it to refresh data) but does not explicitly state when to use it versus alternatives like 'whats_new' or list tools. It does provide usage guidance for the 'full' parameter (full walks every semester), but no exclusion conditions or scenarios where other tools would be preferred. This is adequate but not explicit.

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

• list_gradesA
  4.5/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 of behavioral disclosure. It explicitly mentions that items not yet published appear with score 'Not ready' and released:false, and explains how to filter them. This is valuable behavioral detail that goes beyond the schema. It does not mention pagination or error conditions, but for a read-only list tool, the key behaviors 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 concise and well-structured: the first sentence states the core purpose, and the second paragraph provides a key behavioral nuance. Every sentence adds value with no redundancy or irrelevant details. The critical information about unpublished items is front-loaded.

  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 simple list tool with two optional parameters and no output schema, the description is nearly complete. It explains the parameters, the behavior around unpublished items, and the meaning of the output fields 'score' and 'released'. It falls slightly short by not specifying other output fields or potential response formats, but given the tool's simplicity, this is a minor gap.

  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 description coverage is 0%, so the description must compensate. It does so fully: cv_cid is explained as filtering to one course, and released_only is explained as hiding unpublished items. Both parameters receive meaningful semantic explanations that the schema lacks, making it easy for an agent to use them correctly.

  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 tool lists 'Graded items and their scores' with a specific verb and resource. It distinguishes itself from siblings like list_assignments (assignments vs. grades) and get_assignment (single assignment), making its purpose 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 the tool (to view grades, including outstanding items) and explains the released_only flag for hiding unpublished items. However, it does not explicitly contrast with siblings or state when not to use it, but the context is sufficient for an agent to infer the appropriate scenario.

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