Server Quality Checklist

Tool Scores

• classroom_list_announcementsA
  3.8/5.0
  Behavior4/5

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

  Annotations already indicate readOnly, idempotent, and non-destructive behavior. The description adds useful context by stating that attachments are included and by enumerating the exact returned fields, which goes beyond the annotations and helps the agent understand the tool's output.

  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 front-loaded with the primary action and uses a clear Args/Returns structure, making it easy to scan. The Args section is somewhat redundant with the input schema, but the overall length is appropriate and there is no unnecessary prose.

  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?

  The tool has one required parameter and simple optional parameters, and the description covers the course scope, limit behavior, response format, and the complete set of returned fields. With no output schema present, the explicit Returns list is sufficient for correct invocation.

  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 67%, and the description lists all three parameters but mostly restates the schema. It repeats course_id as 'Course ID', limit's default/range, and response_format's enum/meaning, adding no deeper semantics beyond what the input schema already provides.

  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 opens with 'List announcements posted to a course stream, including any attachments,' which clearly names the verb, resource, and scope. It is distinct from sibling tools by resource type, but it does not explicitly differentiate itself from tools like classroom_list_coursework or classroom_list_topics.

  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 intended use is implied: use this tool when you need announcements from a course stream, especially with attachments. However, there is no explicit when-to-use or when-not-to-use guidance and no mention of alternative sibling list tools, so the agent must infer selection from the resource name.

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

• classroom_list_courseworkA
  3.8/5.0
  Behavior4/5

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

  Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior. The description adds useful behavioral context by outlining exactly what is returned, including materials, due dates, points, and topic associations. 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 front-loaded with the purpose, then follows a clean Args/Returns structure. Every sentence carries useful information, with no fluff or redundant restatement of the tool name.

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

  Completeness4/5

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

  Given there is no output schema, the Returns section does a good job enumerating the important fields. It could be slightly more complete by clarifying how response_format changes the output or by noting edge cases, but the core calling context is adequately covered.

  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 75%, and the description restates all four parameters with brief meanings. It adds some value for the 'limit' parameter (which the schema lacks a description for) and clarifies 'topic_id' as a restriction, but it does not go deeper with examples or parameter relationships.

  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 ('List') and resource ('coursework (assignments, questions)') scoped to a course, and enumerates the key returned attributes. However, it does not explicitly distinguish itself from sibling tools like classroom_list_materials or classroom_list_submissions, which could overlap in an agent's mind.

  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 intended use is implied: use this to list assignments/questions in a course, optionally filtered by topic. But there is no explicit guidance about when not to use it or which sibling tool to prefer for materials-only or submission-only needs.

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

• classroom_list_materialsA
  3.9/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is well covered. The description adds useful semantic scope by clarifying it returns CourseWorkMaterials rather than assignments, but it does not disclose additional operational behavior such as pagination behavior, auth requirements, or list completeness. It is not contradicted by any annotation.

  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 core distinction is front-loaded in a single, clear sentence. The Args and Returns sections are compact and scannable, and every part earns its place. There is mild duplication with the input schema, but no filler or unnecessary prose.

  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?

  Since there is no output schema, the description appropriately lists the returned fields in the Returns section. It covers all parameters, the output format options, and the material type scope. Minor gaps remain around pagination behavior and any auth or error conditions, but the annotations already cover the read-only and idempotent nature of the operation.

  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 75%, and the description mostly restates what the schema already provides. It adds minor clarification with 'Restrict to one topic' for topic_id and fills in the missing schema description for limit with 'Max items 1-200 (default 50)', but most parameter meaning is already present in the schema. This adds some value but does not go beyond a baseline level.

  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 opens with a specific verb and resource: 'List CourseWorkMaterials'. It clearly distinguishes these from assignments, which immediately separates this tool from sibling tools like classroom_list_coursework. The phrase 'posted reading/lesson materials' and 'what teachers typically use for lessons and resources' removes any ambiguity about the tool's purpose.

  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 contextual guidance by stating these are materials that are NOT assignments, which tells an agent not to use this tool when the goal is assignments. It does not explicitly name sibling alternatives such as classroom_list_coursework or classroom_list_announcements, so it falls just short of full explicit routing guidance.

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

