Retrieve gradebooks for 1 to 10 selected courses by ID, with per-source caveats and separate sections. It does not mix sections or compute a general average.
Consulta libros de notas propios de 1 a 10 cursos elegidos por ID, con avisos por fuente. No mezcla secciones ni calcula promedio general.
| Name | Required | Description | Default |
|---|---|---|---|
| courseIds | Yes |
Changes observed during successful MCP inspections.
v0.5.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: warnings are provided per source, sections are not merged, and no overall average is computed.
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 sentences with no wasted words. The main action and scope are front-loaded, and the exclusion clause is compact and useful.
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 rich annotations and the absence of an output schema, the description is largely complete for selecting and invoking the tool. It covers scope and key behavioral exclusions, though the phrase 'avisos por fuente' remains somewhat vague about what warnings will be returned.
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 the single courseIds parameter. It communicates that 1–10 courses are selected by ID, which is useful, but it does not explain the ID format (e.g., the ^_\d+_\d+$ pattern) or give additional syntax guidance.
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 (Consulta) and resource (libros de notas) with a clear multi-course scope of 1–10 courses by ID. It distinguishes the tool from single-course gradebook tools by its multi-course range and from aggregate tools by explicitly saying it does not mix sections or calculate an overall average, though it does not name an alternative 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?
The description implies usage for retrieving gradebooks from multiple courses chosen by ID and notes exclusions such as not mixing sections or calculating an overall average. However, it does not explicitly state when to choose this tool over siblings like get_course_gradebook, export_multi_course_grades, or get_multi_course_overview.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.