Get Quiz

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

Annotations already declare readOnlyHint:true and openWorldHint:true, so the agent knows it's a safe read operation. The description adds only that it gets details for a single quiz by ID, which is minimal but consistent. Given the strong annotation coverage, the description needn't add much; it could have added context about response shape, but the annotations cover the safety profile.

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 a single, perfectly formed sentence: 'Get details for a single quiz by ID.' Every word earns its place and the main purpose is front-loaded with the verb 'Get'. The description follows the pattern of similar sibling tools, maintaining consistency.

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 simple GET-by-ID tool with readOnlyHint and openWorldHint annotations, complete schema coverage, and no output schema, the description is adequately scoped. It could have mentioned that there are no side effects or that it returns a 404 if not found, but given the strong annotation coverage and standard Canvas REST pattern, this is sufficient for an agent familiar with the Canvas API.

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% with both parameters (course_id and quiz_id) described. The schema already provides accurate descriptions ('The Canvas quiz ID', 'The Canvas course ID'). The description adds no additional semantic meaning beyond the schema, but that's acceptable given full coverage. It correctly implies both IDs are needed as path parameters.

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 uses a clear verb ('Get') plus resource ('quiz') and identifies basic scope ('single quiz by ID'). It is distinguishable from the more specific 'get_new_quiz_item' and the list endpoint 'list_quizzes' among siblings. However, it doesn't explicitly contrast with the similarly named 'get_new_quiz_item' which could confuse agents given the sibling list contains both.

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 context that this retrieves a single quiz by ID is clear, implying use when you need details for one quiz. However, there is no explicit 'when to use' vs alternatives like 'list_quizzes', 'get_new_quiz_item', or quiz submission endpoints. The usage guidance is implied rather than explicit.

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