Server Quality Checklist

Tool Scores

• classroom_patch_materialC
  2.6/5.0
  Behavior2/5

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

  Annotations already indicate readOnlyHint=false, and the description confirms a write operation. However, the description adds no behavioral context beyond that: no mention of partial updates via updateMask, effects on published/draft state, scheduling behavior, or what the response contains.

  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 wasted words. It front-loads the verb and resource, though it sacrifices useful detail for brevity.

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

  Completeness1/5

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

  With 8 parameters, no output schema, and only 25% schema description coverage, this description is far too sparse. It fails to mention the critical updateMask mechanism, the allowed fields, the required courseId/id, or the behavior of optional fields. An agent cannot reliably construct a correct request from this description alone.

  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 only 25%, and the description does not compensate by listing the updatable fields or explaining the updateMask requirement. The generic phrase 'Update fields' adds no meaning beyond the schema, leaving the agent to infer that fields like title, description, topicId, scheduledTime, and state are involved.

  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 identifies the verb ('Update') and the resource ('an existing material post'), making it distinct from create/list material tools. It is not as precise as naming the resource 'material' or differentiating from patch_assignment/patch_topic, but the core purpose is unmistakable.

  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 like classroom_patch_assignment, classroom_patch_topic, or classroom_patch_announcement. The description states only what the tool does, not the conditions or exclusions that would help an agent select it correctly.

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

• classroom_patch_topicC
  2.7/5.0
  Behavior2/5

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

  Annotations indicate readOnlyHint=false and openWorldHint=true, but the description adds no behavioral context about side effects, permissions, or potential impacts of renaming a topic. It does not contradict the annotations, but it also does not clarify what changes occur beyond the obvious rename.

  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 and front-loaded, using a single clear sentence with no filler or redundancy. It earns its place but is so minimal that it sacrifices useful detail.

  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?

  With no output schema, low schema parameter coverage, and annotations that only vaguely indicate mutability, the description is too thin to fully guide an agent. It does not explain return values, side effects, or what 'update a topic' changes beyond the topic name.

  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 only 33%, with only 'id' explicitly described as 'Topic ID'. The description does not explain that courseId identifies the course, id identifies the topic, and name is the new topic name, so most parameter meanings remain ambiguous.

  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 action ('rename or update') and a specific resource ('a topic'), which distinguishes it from sibling tools like classroom_get_topic, classroom_list_topics, and classroom_create_topic. It is not as sharply differentiated as some definitions because 'update' is broad, but the topic resource is explicit.

  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 gives no guidance on when to use this tool versus alternatives such as classroom_create_topic or classroom_patch_assignment. There is no mention of prerequisites, such as needing an existing topic, or any conditions under which a different tool should be used.

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

• classroom_post_announcementC
  2.7/5.0
  Behavior2/5

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

  Annotations already indicate a write operation (readOnlyHint=false). The description adds only the 'course stream' context. It does not disclose that the default state is DRAFT, meaning announcements may not be immediately visible in the stream, nor any scheduling or permission side effects.

  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 single sentence is concise, front-loaded, and contains no filler. However, it is perhaps too terse to be fully helpful, but that is a completeness issue rather than a conciseness defect.

  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?

  With 4 parameters, an unexpected state default, and no output schema, the description is too minimal. It does not explain the draft/published behavior, scheduling, how the announcement appears in the course stream, or how this operation relates to patching or listing announcements.

  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 only 25% (scheduledTime alone is described). The tool description fails to compensate by explaining the semantics of text, courseId, or the surprising state default of DRAFT versus PUBLISHED. An agent gets little help interpreting the parameters.

  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 specific verb ('post'), a resource ('announcement'), and a target location ('course stream'). This clearly distinguishes it from list_announcements and patch_announcement siblings, though it does not explicitly say 'create a new' or contrast with those alternatives.

  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 provided on when to use this tool versus the sibling classroom_patch_announcement or classroom_list_announcements. The verb 'post' implies creation, but the description does not mention exclusions, alternatives, or conditions for selecting this tool.

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

