Retrieves a student's complete record, including their default dismissal plan for each weekday. Optionally returns the raw API response for unmodified data.
One student in full, including the default dismissal plan for each weekday. Pass raw: true for the untouched API record.
| Name | Required | Description | Default |
|---|---|---|---|
| raw | No | Return the unprojected API record instead of the summary | |
| student_id | Yes | Student id, from pup_list_students |
Changes observed during successful MCP inspections.
v1.0.0Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"v0.1.2Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes safety, so the description's main contribution is the projection behavior: by default a summary is returned and raw:true returns the untouched API record. This goes beyond the annotation and helps an agent understand output variation, though error and edge-case behavior are not described.
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 sentences with no filler; the main deliverable is stated first and the optional raw behavior is given second. The structure is easy to scan and each 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?
For a two-parameter read-only tool, the description covers the core return content and the summary-vs-raw distinction. No output schema exists, so a little more detail about the full shape could help, but the essentials for selecting and calling the tool are present.
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 100%, so the schema already documents both parameters. The description's 'Pass raw: true for the untouched API record' restates the raw parameter's meaning with slightly different wording but adds no substantive information beyond the property description.
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 identifies the resource ('one student') and a distinguishing feature: the full record includes the default dismissal plan for each weekday. It clearly differentiates this from list-style siblings such as pup_list_students, though it does not use an explicit verb like 'returns'.
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 the tool is for retrieving a single complete student record rather than a list or a plan-only resource, but it does not explicitly state when to choose it over siblings like pup_get_default_plans or pup_list_students. There are no exclusion criteria or alternative routes mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.