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

Beyond the read-only, idempotent, and non-destructive annotations, it discloses important role-dependent visibility: students receive their own Submission and released Feedback, whereas lecturers receive every Submission and information about who has not handed in. It does not address not-found or authorization behavior, but those are secondary gaps for this simple read.

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?

Two compact sentences front-load the operation and then present the student/lecturer distinction. Every clause contributes payload or visibility information, with no filler or repetition of the annotations.

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 two-parameter read, the documented IDs, consistent safety annotations, and explanation of returned content and role visibility are enough to select and invoke the tool correctly. The absence of an output schema leaves the exact response shape unspecified, but the description supplies the key semantic contents without needing a field-by-field contract.

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 both required IDs already have meanings and discovery sources in the schema, so the baseline score applies. The description adds no further parameter syntax or relationship constraints, but none are necessary to understand the basic invocation.

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?

“Reads one Task” supplies a clear verb, resource, and singular scope, while the listed description, Files, deadline, Submissions, and Feedback clarify what the read provides. It does not explicitly contrast itself with list_tasks or another sibling, so sibling differentiation remains implicit.

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 wording implies use when the caller already has the course and task IDs and needs a detailed, role-appropriate task view. It gives no explicit when-not guidance or alternative for task discovery, although the schema's references to list_tasks and list_courses partly fill that workflow gap.

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