• classroom_update_courseC
  2.9/5.0
  Behavior2/5

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

  The annotations already indicate this is a mutating operation (readOnlyHint=false). The description adds little beyond that, and its statement that 'State can be ACTIVE or ARCHIVED' is misleading because the input schema allows PROVISIONED and DECLINED as well. No side effects, permissions, or response behavior are disclosed.

  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 compact sentence with the main action front-loaded. It wastes no words, though the state clause is both useful and partially inaccurate, preventing a perfect score.

  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 mutation tool with six parameters, no output schema, and minimal annotations, the description is notably incomplete. It does not mention the required courseId, the full set of state enum values, when the operation should be used, or any behavioral consequences.

  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?

  With 0% schema description coverage, the description carries the burden for explaining parameters. It only lists field names, does not explain their meanings, omits the required courseId parameter, and gives an incomplete/incorrect set of allowed state values. This provides marginal help and some misinformation.

  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 action ('Update'), the resource ('course fields'), and explicitly lists the fields involved. It is distinguishable from the get/list siblings and from patch tools targeting other resources, though it does not explicitly name a sibling alternative.

  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?

  Usage is implied rather than stated: an agent can infer this tool is for modifying course fields, but there is no explicit guidance about when to prefer it over alternatives or any preconditions. The absence of a course-update sibling lowers the need for exclusion logic, but guidance is still minimal.

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

• classroom_get_topicB
  3/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe read operation. The description adds no further behavioral detail such as error behavior or response characteristics, but it also does not contradict the annotations.

  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, front-loaded sentence with no filler words. It is concise but somewhat sparse, omitting useful context that could have been added without much length.

  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 read-only lookup with two required parameters and no output schema, the description is minimally viable. However, it does not explain courseId semantics, provide routing guidance among topic-related siblings, or cover what 'details' means in terms of the response.

  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?

  The schema covers only one of two parameters ('id' is described as 'Topic ID'), while 'courseId' has no description. The tool description merely repeats 'by ID' and does not clarify the role of courseId or how the two parameters relate, leaving a meaningful gap at 50% schema coverage.

  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 uses a specific verb ('Get') and resource ('details of a specific topic by ID'), which clearly communicates the core operation. It distinguishes itself from listing or creating topics, though it does not explicitly name any sibling alternative.

  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 gives no guidance on when to choose this tool over siblings such as classroom_list_topics or classroom_get_course. It only states what the tool does, leaving the agent to infer usage context without 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.

• classroom_create_assignmentB
  3.2/5.0
  Behavior3/5

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

  Annotations mark readOnlyHint as false, and the description's 'Create' is consistent, adding that this is a mutation that produces a new assignment or question. It does not disclose defaults like DRAFT state or the returned value, but the annotations and schema already carry part of the safety and mutation signal.

  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 core action ('Create an assignment or question') and then lists optional context. There is no filler or redundancy.

  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?

  With 11 parameters, low schema description coverage, and no output schema, the description does not cover important decisions such as DRAFT vs PUBLISHED state, scheduledTime, maxPoints, workType, or what the method returns. An agent would need to infer too much from names and enums.

  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 only 27%, and the description merely echoes 'attachments, due date, and topic' without explaining their types, required values, or behavior. It hints at workType through 'question' but leaves state, maxPoints, scheduledTime, dueTime, and attachment structure mostly unexplained.

  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 verb 'Create' and the resource 'assignment or question', and it names common optional aspects like attachments, due date, and topic. It is distinguishable from classroom_create_topic because the topic is an optional property rather than the primary resource, though it does not explicitly contrast with classroom_patch_assignment.

  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 word 'Create' implies this is for new assignments or questions, and sibling names like classroom_patch_assignment and classroom_create_topic hint at alternatives. However, there is no explicit guidance on when to use this instead of patching an existing assignment or when to create a topic first.

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

