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

No annotations are provided, so the description carries the full burden. It discloses what the tool returns and that it accepts either a full URL or an id/course_id pair. It does not explicitly mention read-only behavior, permissions, error handling, or rate limits, though the 'get' verb implies a safe read operation.

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 sentence delivers the core purpose and expected output; the second gives concrete input format guidance. Every sentence earns its place.

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 covers the required parameter and the return content well, but omits the account parameter's role and any operational details such as error behavior or prerequisites. For a simple read tool with one required parameter, this is near adequate but still leaves a notable 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 0%, so the description must compensate. It explains the required parameter coursework_id_or_url (full URL or id) and how course_id relates to it, but it says nothing about the account parameter, leaving its purpose and usage 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 clearly states a specific operation: retrieving details of a single task or question, and lists the returned fields (instructions, deadline, points, materials, submission status). This distinguishes it from siblings like list_pending_assignments or get_course_contents, which have broader or different scopes.

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 you already have a coursework URL or id plus course_id. However, it does not explicitly state when not to use it or compare it with alternatives such as list_pending_assignments, leaving some routing to inference.

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?

With no annotations, the description carries the full burden. It discloses that the tool returns current-user delivery status and grades and that it accepts either a course ID or URL, but it does not mention read-only behavior, required permissions, pagination, or other 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?

Two short sentences deliver the resource scope, the contents returned, and the accepted input format with no filler. The most important information is 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 simple retrieval tool with two parameters and no output schema, the description gives a reasonable account of return contents and input format. However, it omits any explanation of the account parameter and any caveats about behavior, so it is adequate but not 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 0%, so the description must compensate. It clarifies that course_id accepts either an ID or a course URL, but it never explains the optional account parameter, leaving part of the input semantics undocumented.

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 that the tool returns a course's classwork grouped by topic, including assignments with submission status and grade, questions, and materials. This is specific and distinguishes it from siblings like get_assignment or list_announcements, though it does not explicitly name the contrast.

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 of when to call this tool is implied by describing the aggregate course content it returns, but there is no explicit guidance on choosing it over list_pending_assignments, get_assignment, or list_announcements, nor any 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?

No annotations are provided, so the description carries the full burden. It discloses that the tool verifies connectivity and returns authenticated user data, and that it can operate per account. However, it does not mention side effects, authentication requirements, error behavior, or what happens when no account is available.

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 communicates the core purpose and the parameter behavior without redundancy. Every part of the sentence contributes useful 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?

Given the low parameter count and simple input schema, the description is minimally viable. It tells the agent what the tool does and how the optional account affects behavior. However, with no output schema and no annotations, the lack of detail about the returned user object and connection-check semantics leaves some 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 0%, so the description must clarify the account parameter. The phrase 'de cada cuenta (o de la indicada)' indicates that the optional account parameter selects a specific account, with the default covering all accounts. This adds meaningful semantic value, though it stops short of explaining accepted formats or values.

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: verify the connection and return the authenticated user for each account (or a specified one). The verb-resource pair is specific and distinct from the sibling tools, though it does not explicitly contrast with any sibling.

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 about when to use this tool versus alternatives such as list_accounts or get_course_contents. The tool's use case can be inferred, but the description does not state explicit conditions or 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?

There are no annotations, so the description carries the behavioral load. 'Sin conexión a la API' usefully discloses that this is a local/no-API operation, implying a safe, read-only listing. It does not go into return format or empty-result behavior, but for a simple account list this is adequate.

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 short fragments with no filler. The core identity of the tool is front-loaded, and the behavioral note about no API connection adds value without bloat.

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 zero-parameter local listing tool, this is nearly complete: it specifies the returned fields and the key behavior (no API call). It does not mention return format or the possibility of an empty list, but those are minor for this simple use case.

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 tool has zero parameters, so the baseline of 4 applies. There are no parameter details needed, and the description correctly focuses on the output instead.

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 resource (configured Google accounts) and the expected output fields (alias and email). It lacks an explicit verb, but combined with the tool name 'list_accounts' the purpose is unambiguous and easily distinguished from the sibling course/assignment tools.

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 given about when to use this tool versus alternatives or when not to use it. The resource is distinct enough from the siblings, but the description does not state any selection conditions or prerequisites.

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?

With no annotations, the description must carry full behavioral burden. It mentions sorting order but omits critical behaviors: pagination (limit parameter), default limits, whether announcements include attachments or metadata, and whether any authentication or permissions are needed. The agent is left without details on what happens with the limit or how results are returned.

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 concise sentence that captures the core purpose and ordering. It is appropriately front-loaded with the main action. Omitting details is a trade-off but not verbose, so it earns a 4 for clarity relative to 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?

Given three parameters, no annotations, and no output schema, the description is insufficient. It does not clarify the role of limit and account, nor does it specify the output format (e.g., fields of each announcement). The sorting detail is helpful but not enough for full context.

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 for all parameters. It does not explain course_id, limit, or account at all, leaving agents to infer from parameter names. Since there is no parameter documentation in the schema, the lack of explanation is a significant gap, though parameter names are somewhat self-explanatory.

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?

