Skip to main content
Glama
OrDinaD
by OrDinaD

iis_get_grade_book

Read-only

Retrieve a BSUIR student's current-semester grade book, including subjects and latest class marks, to check academic progress.

Instructions

Получить текущий журнал отметок студента за текущий семестр.

Возвращает: список дисциплин и последние выставленные отметки на занятиях.

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered by structured data. The description adds the return content (list of disciplines plus latest marks), which is genuinely useful given there is no output schema, but it discloses nothing about scope limits, semester boundaries, or empty-result behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, zero waste: the first gives the action and scope, the second gives the return shape. Front-loaded and appropriately sized for a parameterless read tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description's return summary (disciplines and latest marks) fills the most important gap, and annotations cover safety. The remaining weakness is the unresolved ambiguity against near-identical siblings, but for a simple no-argument read tool this is close to complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is no parameter semantics burden; the baseline of 4 applies. The description correctly signals that no identifier is expected by anchoring everything to the implicit current student and current semester.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Получить) and resource (текущий журнал отметок студента) with a scope qualifier (за текущий семестр), so the agent knows exactly what is fetched. However it does not distinguish itself from close siblings like iis_get_markbook or iis_get_mark_sheets, which sound like the same artifact, leaving overlap unresolved.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No indication of when to use this tool versus the several look-alike siblings (iis_get_markbook, iis_get_mark_sheets, iis_get_omissions). There is also no mention of prerequisites such as authentication or which student's book is returned (no parameters implies the caller's own record), which the agent must infer.

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