• classroom_create_materialB
  3.2/5.0
  Behavior3/5

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

  Annotations already indicate a mutating operation (readOnlyHint=false) and openWorldHint=true, so the baseline behavioral profile is covered. The description adds the resource type and optional parameters, but it does not disclose additional side effects such as notifications or scheduling behavior. No contradiction with annotations exists.

  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 one tightly front-loaded sentence with no filler; the verb and object appear first. It is efficient, though arguably too terse for the complexity of a seven-parameter creation tool.

  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?

  With seven parameters, no output schema, and little parameter documentation, a single sentence is not enough for an agent to invoke the tool correctly. Missing details include required courseId/title expectations, state defaults or scheduling effects, and what happens after creation. The description leaves significant room for guesswork.

  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 only 14%, so the description carries a heavy burden. It mentions attachments and topic, but leaves five parameters—including required courseId and title, plus state, description, and scheduledTime—without semantic explanation. This is insufficient compensation for the sparse 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 ('Create') and resource ('study material post'), and notes the optional attachments and topic scope. This clearly differentiates it from sibling tools like classroom_create_assignment and classroom_post_announcement by the 'material' resource type.

  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 like creating an assignment, announcement, or topic. The description only states what the tool does, leaving the agent to infer selection criteria from sibling names.

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

• classroom_create_topicB
  3.3/5.0
  Behavior2/5

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

  Annotations already signal a mutating, open-world operation (readOnlyHint=false, openWorldHint=true), but the description adds no further behavioral detail. It does not mention permissions, idempotency, duplicate-name behavior, or what happens after successful creation, so the agent has limited expectations beyond 'this creates something.'

  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, concise, front-loaded sentence with no filler or repetition. Every word contributes to identifying the action, resource, and context.

  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 two-parameter create tool, the one-line purpose is close to adequate, especially with annotations present. However, it lacks usage guidance and behavioral outcome detail, and there is no output schema to fill in expected return behavior, so the description is only partially complete.

  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?

  With 0% schema description coverage, the description provides minimal compensation by implying that courseId identifies the course and name is the new topic name. This partially clarifies both required parameters, though it does not document formats, examples, or constraints 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 action and resource ('Create a new topic/unit') and a clear scope ('in a course'), so an agent can easily tell what the tool does. It is distinguishable from sibling read/update tools like classroom_list_topics and classroom_patch_topic.

  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 explicit when-to-use or alternative guidance is given. The verb 'Create' only implies it is for new topics, but it never says to use patch_topic for updates or list_topics to find existing ones, and it does not mention prerequisites such as the course already existing.

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

• classroom_patch_announcementB
  3.3/5.0
  Behavior2/5

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

  Annotations only indicate readOnlyHint=false and openWorldHint=true; the description adds little beyond restating that the tool mutates an existing announcement. It does not disclose partial-update semantics, the role of updateMask, or any effects or prerequisites.

  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 sentence with no filler or repetition. It communicates the essential purpose economically.

  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 six parameters, a required updateMask, and no output schema, the description is not sufficient to guide correct invocation. The agent must discover updateMask semantics and field options from the schema, and there is no guidance on return values or side effects.

  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?

  The description provides no parameter-level meaning, and schema description coverage is only 33%, with id, text, state, and courseId lacking descriptions. The updateMask and scheduledTime schema descriptions carry the only semantic load; the description does not 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 the specific verb 'Edit' and identifies the resource 'an existing announcement,' clearly distinguishing this from sibling tools like classroom_post_announcement (create) and classroom_list_announcements (read).

  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 phrase 'Edit an existing announcement' implies usage for modifying an existing resource, but it provides no explicit when-to-use or when-not-to-use guidance and names no alternatives. An agent must infer that creation belongs to classroom_post_announcement.

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