• classroom_list_topicsA
  4/5.0
  Behavior3/5

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

  Annotations already declare the operation read-only, idempotent, open-world, and non-destructive. The description adds useful context about what is returned and how topics are used, but it does not disclose additional behavioral traits such as pagination, ordering, or potential error cases. No contradiction 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 concise and front-loaded with the core purpose. The extra sentences about what topics represent and how to use topic IDs add value without excessive length, though the Args block duplicates schema details.

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

  Completeness5/5

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

  For a simple list operation, the description covers the return content (topicId and name), the relationship to sibling tool classroom_list_coursework, and the role of the main parameter. The annotations cover safety, so no critical behavioral information is missing for correct invocation.

  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%: course_id and response_format are both documented with types, defaults, and source guidance. The description's Args section mostly restates schema information, so it adds little beyond what the schema already provides.

  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 all topics ... within a course.' It also clarifies what topics are in the teacher/classroom context, making the tool's purpose unambiguous and distinguishable from sibling listing tools like classroom_list_coursework or classroom_list_courses.

  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 clearly implies when this tool is useful: to obtain topic IDs for a course, and then pass each topicId to classroom_list_coursework. It provides actionable usage context but does not explicitly state when not to use it or compare it against alternatives like classroom_list_announcements.

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

• classroom_reclaim_submissionA
  4/5.0
  Behavior4/5

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

  Annotations already indicate readOnlyHint=false and idempotentHint=false, and the description adds useful behavioral context: the operation is equivalent to Unsubmit, works only in TURNED_IN state, and returns a confirmation. This goes beyond the annotations without contradicting them.

  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 compact and front-loaded: the action and equivalence appear first, followed by necessary preconditions and a brief Args/Returns structure. Every sentence adds information; there is no filler or repetition.

  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 core action, precondition, and return type are covered, which is adequate for a simple three-string-parameter tool. However, it does not explain where course_id and coursework_id come from, nor the side effects on the submission beyond 'make edits'. These are notable gaps given no output schema and sparse parameter documentation.

  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 33%; only submission_id has a description ('From classroom_list_submissions'). The description's Args section merely lists names and says they are strings, adding no meaning for course_id or coursework_id. Given the low coverage, the description should compensate but does not.

  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: 'Reclaim a turned-in submission (pull it back to make edits)', with a well-understood equivalent, 'Unsubmit'. It distinguishes the tool from its opposite sibling classroom_turn_in_submission 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?

  It gives explicit preconditions: 'Only works if the assignment still allows it and state is TURNED_IN.' This is clear context and even a when-not condition, though it does not explicitly name alternative tools for different submission states.

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

