List Student New Quiz Accommodations

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

Annotations already declare readOnlyHint=true. The description adds meaningful behavioral detail: return value semantics for the no-accommodation case (returns false rather than erroring), the course-level vs per-quiz scope, and the fact that it is not per-quiz. It stops short of detailing exact response fields or error behavior beyond the no-accommodation case, but with a read-only hint and sibling guidance this is quite transparent.

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?

Four tight sentences. First sentence states purpose, second gives the key edge-case behavior, third scopes the tool away from per-quiz, fourth routes to the sibling for classic quizzes. Every sentence adds signal; front-loaded with the core verb and resource.

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 read-only lookup tool with two well-documented params, the description covers the key behavioral domain: returns a boolean-ish 'has accommodation' signal, treats 404 as no accommodation, clarifies the course-level vs per-quiz scope, and tells when to call the classic-quiz sibling. It doesn't explicitly say what fields are included when an accommodation IS set (e.g., multiplier value, attempt count), but the has_accommodation:false shape is at least implied.

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 baseline is 3. The description clarifies that user_id refers to a student and course_id to a course, but does not add new meaning beyond the schema's 'Canvas course ID' and 'student' descriptions. Neither description explains ID formats or lookup prerequisites beyond the pseudonym hint in the usage section.

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 clearly states the tool's specific purpose: listing the course-level New Quizzes accommodation for a specific student. It explicitly distinguishes itself from the per-quiz model and names the sibling tool (set_student_new_quiz_accommodation) in context, so an agent can identify exactly what this tool does.

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?

Provides explicit guidance: when it is a read operation, when to use it (auditing before/after setting accommodations), and an explicit alternative for Classic Quizzes (list_student_quiz_accommodations). It also mentions the pseudonym resolution prerequisite for anonymous courses, which is a clear conditional usage rule.

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