google-classroom-mcp

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

Annotations already declare readOnlyHint=false and openWorldHint=true, so the mutation/non-determinism profile is covered. The description adds nothing beyond that: it doesn't say that state defaults to DRAFT, that dueTime is converted to UTC, that scheduledTime defers publication, or that creation is irreversible. With annotations carrying the safety signal, this is a thin addition rather than a contradiction.

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

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

A single front-loaded sentence with no filler; the creation verb leads and the optional payload follows. It is efficient but too short to serve as a complete definition for an eleven-parameter mutation tool.

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

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

Not applicable — no output schema exists, so nothing about return values needs explaining. Wait: for a mutation tool with low schema coverage the description should do more; it under-delivers on state, scheduling, and required parameters. Score reflects that gap.

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

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

Schema description coverage is only 27%, so the description must compensate, but it mentions just four of eleven parameters (attachments, due date, topic, and implicitly workType). It omits the required courseId and title, plus state, maxPoints, scheduledTime, and description, and gives no syntax or interaction rules (e.g. dueTime defaults to 23:59).

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

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

The description states a specific verb and resource ('Create an assignment or question') and enumerates distinguishing content (attachments, due date, topic), which separates it from the get/list/patch siblings. It does not explicitly name a sibling, but the create-vs-read/update split is unambiguous from the name and verb.

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

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

It says nothing about when to use this versus classroom_create_material or classroom_create_topic, nor about prerequisites such as teacher permissions or course state. The only guidance is the adjective 'optional', which merely restates the schema's required list.

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

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

Annotations already declare readOnlyHint=false and openWorldHint=true, so the write/network profile is covered. The description adds nothing beyond that: it doesn't say materials are posted into a course visible to students, doesn't mention the PUBLISHED vs DRAFT visibility consequence, and doesn't note permission requirements or the 20-attachment cap.

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

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

A single efficient sentence with the core action front-loaded and no padding. It is only slightly short of ideal because brevity here comes at the cost of necessary detail elsewhere.

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

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

For a 7-parameter mutation tool with 14% schema coverage and no output schema, the description is thin. It leaves unclear how state, scheduledTime, and attachment shareMode interact, and gives no picture of what the call returns or what permissions are needed.

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

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

Schema description coverage is only 14%, so the description must compensate, and it barely does — it names attachments and topic but says nothing about state, scheduledTime, description, or the shareMode behavior for driveFile attachments. Two of seven parameters get implicit mention at best.

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

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

Specific verb plus resource: 'Create a study material post', with a note that attachments and topic are optional. That is clear enough to distinguish it from classroom_create_assignment and classroom_create_topic, though it never names those siblings or states the distinction explicitly.

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

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

No when-to-use guidance, no prerequisites, and no alternatives named. An agent choosing between creating a material, an assignment, or an announcement gets no help from the text beyond the noun 'material'.

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

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

Annotations 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

Annotations only declare readOnlyHint=false and openWorldHint=true, leaving destruction/reversibility and permission needs undisclosed. The mention of updateMask conveys partial-update semantics (only masked fields change), but the description omits the critical gotcha that supplied fields absent from the mask are silently ignored, and says nothing about auth or 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.

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

A single front-loaded sentence with zero filler. It is efficient, though the brevity tips into under-specification rather than disciplined concision.

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

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

This is an 11-parameter mutation tool with no output schema, sparse annotations, and 45% schema coverage; the description should carry far more. Nothing explains the updateMask/payload contract, required-field behavior, or what a successful response looks like, leaving the agent to infer the core usage pattern.

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

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

Schema description coverage is only 45% across 11 parameters, so the description must compensate and it does not. It references updateMask but never explains its interaction with the payload fields or names any of the undocumented parameters (state, title, topicId, courseId, maxPoints, description).

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

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

States a specific verb and resource ('Update specific fields of an existing assignment') and names the mechanism (updateMask), which distinguishes it from classroom_get_assignment, classroom_list_assignments, and classroom_create_assignment. It stops short of explicit sibling differentiation against the other patch_* tools in the family.

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

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

There is no statement of when to use this versus a full replacement, versus classroom_create_assignment, or versus the topic/material patch siblings. The only implied guidance is the word 'specific fields,' which hints at partial update without stating prerequisites or when-not conditions.

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

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

Annotations 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.