• classroom_list_assignmentsA
  3.5/5.0
  Behavior4/5

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

  Annotations already indicate readOnlyHint and openWorldHint. The description adds concrete behavior beyond that: 'Returns one page as {items, nextPageToken}; continue until nextPageToken is null.' This gives the agent the pagination contract and confirms a read-only listing operation. No contradiction with annotations.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the core verb and resource, then adds filtering and pagination details. Every sentence contributes meaningful information and there is no 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 paginated list endpoint, the description does provide the return shape and continuation rule, which is important since no output schema exists. However, it omits the meaning of fullData and pageSize, and it does not explain what an 'item' contains. This makes the description adequate but not fully complete.

  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 only 20%, so the description must compensate. It mentions 'Supports filtering by state' for courseWorkStates and implies pageToken via the pagination note, but it does not explain fullData, pageSize, or the semantics of courseId beyond the obvious. With 5 parameters and most undocumented, this is a clear gap.

  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 specific action and resource: 'List coursework (assignments/questions) for a course.' This clearly separates it from sibling tools like classroom_get_assignment, classroom_create_assignment, and classroom_patch_assignment, even though it does not name them explicitly. 'Supports filtering by state' adds useful scoping.

  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 the tool: when listing coursework for a course and optionally filtering by state. It also explains how pagination works, which is useful. However, it does not explicitly contrast with alternatives such as classroom_get_assignment for a single item or list tools for other resource types.

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

• classroom_patch_assignmentA
  3.5/5.0
  Behavior3/5

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

  Annotations already signal that this is not read-only, and the description adds a mild behavioral trait: only supplied fields are updated via updateMask. It does not disclose broader side effects, prerequisites, or handling of omitted/unset fields, but for a simple patch it passes a bare-minimum bar.

  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, compact sentence with no redundant words. It front-loads the action and object and states the key mechanism before any extra detail.

  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 an 11-parameter patch tool with no output schema and low parameter coverage, this description is too terse to fully guide invocation. It omits updateMask construction, required-parameter context, field dependencies, and any indication of what the response contains.

  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?

  With 45% schema description coverage, the description needed to compensate by explaining key parameters or updateMask usage, but it only restates the updateMask concept. It adds no meaning for courseId, id, state, title, topicId, maxPoints, or description beyond what the schema does.

  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?

  It clearly states the verb (Update), the target resource (existing assignment), and the mechanism (using updateMask). This distinguishes it from sibling creation, listing, and retrieval tools by the patch-on-existing-assignment operation.

  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 phrase 'existing assignment' implies this is for modifying an already-created assignment rather than creating or reading one. However, it gives no explicit guidance about when to prefer this over sibling tools or what circumstances make it inappropriate.

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

• classroom_get_assignmentA
  3.6/5.0
  Behavior3/5

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

  The annotations already declare readOnlyHint and openWorldHint, so the read-only nature is covered. The description adds 'full details,' which hints at the response shape, but it does not disclose error behavior, permissions, or other operational traits. It is acceptable but minimal.

  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 sentence with no filler or repetition. It efficiently communicates the core purpose without unnecessary detail.

  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 two-parameter read-only getter, the description is nearly sufficient. However, the lack of clarification about how the two IDs map to courseId and id, combined with no output schema, leaves some ambiguity for an agent deciding how to call it correctly.

  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 only 50%, with only 'id' described in the schema. The description adds no meaning for 'courseId' and uses the generic phrase 'by ID,' which does not clarify that both courseId and id are required identifiers. It fails to compensate for the schema's missing courseId description.

  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 specifies the action ('Get'), the resource ('assignment'), and the scope ('full details ... by ID'). This immediately distinguishes it from list-oriented siblings such as classroom_list_assignments without needing to inspect the schema.

  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 phrase 'specific assignment by ID' implies this tool is for retrieving one known assignment rather than listing assignments, but it never explicitly names alternatives or states when not to use it. Guidance is present only implicitly.

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

