wilma_list_printoutsLists available school PDF documents, such as report cards and absence reports, for one child or all children on the account.
PDF documents the school offers (Tulosteet), such as report cards or absence reports. Fetch one with wilma_get_printout.
| Name | Required | Description | Default |
|---|---|---|---|
| student | No | Child's name or student number. Omit to include every child on the account. |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is fully covered. The description adds only the domain fact that these are school-issued PDFs; it says nothing about ordering, pagination, or whether a student filter narrows the result set. With annotations carrying the burden, a 3 is appropriate.
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, zero filler, with the resource definition front-loaded and the sibling handoff placed last. Nothing to trim.
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?
Adequate for a simple read-only list with no output schema: the agent knows what it gets (PDF printouts) and where to go next. The one gap is that nothing describes the shape of a list entry or which identifier is needed to call wilma_get_printout, which the absence of an output schema leaves undocumented.
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?
There is a single optional parameter with 100% schema description coverage ('Child's name or student number. Omit to include every child'). The description adds no format hints or naming conventions beyond that, so the schema does all the work and baseline 3 applies.
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 the concrete resource (PDF documents offered by the school, Tulosteet) with two illustrative examples, report cards and absence reports. The closing sentence 'Fetch one with wilma_get_printout' makes it unambiguous that this tool lists while the sibling retrieves, so an agent can distinguish the pair without opening either 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?
Explicitly routes the follow-up action to wilma_get_printout, which is the natural alternative an agent would confuse this with. It does not state when to prefer this over other list tools (messages, news), though the resource is distinct enough that the omission is minor.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.