Update a Google Classroom course's name, section, description, room, or state (ACTIVE or ARCHIVED) to keep course details accurate and current.
Update course fields (name, section, description, room, state). State can be ACTIVE or ARCHIVED.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| room | No | ||
| state | No | ||
| section | No | ||
| courseId | Yes | ||
| description | No |
Changes observed during successful MCP inspections.
v3.0.0-beta.1Does 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.