Missing work

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

Beyond the readOnlyHint annotation it discloses real operational traits: drafts that were never handed in are included, handed-in/graded work is excluded, up to 25 assignments per course are checked, and results are capped at 50 items. Those inclusion/exclusion rules and truncation caps are exactly the kind of behavior an agent cannot get from annotations or schema.

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?

Front-loaded with the intent question, then scope, exclusions, and limits in a logical order; every sentence carries information. The closing 'Ask: ...' line partially restates the opening question, a small redundancy.

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 filter tool with no output schema, it covers inclusion rules, exclusions, per-course scan depth, result cap, and the fields returned (course name, due date). What is missing is what happens when the 50-item cap truncates — ordering or a truncation indicator — which matters for an agent summarizing results.

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's course_ids property lacks a top-level description (0% coverage), and the description compensates by explaining that the array limits the list and that omitting it covers all current courses. It does not repeat the schema's note that IDs come from get_my_courses, but the key default semantics are supplied.

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?

States a specific verb and resource ('Lists the assignments in your courses that you have not handed in yet') and adds an intent framing ('what do I still owe?') an agent can match a user request against. The scope definition (not-submitted, includes drafts) implicitly separates it from get_overdue and get_upcoming_due_dates, but no sibling is named explicitly.

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?

Gives a clear trigger ('Ask: "What work am I still missing?"') plus the default behavior of omitting course_ids to cover all current courses, which is actionable selection context. It does not state when to prefer get_overdue, get_todo, or get_assignments instead, so the agent must infer the boundary.

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