See a student AI consent
get_student_ai_consentWhether the student agreed to have assessments analysed by AI, and when.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| studentId | Yes | The student_id from list_students. |
get_student_ai_consentWhether the student agreed to have assessments analysed by AI, and when.
| Name | Required | Description | Default |
|---|---|---|---|
| studentId | Yes | The student_id from list_students. |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. In the absence of an output schema, the description does add value by disclosing the return content (consent flag + timestamp), but it says nothing about the behavior when no consent record exists — null, default, or error — which is the main behavioral question for a lookup like this.
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?
An eleven-word fragment with zero waste, and the key concept (AI consent for assessments) is front-loaded. It is terse to the point of being a sentence fragment, but nothing is padded.
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 one-parameter read with no output schema, the description covers what the tool returns, which is the essential piece. It is still thin on edge cases (missing consent record, student outside the caller's scope) that an agent would want before relying on the result.
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 coverage is 100% and the single studentId parameter is documented in the schema as coming from list_students. The description adds nothing further about the parameter, so the baseline of 3 is appropriate.
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 names the exact data returned — whether the student consented to AI analysis of assessments plus the timestamp — which is specific enough to distinguish it from siblings like get_student_health or get_student_summary. It is phrased as a noun clause rather than a verb+resource, so the 'retrieve' action is only implied by the name get_student_ai_consent.
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?
There is no guidance on when to call this versus alternatives (e.g., get_student or get_student_summary), and no stated prerequisites such as needing the student to exist in the caller's team. The agent must infer usage purely from the topic.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.