• classroom_create_announcementA
  4.1/5.0
  Behavior4/5

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

  Annotations already establish non-read-only, non-idempotent, non-destructive behavior. The description adds the authorization requirement and the return value ('The new announcement's id'), which are behavioral details beyond the annotations. It does not describe side effects like notifications, but the annotation set lowers that burden.

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

  Conciseness5/5

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

  The description is three short, tightly packed components: action+prerequisite, args, and return. It is front-loaded and contains no filler or redundant explanation.

  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?

  Covers the action, authorization requirement, arguments, and return ID, which is nearly everything needed. The only notable gap is that course_id is not explicitly tied to classroom_list_courses, but that is inferable from the sibling tool set.

  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 Args section merely restates the schema's types and length bounds, adding no new meaning. With schema description coverage at 50%, the description needed to clarify what course_id refers to or how to obtain it, but it does not. The text parameter gains no value beyond the schema's existing 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 opens with a specific verb+resource: 'Post an announcement to a course stream.' This clearly distinguishes the tool from sibling list/read tools and from classroom_create_topic. The teacher-rights qualifier further pins down intended use.

  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?

  It states a meaningful precondition ('Requires teacher rights'), giving the agent clear context for when invocation is appropriate. It does not explicitly name alternatives or when-not conditions, but the action is specific enough that confusion with read-only sibling tools is unlikely.

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

• classroom_list_rosterA
  4.1/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds useful behavioral context by specifying the return fields and the caveat that email visibility depends on scope and domain permissions.

  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 compact and well-structured: a one-sentence purpose, an Args list, and a Returns line. There is no fluff, though the Args block partially duplicates the schema.

  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?

  With no output schema, the Returns line is valuable and explains what the agent will receive. It covers role, limit, response format, and email visibility caveats. It omits pagination or error behavior, but for this simple read-only roster tool, the description is adequately 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?

  The Args section largely restates what the input schema already provides. It does add a human-readable constraint for limit ('Max 1-200 (default 100)'), which the schema only expressed via min/max/default values, but it does not deeply enrich course_id or response_format beyond the 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 opens with 'List students or teachers enrolled in a course,' which is a specific verb and resource. This clearly distinguishes it from sibling list tools such as classroom_list_courses, classroom_list_coursework, and classroom_list_announcements.

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

  Usage Guidelines4/5

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

  The description provides clear context for when to use this tool: fetching roster members for a course. It does not explicitly name alternatives or state when not to use it, but the purpose is unambiguous enough that an agent can route correctly.

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

• classroom_turn_in_submissionA
  4.1/5.0
  Behavior5/5

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

  It discloses that the tool mutates submission state, is not trivially reversible, and names the reclaim tool for undoing it. This adds meaningful context beyond the annotations, which only indicate readOnlyHint=false and idempotentHint=false.

  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 compact and front-loads the core purpose, then adds state requirements, return info, and reversal guidance in a structured way. The Args list is somewhat redundant with the schema, but the overall length is appropriate.

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

  Completeness4/5

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

  The description provides the critical state precondition, the mutation behavior, and the reversal path, which are essential for correct use. Missing details like error behavior for invalid states or fuller parameter semantics leave minor gaps, but the tool is otherwise well-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 33%, with only submission_id having a description. The description merely lists param names and types but does not explain course_id or coursework_id beyond what the schema already shows, failing to compensate 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: turning in/submitting a student assignment submission, with the concrete analogy of clicking 'Turn in'. It names the required state (CREATED or NEW) and is distinct from sibling tools like listing or reclaiming submissions.

  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 conveys when to use this tool: to submit work to the teacher, and only when state is CREATED or NEW. It also explicitly points to the reclaim sibling for reversing the action if allowed, giving useful guidance for choosing alternatives.

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

• classroom_list_submissionsA
  4.2/5.0
  Behavior4/5

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

  Annotations already establish safety and idempotency, so the description does not need to repeat that. It adds genuine behavioral context: role-dependent visibility, the submission state enum, late/grade fields, attachments, and the connection to write tools. This goes well beyond the structured annotations without contradicting them.

  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 compact and well organized: purpose first, then arguments, then returns. The only mild redundancy is that the Args list repeats schema properties, but the overall text is short, scannable, and free of filler.

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

  Completeness5/5

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

  For a simple read-only tool with no output schema, the description supplies the essential usage context: role-based behavior, returned fields, and how to use the submission id afterward. All parameters are covered by the schema, and safety is covered by annotations, so nothing required for correct invocation is missing.

  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 coverage is 100%, so the schema already fully documents course_id, coursework_id, and response_format, including defaults and enum values. The Args section in the description largely mirrors the schema rather than adding new parameter-level meaning, so the baseline score of 3 is appropriate.

  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 first sentence names a specific verb and resource: 'List student submissions for a specific assignment.' This clearly distinguishes the tool from sibling list tools like classroom_list_courses, classroom_list_topics, and classroom_list_coursework. The role-based visibility note ('student... own; teacher... all') further pins down exactly what the tool does and what results to expect.

  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 clearly indicates when to use it: with a course_id and coursework_id to list submissions for a particular assignment. It also points the agent to related write tools by noting the submission id is used with turn-in/attachment tools, which helps with subsequent tool selection. It does not explicitly name an alternative list tool or provide a when-not-to-use condition, but among the siblings this is the only submission-list tool.

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

• classroom_create_topicA
  4.3/5.0
  Behavior4/5

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

  Beyond the annotations, the description discloses an important precondition (teacher rights) and a failure mode (permission error for students). It also states that the call returns the new topic's id and name. This adds useful behavioral context beyond readOnlyHint=false.

  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 compact and well organized: purpose, permission note, args, and return value. Each sentence earns its place, and there is no redundant filler.

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

  Completeness5/5

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

  For a simple two-parameter create operation, the description covers the essential context: required permissions, failure mode, and return shape. Since there is no output schema, providing the return value is important and is handled 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?

  The parameter section restates the schema's types and constraints: course_id as string and name as string with 1-100 chars. Since schema coverage is only 50% and course_id has no description in the schema, the description adds marginal value by listing it, but it does not explain what course_id refers to or how to obtain it.

  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 opens with a specific verb and resource: 'Create a new topic in a course.' It names the target (topic), the scope (course), and the role (teacher), clearly separating it from sibling tools like classroom_create_announcement or classroom_list_topics.

  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?

  It gives clear context by stating that teacher rights are required and that student accounts will receive a permission error. It does not explicitly name alternatives or say 'use this instead of X,' but the resource-specific language makes the intended use obvious.

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

• classroom_dump_courseA
  4.3/5.0
  Behavior4/5

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

  Annotations already cover read-only, idempotent, non-destructive behavior, so the description focuses on additional behavioral traits: nested grouping, per-category caps, optional announcements, and truncation of descriptions in large dumps. This adds meaningful context beyond the annotated safety profile, though it could be more explicit about what happens when a category exceeds the cap.

  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 well-structured with a front-loaded purpose sentence, a compact Args list, and a valuable Returns paragraph. The Args section duplicates schema details and could be trimmed, but the overall length is justified by the useful behavioral and usage guidance.

  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?

  There is no output schema, so the description fully specifies the return shape, including nested topics, no_topic grouping, and announcements. It also covers truncation behavior and attachment handling. Minor gaps remain around error conditions and pagination beyond the cap, but the description is largely complete for this read-only aggregation tool.

  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 input schema provides 100% coverage of all parameters, including defaults, ranges, and enums. The description's Args section repeats this information almost verbatim without adding new semantics, so it earns the baseline 3 for schema-covered parameters.

  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 this tool fetches a course's full structure in one call, with topics, coursework, materials, and optional announcements nested. It distinguishes itself from the per-resource sibling tools by being 'the fastest way to get a complete picture of a class.' No ambiguity remains about what resource is operated on.

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

  Usage Guidelines5/5

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

  The description explicitly positions this as the go-to for a full course snapshot and directs users to per-resource tools when full detail is needed due to truncation. It also tells users how to read attachment text via drive_fetch_file_content, providing clear when-to-use and when-not-to-use guidance.

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

• classroom_list_coursesA
  4.3/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond the annotations by specifying return fields, default state filtering, and how the returned course ids connect to other tools.

  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 tightly structured with a one-sentence purpose, an Args list, and a Returns note. Every sentence earns its place, and the most decision-relevant information—what the tool lists and what to do with the output—is front-loaded.

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

  Completeness5/5

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

  For a simple list tool with no output schema, the description fully explains the return values and includes the important integration instruction to use returned course ids with other tools. Combined with complete parameter schemas and strong annotations, nothing essential is missing.

  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 schema fully documents all three parameters. The description repeats the parameter meanings and defaults but does not add significant meaning beyond the schema, so a baseline of 3 is appropriate.

  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'), a clear resource ('Google Classroom courses'), and a scope ('the authenticated user is enrolled in or teaches'). This clearly distinguishes it from sibling list tools such as classroom_list_topics and classroom_list_coursework.

  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: this is the entry point for listing courses, and it explicitly tells the agent to use the returned course id with other tools. It does not explicitly name alternatives or state when not to use this tool, but the resource scope makes the usage situation clear.

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

• classroom_whoamiA
  4.3/5.0
  Behavior4/5

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

  Annotations already establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful context by emphasizing that this is a read-only check of the 'currently authorized' account and implying that fixing an incorrect account requires external steps like deleting token.json and re-running npm run auth rather than changing state through this 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 front-loaded with the core purpose, followed by a concise use case, a practical troubleshooting note, the argument list, and the return value description. Every sentence earns its place, and nothing is redundant or padded.

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

  Completeness5/5

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

  For a simple, read-only tool with one optional parameter and no output schema, the description is fully sufficient. It states what the tool returns (email, name, id), how to invoke it, and how to interpret the response_format parameter, so an agent has everything needed to call 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?

  There is only one optional parameter, response_format, and the input schema already fully documents it with an enum, a default, and a description. The description's Args section repeats that information without adding meaningful semantic detail beyond what the schema provides, so the baseline 3 applies.

  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 opens with a specific verb and resource: 'Show which Google account this server is currently authorized as.' It clearly differentiates this tool from the classroom_* siblings, which all operate on Google Classroom data rather than on the authorization identity itself.

  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 explicitly tells the agent when to use this tool: 'Use this to confirm the server is pointed at the Google login that actually holds your classes.' It also provides actionable remediation for the wrong-account case, though it does not discuss when not to use it or name alternatives because no real sibling alternative exists.

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

• drive_fetch_file_contentA
  4.5/5.0
  Behavior5/5

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

  The description richly discloses behavior beyond the annotations: per-file-type export behavior, binary-file fallback to metadata and link, truncation with a note, and specific error handling for 403 and 404. Annotations already mark the tool read-only and idempotent, and the description adds valuable operational context without contradicting them.

  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 well organized with a clear lead sentence followed by concise bullets for file-type handling, arguments, return value, and errors. Every section serves an operational purpose and the most important behavior is front-loaded.

  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 tool with no output schema, the description sufficiently explains what will be returned, how different file types are treated, what happens with binary files, and how to handle common errors. Combined with the annotations and complete input schema, an agent has everything needed to invoke the tool correctly and interpret results.

  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 coverage is 100%, so the baseline is 3. The description repeats the parameter names and enum values already present in the schema and adds only minor clarification about where drive_file_id comes from. It does not substantially extend the schema's parameter explanations, but it does not need to given full coverage.

  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 the text content') applied to a specific resource ('Google Drive file attached to Classroom coursework, materials, or announcements'). It clearly differentiates the tool from the sibling classroom_* tools, which primarily list or manage Classroom data rather than fetch and interpret attachment file contents.

  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: use this when you have a Drive file id from a Classroom attachment and need its readable text content. It does not explicitly name sibling alternatives or state when not to use the tool, but the unique purpose and detailed handling instructions make the intended usage unambiguous.

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

• classroom_attach_to_submissionA
  4.8/5.0
  Behavior4/5

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

  The description discloses the mutating nature, the required before-turn-in state, the one-of constraint, and the return confirmation. This goes beyond the annotations, which already indicate a non-read-only, non-idempotent, non-destructive operation; no contradiction exists.

  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 compact and front-loaded with the most important guidance ('BEFORE turning it in'), followed by a clear argument list and return note. Every sentence adds value without redundancy.

  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 tool with no schema-declared parameters and no output schema, the description covers all necessary invocation details: required IDs, optional attachment selection, the one-of requirement, sequencing, and the return confirmation.

  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?

  Although the input schema is empty, the description manually documents all five parameters with types, optionality, and the exactly-one constraint. This fully compensates for the missing schema information and directly guides the agent on what to provide.

  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: 'Attach a Drive file or link to a student submission'. It also distinguishes itself from the sibling classroom_turn_in_submission by emphasizing the BEFORE turning it in ordering.

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

  Usage Guidelines5/5

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

  The description explicitly instructs to add attachments first and then call classroom_turn_in_submission, giving clear sequencing and naming the sibling alternative. It also clarifies that exactly one of drive_file_id or link_url must be provided.

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