get_my_official_exam_schedule

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

Annotations already declare readOnlyHint=true, so the description need not restate safety. It adds a little context about the cross-referencing operation, but does not disclose details like whether it requires prior authentication or what happens if degree_keys is omitted. Consistent with annotations, no 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?

The description is a single, efficient sentence with no fluff. It is front-loaded with the action, and every word contributes meaning. However, the word 'Cruza' is slightly idiomatic and could be more explicit, but overall it is concise.

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 read-only tool with two parameters (one optional), the description is thin. It does not explain degree_keys, the expected output, or any dependencies (e.g., being logged in, having Moodle courses). Given the low schema coverage and no output schema, an agent lacks key information 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 0%, so the description carries the burden of parameter explanation. It mentions the year indirectly ('año indicado') but does not explain degree_keys at all. An agent cannot infer the purpose or format of degree_keys from the description, leaving a significant 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 clearly states the tool cross-references the user's Moodle course codes with official USC calendars for a given year. It goes beyond the tool name, specifying the data sources and the personalized nature ('mis cursos Moodle'), which helps distinguish it from siblings like get_official_exam_dates or search_exam_dates.

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 usage for retrieving one's own exam schedule based on Moodle enrollment, but it does not explicitly state when to prefer this over alternatives (e.g., get_official_exam_dates for subject-specific queries). It provides some context but no exclusion criteria or guidance on degree_keys usage.

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