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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive, so safety is covered. The description adds concrete behavior beyond annotations: it returns aggregated per-course stats (file count, total size, extension groups), includes content_id per file, auto-selects the active term when term_id is omitted, and requires/uses mcp_session_id for LMS login context. It also exposes an implicit behavior of presenting a summary table to the user. Minor gap: no mention of what happens if the user has no enrolled courses or no files, but the description does considerably more than the annotations require.

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 information-dense and front-loaded with the core purpose and value proposition, then flows into usage and follow-up instructions. It is longer than minimal, but every sentence earns its place by explaining the aggregated content, the user interaction step, and the follow-up call. A minor deduction for density: multiple clauses per sentence may require re-reading, but the structure is logical and not padded.

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 list tool with 2 optional parameters and no output schema, the description is remarkably complete: it states what is returned (file count, total size, extension groups, content_id), how to surface it to the user, which sibling to use next and why get_my_lms_materials is unnecessary, and the default term selection behavior. There is no output schema, so the description must specify return contents—and it does. The only minor omission is empty-state behavior, but this does not meaningfully hurt callability.

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%, so the schema already documents both parameters (term_id and mcp_session_id) with meaningful descriptions. The tool description adds context for term_id's default behavior and states mcp_session_id is needed for LMS login, but doesn't add new parameter syntax or format details. Baseline 3 is appropriate because the schema carries the burden and the description only slightly supplements it.

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+resource (retrieves the authenticated user's LMS courses) and specifies a key differentiator: it bundles downloadable materials per course. It clearly distinguishes from sibling get_my_lms_materials by explaining that this one returns content_id per file and removes the need for a second call.

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?

Explicitly says to call this right after login, describes the user-facing table format, instructs how to ask the user which course to receive, and directs the follow-up call to prepare_lms_material_export using the content_ids from this response. Also explains term_id behavior when omitted and notes that mcp_session_id is required (LMS login). This is strong usage guidance with invocation ordering and next-step routing.

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