• classroom_get_materialA
  3.6/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, and the description's 'Get' is consistent. It adds 'full details' and by-ID scoping, but does not disclose auth requirements, error behavior, or what 'full details' includes. Given the annotation coverage, this is acceptable but not rich.

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

  Conciseness5/5

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

  One sentence with no filler, front-loaded with the operation and object. It is appropriately compact for a simple getter tool.

  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 definition is enough for a basic read call, but without an output schema or return description, 'full details' is vague. It also omits the relationship/requirement of courseId and how to discover the material ID, such as via classroom_list_materials. These gaps make it only minimally complete.

  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?

  Only 50% of parameters have schema descriptions: id is described as 'Material ID', but courseId has no description. The description says 'by ID' but does not clarify that both the material id and its parent courseId are required or how they relate. It adds little 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 states the verb 'Get', the resource 'course material', and the scope 'specific ... by ID', which clearly distinguishes it from list-oriented siblings like classroom_list_materials. The phrase 'full details' further separates it from summary-list operations.

  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 this tool is for retrieving one known material by ID, but it does not explicitly say when to use alternatives such as classroom_list_materials when the ID is unknown. There is no when-not-to-use or alternative routing, so usage guidance remains implied rather than explicit.

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

• classroom_get_courseA
  3.8/5.0
  Behavior3/5

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

  The readOnlyHint annotation already covers the safety profile, so the description does not need to repeat that. However, the description adds no behavioral details beyond that, such as error behavior or what 'full details' includes.

  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 sentence with no filler. Every word adds meaning and the key distinction ('by ID') is included.

  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 read-only getter with one required parameter and readOnlyHint=true, the description is largely sufficient. It explains what the tool returns ('full details') and the lookup method, though it does not describe error or not-found behavior.

  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%, but the single parameter courseId is self-explanatory and the description reinforces it by saying the course is retrieved 'by ID'. No additional format, source, or usage semantic is provided, but none is strictly needed for this simple parameter.

  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 ('Get') and resource ('full details of a specific course'), and clarifies the selection mechanism ('by ID'). This clearly distinguishes it from list/search/update siblings.

  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 'by ID' phrasing implies the tool should be used when a course ID is already known, but there is no explicit guidance about when to prefer list_courses or search_courses instead. Usage context is implied rather than explicitly stated.

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

• classroom_list_topicsA
  3.8/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds valuable behavior beyond that: a single call returns only one page shaped as {items, nextPageToken}, and the caller must loop until the token is null. This is exactly the behavioral trait an agent needs for a paginated 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.

  Conciseness5/5

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

  Two sentences with zero waste: the purpose is front-loaded first, and the return shape plus iteration rule follow compactly. Every word earns its place, including the high-density '{items, nextPageToken}' notation.

  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 list tool with annotations covering safety and no output schema, the description adequately documents the return shape and pagination loop. The clear gap is fullData's semantics, which is left completely undocumented; minor omissions include item ordering and explicit routing to sibling topic tools.

  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 bears the full burden for parameter meaning. It compensates for pageToken via the pagination contract and loosely implies courseId and pageSize, but fullData is never mentioned anywhere — an agent cannot infer what true versus false requests, and pageSize/pageToken semantics are not explicitly stated either.

  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 specific verb (List), resource (topics), and scope (in a course), which cleanly distinguishes it from siblings like classroom_get_topic, classroom_create_topic, and classroom_patch_topic. An agent can tell what this tool does without opening the schema.

  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 pagination instruction ('continue until nextPageToken is null') is genuine usage guidance for fully consuming results, and 'in a course' implies the calling context. However, the description never explicitly addresses when to choose this over alternatives such as classroom_get_topic, leaving tool-selection guidance implied rather than stated.

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