Description clearly indicates it lists announcements for a course, sorted by most recent to oldest, which defines the core function. However, it does not explicitly distinguish itself from sibling tools like list_courses or list_pending_assignments, but the resource (announcements) is distinct enough.

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 on when to use this tool versus alternatives. It does not mention prerequisites (e.g., requiring a course from list_courses) or when to prefer other tools. Usage is implied for listing announcements but with no exclusions or context.

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?

There are no annotations, so the description carries the behavioral burden. It does disclose the multi-account traversal behavior and the student-enrollment scope. However, it does not mention pagination, output format, permissions, or whether archived courses are handled beyond the include_archived parameter.

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 only two short Spanish sentences with no filler or redundant phrases. It is front-loaded with the main purpose and then adds the key account-related nuance.

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 two optional parameters and no annotations or output schema, the description covers the core behavior and account aggregation, but it leaves include_archived and the expected return shape unstated. It is adequate but has clear 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 0%, so the description must compensate. It meaningfully explains the account parameter (when omitted, it iterates all configured accounts), but it provides no additional semantics for include_archived at all, leaving that parameter to be understood only from its name and schema default.

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 tool's resource and scope: Classroom courses in which the user is enrolled as a student. It also distinguishes the tool from siblings such as get_course_contents or get_assignment by emphasizing an aggregate course list rather than a single item.

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 about when to use it (courses where the user is a student) and the behavior when account is not provided (recorre todas las cuentas configuradas). It does not explicitly name alternatives or exclusions, but the context is enough for basic tool selection.

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?

With no annotations present, the description carries the burden of behavioral disclosure. It reveals the status filter, grouping, ordering by deadline, and inclusion of overdue indicator. It does not mention pagination, rate limits, or authorization, but for a read-only list tool this is reasonable.

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 compact sentences deliver all essential information—what is listed, statuses included, grouping, sorting, and default scope—without redundantly repeating the 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?

The description covers statuses, grouping, sorting, default behavior, and overdue flag. Since there is no output schema, an agent gets enough to call the tool correctly. Minor missing details (sort direction, pagination, return format) prevent a perfect score.

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 has no descriptions and only shows account/course_id as nullable strings. The description adds crucial semantics: omitting them means scanning all accounts/courses(), which is more than the bare schema provides. It stops short of explaining expected ID formats.

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'), names the exact resource ('pending assignments'), enumerates the included statuses (NEW, CREATED, RECLAIMED_BY_STUDENT), and specifies grouping and sorting. This clearly distinguishes it from siblings like list_courses or get_assignment.

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 explains the behavior when parameters are omitted ('Sin account ni course_id revisa todos los cursos activos de todas las cuentas'), giving a clear decision rule. It does not explicitly contrast with sibling tools, but the context makes the appropriate use obvious.

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?

With no annotations, the description carries the full burden of behavioral disclosure. It reveals the action is a mutating withdrawal but does not state potential side effects, irreversibility, permission requirements, or the specific Google restriction it references. The mention of a restriction without details is insufficient for a mutation 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?

The description is brief and to the point, with two sentences that convey the purpose and a usage condition without redundancy. It is front-loaded with the core action and efficiently structured.

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 no annotations, no output schema, and 0% parameter coverage, the description is inadequate. It omits parameter explanations, the nature of the Google restriction, and any operational details, leaving the agent with significant gaps that could lead to incorrect invocation.

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% and the description provides no information about any of the three parameters, including the required coursework_id_or_url. The description does not clarify how account, course_id, or coursework_id_or_url should be used or their meaning beyond what the schema's names imply.

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 (retira/resolves a submitted submission) and its purpose (to allow modification), using a specific verb and resource. It also equates it with 'Anular entrega', making the function unambiguous. Although it references submit_assignment, it still provides a clear purpose distinct from that sibling.

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 explicitly instructs to use only if the user asks ('Úsala solo si el usuario lo pide'), giving a clear condition. However, it relies on a stated restriction 'Misma restricción de Google que submit_assignment' without specifying what that restriction is, leaving the agent to infer or lack critical context about when the tool is valid.

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?

With no annotations, the description carries the full burden. It discloses the conditional turn_in behavior and the 403 failure mode, which is valuable. However, it does not state whether submission is reversible, whether existing attachments are overwritten, or what other side effects occur beyond attaching/submitting.

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 front-loaded with the core function, followed by a workflow note and a critical warning. Every sentence adds information and there is no filler, though it is slightly long due to the warning and workflow 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 mutation tool with no output schema and no annotations, it explains the key parameters and a likely error, but omits the meaning of course_id and account, and does not describe what a successful response looks like. It is adequate but leaves meaningful 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 0%, so the description must compensate. It explains drive_ids and links as Drive files/URLs and links, and clarifies turn_in's conditional behavior, but it leaves course_id and account undefined and does not clarify the required coursework_id_or_url beyond its name. The compensation is incomplete for a 6-parameter tool.

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: attaching Drive files (IDs/URLs) and/or links to an assignment, with conditional submission via turn_in=True. This clearly distinguishes it from read-only siblings like get_assignment and from the opposite action reclaim_submission.

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 explicitly says to use the tool only when the user asks, and it gives an alternative workflow for local files (upload to Drive via the Google Drive MCP server, then pass the ID). It also warns about a case where the tool should not be used (403 ProjectPermissionDenied) and directs the user to classroom.google.com instead.

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