edubase_get_quiz

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

The annotations declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the description's 'Get/check' aligns with these. However, the description adds minimal behavioral context beyond the annotations. It doesn't explain what 'check' means (e.g., validates existence, returns status), nor does it mention that the quiz is an entity containing questions and used in exams, which is a minor detail. The description repeats the resource type but doesn't disclose any non-obvious behavior such as response format, error conditions, or permissions.

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 short but awkwardly structured: 'Get/check Quiz set. Containing questions and powering Exams.' The second sentence is a fragment and not clearly connected; it reads as two separate clauses that don't flow. It is concise in word count but not well-formatted, and the lack of a clear subject-verb-object structure hurts clarity. It could be improved by rewriting as a single sentence.

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 there is an output schema (though not shown in the prompt, it is indicated as present), the description doesn't need to detail return values. However, for a simple get tool with a single parameter, the description is adequate to know what it does (retrieve quiz data). It doesn't cover edge cases like what happens if the quiz ID is invalid, but given the output schema and annotations that provide safety (read-only), it is minimally complete. The lack of usage guidance is a gap but not critical for a read-only retrieval.

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?

The schema coverage is 100%, with the parameter 'quiz' described as 'Quiz identification string' in the schema. The description does not add any additional meaning beyond that; it says the quiz set contains questions and powers exams, but that doesn't elaborate on the parameter itself. Since the schema adequately documents the parameter, baseline of 3 is appropriate; no extra semantics are provided, but not needed.

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 'Get/check Quiz set. Containing questions and powering Exams.' which identifies the resource (Quiz set) and action (Get/check), but the phrasing is awkward and lacks clarity. It doesn't clearly distinguish from siblings like get_quiz_settings or get_quiz_questions; the mention of 'powering Exams' adds ambiguity about the tool's scope. Still, it's more than a tautology because it indicates the tool retrieves quiz data.

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 explicit guidance on when to use this tool versus alternatives. It does not mention any conditions for choosing this over other get_* quiz functions (e.g., get_quiz_settings, get_quiz_questions). The description only says what it returns, not when to use it. The only implied context is that it retrieves quiz information, but no exclusions or alternatives are provided.

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