• classroom_search_coursesA
  3.8/5.0
  Behavior5/5

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

  The annotations cover read-only behavior, but the description adds essential behavioral detail: it is a client-side filter, case-insensitive, returns exactly one page with the shape {items, nextPageToken}, and requires the caller to continue until nextPageToken is null. This goes well beyond the structured annotations.

  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 short sentences deliver the essential search behavior and pagination contract with no filler. The most important behavioral details are 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 paginated read-only search with no output schema, the description provides the return shape and termination condition, which is enough for basic correct invocation. The main gap is the undocumented fullData parameter, but the schema's default and the overall simplicity keep this from being severely 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 coverage is only 25%, with fullData, pageSize, and pageToken lacking schema descriptions. The description explains query meaning and implies pageToken usage through the return contract, but fullData remains completely unexplained and pageSize semantics are only inferred.

  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 verb 'Search' and the resource 'courses', and adds that search is by name or section, case-insensitive, and client-side. This distinguishes it from classroom_list_courses and classroom_get_course, though it does not explicitly name a sibling alternative.

  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 this tool is for filtered, case-insensitive searches on course name or section rather than for listing or retrieving a specific course. However, it never explicitly states when to prefer this over classroom_list_courses or provides any exclusion criteria.

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

• drive_upload_fileA
  3.8/5.0
  Behavior3/5

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

  The description matches the annotations (write operation, readOnlyHint=false) by saying 'upload', and it adds that the result is an ID and URL. However, it does not disclose other behavioral traits such as duplicate-name behavior, overwrite semantics, permission requirements, or failure modes. Useful but minimal.

  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 active sentence that front-loads the action and target, includes the essential return value, and contains no filler or repeated schema information.

  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 is adequate for a simple upload: it states what the tool does and what it returns, which partially compensates for the missing output schema. It still leaves operational context unexplained, such as how `name` is interpreted, whether duplicate names create new files, and Drive permission/size constraints beyond the schema's raw maxLength.

  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?

  With 0% schema description coverage, the description needed to compensate by explaining `name`, `mimeType`, and `base64Content`; it only paraphrases `base64Content` as 'base64-encoded file' and leaves `name` and `mimeType` semantics entirely to inference. The schema defaults and patterns do most of the work.

  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 names a specific action ('Upload'), an input encoding ('base64-encoded'), a destination ('Google Drive'), and the returned values ('Drive file ID and URL'). This makes the purpose explicit and distinguishes it from the Classroom/Slides sibling tools without ambiguity.

  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 call the tool: whenever a base64-encoded file needs to be uploaded to Google Drive. It does not list when-not cases or alternative Drive tools, but none of the sibling tools perform this operation, so no explicit exclusion is necessary.

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

• classroom_list_announcementsA
  3.9/5.0
  Behavior4/5

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

  Annotations already mark the tool as read-only and open-world, so the description's main contribution is the explicit pagination contract: returns one page as {items, nextPageToken} and tells the caller to continue until nextPageToken is null. This is valuable behavioral context beyond the annotations. It does not explain fullData or announcementStates, but core behavior is disclosed.

  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: the first states the purpose, the second gives the pagination loop. Every word earns its place, and there is no redundant restating of the tool name or schema.

  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?

  With no output schema and 0% parameter coverage, the description is incomplete for safe and correct invocation. It handles courseId and pageToken adequately, but fullData and announcementStates are completely unexplained, leaving an agent to guess their effects. The pagination instruction is helpful but does not compensate for the missing parameter semantics.

  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 by explaining parameters. It implies courseId and indirectly explains pageToken through the pagination contract, but fullData, pageSize, and announcementStates are left entirely undefined. An agent would not know what fullData does or how to filter states without external knowledge.

  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 specific verb and resource: list announcements for a course. This clearly distinguishes it from siblings like classroom_post_announcement and classroom_patch_announcement, and the pagination note adds important scope. There is no ambiguity about the core operation.

  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 context is clear: this is for reading course announcements, and the description points out the one-page-at-a-time behavior. It does not explicitly mention alternatives such as post/patch, but the operation is intuitive from the name and the sibling list. No misleading usage guidance is present.

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

• classroom_list_coursesA
  3.9/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and openWorldHint=true, and the description adds valuable behavior: only one page is returned as {items, nextPageToken}, and callers must continue until nextPageToken is null. However, it omits that courseStates also permits DECLINED and SUSPENDED, which slightly reduces 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?

  Two sentences with no filler: purpose, filter support, and pagination behavior are each stated once. The most important information is front-loaded and every sentence earns its keep.

  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 adequately covers core list/pagination behavior and state filtering, and the readOnly annotation covers the safety profile. But with no output schema and low schema description coverage, the lack of any explanation for fullData and pageSize, plus the incomplete state list, leaves noticeable gaps.

  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 only 25%, but the description partially compensates by explaining courseStates values and the pageToken-based continuation. pageSize is reasonably inferable from its name and limits, but fullData is entirely unexplained in both schema and description, leaving a real gap.

  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 uses a specific verb ('List') and resource ('Google Classroom courses'), with a clear scope ('all') and state-filtering behavior. It is clear but does not explicitly distinguish itself from the sibling classroom_search_courses, so it misses the top score.

  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 clear context for when to use the tool: to list all courses or filter by state, and to paginate by following nextPageToken until null. It does not name sibling alternatives such as classroom_search_courses or state when not to use this tool, so it falls short of explicit exclusions.

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

• slides_get_presentationA
  3.9/5.0
  Behavior3/5

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

  The readOnlyHint annotation already establishes that this is a safe read operation, and the description is consistent with it. The description adds useful context that the response includes slide text and structure, but it does not go into error behavior, authentication needs, or additional output details.

  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 sentence with no filler. It puts the verb and resource first, and every phrase adds useful meaning.

  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 one-parameter, read-only getter, the description covers what it operates on and what the response contains. Between the annotations covering safety and the schema covering the parameter, nothing essential is missing for an agent to 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 100%, so the single parameter is already fully documented. The description's phrase 'by ID' restates the parameter's role without adding extra format, constraints, or usage nuance.

  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 specific action ('Read') and a specific resource ('Google Slides presentation by ID'), and clarifies what is included in the result ('slide text and structure'). This clearly distinguishes it from the classroom and drive sibling tools, none of which read Slides presentations.

  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?

  No explicit when-to-use guidance or alternative tools are mentioned. The resource name and description imply this is the tool for reading a Slides presentation by ID, but no exclusions or comparison to siblings are provided.

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

• classroom_list_materialsA
  4/5.0
  Behavior4/5

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

  Annotations already provide readOnlyHint and openWorldHint, but the description adds meaningful runtime behavior: it returns one page as {items, nextPageToken} and requires callers to continue until nextPageToken is null. This pagination contract is not available from the annotations or the sparse schema descriptions.

  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 filler. The first defines the tool's purpose and the second immediately provides the critical pagination contract, making the description easy to parse and act on.

  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 gives a usable return shape and pagination loop, which is valuable given there is no output schema. However, it omits the optional filtering and verbosity controls such as courseWorkMaterialStates and fullData, leaving non-default usage under-specified.

  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 only 20%, so the description must compensate, but it does not. The description only implicitly mentions pageToken via nextPageToken and leaves fullData, pageSize, and courseWorkMaterialStates unexplained beyond their names.

  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 specific verb, 'List', and a specific resource, 'non-graded materials for a course'. This clearly distinguishes the tool from sibling tools like classroom_list_assignments and classroom_list_announcements without needing to inspect the schema.

  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 phrase 'non-graded materials' gives clear context for when the tool is appropriate and implicitly excludes graded assignments. However, it does not explicitly name alternatives or say when not to use it, stopping short of full routing guidance.

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