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

Beyond the annotations, the description discloses meaningful behavioral details: fresh uses a clean browser without saved cookies, and a failed fresh login preserves the saved session. This adds state-management nuance that the annotations alone do not convey.

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?

Three sentences, each earning its place: purpose, required follow-up, and parameter-specific behavior. No filler or redundant restatement of the tool name.

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?

The description covers the overall login flow, the follow-up polling step, and the edge-case fresh behavior. It does not state what begin_login itself returns, but the instruction to poll get_login_status makes the protocol clear enough for an agent to act.

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?

With 0% schema description coverage, the description compensates by explaining the sole parameter: fresh:true is for recovering from expired or unsupported flows. It also implies the default normal behavior through 'Open normal TU Delft sign-in'. Could be slightly clearer about default false, but it is largely sufficient.

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 states a specific action ('Open normal TU Delft sign-in starting from Brightspace') and clearly identifies the resource and portal. It also distinguishes this from sibling login flows like begin_mytu_login and begin_mail_login by emphasizing 'normal TU Delft sign-in' and 'Brightspace'.

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 workflow is explicit: complete password/MFA, then poll get_login_status. It also gives a concrete when-to-use condition for fresh:true ('expired or unsupported sign-in flow'). It does not explicitly state when to use sibling login tools, but the 'normal TU Delft sign-in' framing provides clear enough context.

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

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

Beyond the annotations (readOnlyHint=false, openWorldHint=true, etc.), the description adds meaningful behavior: it specifies the scopes requested, notes that 'passwords and MFA stay in Microsoft's login window' (indicating an interactive flow), and flags possible consent approval. These details are not covered by the annotations and enrich the agent's understanding of the tool's side effects and user dependence.

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 compact, consisting of two sentences, and is front-loaded with the core action ('Start normal Microsoft sign-in') before providing scopes, caveats, and next-step guidance. Every sentence contributes value, with no redundant or filler content.

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?

The description provides essential context for using the tool: it instructs the agent to poll get_mail_login_status, explains consent approval, and clarifies that credentials remain in Microsoft's window. While it does not describe the immediate return value, for an initiation tool with zero parameters, the guidance on follow-up actions largely compensates for the lack of an output schema.

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 tool has zero parameters, and schema coverage is 100% (empty). With no parameters, the baseline is 4, and the description does not need to explain parameter meaning. The description's focus on the login flow and its outcomes is sufficient given the absence of 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 clearly states a specific action ('Start normal Microsoft sign-in') with a specific resource scope (mail via Microsoft Graph SDK) and details the exact permissions requested ('profile and Mail.ReadWrite' with 'no Mail.Send'). It is distinguishable from sibling login tools like begin_mytu_login and begin_recording_login, though it does not name an alternative 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?

The description gives a follow-up instruction ('Poll get_mail_login_status') and notes that 'University consent policy may require approval', implying the need for user interaction. However, it does not explicitly state when to use this tool versus other login methods, nor provide exclusions or alternatives. Usage context is implied rather than stated.

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

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

Annotations already indicate openWorldHint (external side effects) and non-readOnly, non-idempotent. The description adds valuable behavioral context: it mentions that the user must complete password/MFA in the browser (interactive step), and that the tool returns nothing itself—the agent must later poll get_mytu_login_status. It also provides the account-matching constraint, which is not in the annotations. This goes beyond the structured metadata.

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 two sentences with no filler. The first sentence front-loads the purpose and scope, the second provides the follow-up action and a key prerequisite. Every clause adds information; no redundancy with annotations or schema.

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 login-initiating tool with no parameters and no output schema, the description covers the essential flow: what to do (open sign-in, complete MFA), what to do next (poll status), and a constraint (match Brightspace). It might benefit from clarifying what 'normal' vs 'protected' means, but given the sibling tools and the mention of get_mytu_login_status, it is sufficiently complete for an agent to proceed correctly.

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 tool has zero parameters, so schema coverage is trivially 100%. The baseline for 0-param tools is 4, and the description doesn't need to elaborate on parameters. It correctly omits any parameter details, making this adequate.

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 opens the 'normal My TU Delft student sign-in' and specifies the purpose as obtaining 'official OSIRIS results.' It distinguishes itself from sibling begin_* tools by naming the specific system (My TU Delft) and the result type (OSIRIS), and by referencing a 'separate protected login' that must match Brightspace, leaving no ambiguity about 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?

It provides a clear sequence: open the sign-in, complete password/MFA in that browser, then poll get_mytu_login_status. It also adds a precondition (the protected login must match your verified Brightspace account). While it doesn't explicitly contrast with alternatives like begin_login or begin_mail_login, the specific reference to My TU Delft and OSIRIS makes the intended scenario clear, and the polling guidance is actionable.

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

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

The description adds meaningful behavioral detail beyond the annotations: it discloses that a browser is opened for sign-in, the user must complete password/MFA, and that the recording login is encrypted and bound to a verified Brightspace account. These traits are not derivable from annotations like openWorldHint=true and readOnlyHint=false.

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?

At roughly 50 words, the description is concise and front-loaded. The purpose sentence is the first sentence, followed by necessary flow instructions and a binding note. The final sentence adds a security nuance, though it is slightly loosely worded.

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?

The tool has no output schema and the description does not state what the call returns (e.g., an interaction token or a session identifier), which an agent may need. It does, however, provide enough high-level flow context—open chat, complete MFA, poll the status tool—to make the intended sequence understandable.

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 baseline is 3. The description adds 'exact recording topic' and 'your own course' constraints, which help the agent avoid arbitrary input, but it does not add meaning about parameter formats or how to obtain either identifier beyond what the schema already says ('Exact Brightspace numeric identifier from another tool').

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 states a specific verb and resource: 'Open normal Collegerama/TU Delft sign-in for an exact recording topic discovered in your own course.' It is clearly scoped to recording login as opposed to mail or MyTU, though it does not explicitly name a sibling alternative.

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 description gives a clear usage context ('for an exact recording topic discovered in your own course') and a follow-up step ('poll get_recording_login_status'), but it does not compare against sibling start-login tools such as begin_login, begin_mytu_login, or begin_mail_login. The when-not-to-use cases are left to inference.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the description is not burdened with baseline safety disclosure. It does add one useful behavioral detail—that this is a live check against the current-user API rather than a purely local read—but it doesn't say what happens on failure or what the response contains.

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?

A single front-loaded sentence with no filler; every word contributes to identifying the action, the object, and the live nature of the check.

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 parameterless read-only tool this is almost sufficient, but the absence of an output schema and the presence of several closely related auth-status siblings leave the agent without guidance on what the verification result looks like or when to prefer this tool over get_login_status, check_mytu_auth, or check_mail_auth.

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 tool has zero parameters, so per the calibration baseline it scores 4; there is no parameter information for the description to add beyond the empty schema.

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 specific verb ('Verify') and a clear resource ('the saved session against the live current-user API'), so an agent knows what action to take. It does not explicitly distinguish this from sibling auth-status tools like get_login_status, check_mytu_auth, or check_mail_auth, so it stops short of a 5.

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 the use case: when you need to confirm that a saved session is still valid by checking the live current-user API. However, it gives no exclusions and names no alternative tools, so an agent selecting among the many auth-check siblings has to infer when check_auth is the right choice.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds meaningful behavioral context beyond annotations by specifying what is verified and that it reports email access and process-local session lifetime, which is useful for an agent deciding how to interpret results.

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 brief, front-loaded sentences with no filler. The first states the core verification, and the second lists the additional reported outputs, making every sentence earn its place.

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?

Given the zero-parameter schema, rich annotations, and low complexity, the description is nearly complete: it names the verification target and the outputs. Since there is no output schema, a bit more detail on the exact return format would further reduce ambiguity, but the description is sufficient for correct invocation.

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 tool has zero parameters, so the schema is trivially 100% covered. The description correctly implies no inputs are required, satisfying the baseline for a no-parameter tool.

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 specific verb ('Verify') and names concrete resources: Microsoft identity, tenant, and Brightspace account. It also states clearly what the tool reports (email access and process-local session lifetime), which differentiates it from sibling auth tools like check_auth, check_mytu_auth, and get_mail_login_status.

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 description gives a clear context for use: when you need to confirm that the Microsoft identity, tenant, and Brightspace account are aligned and to learn about email access and session lifetime. It does not explicitly list alternative tools or exclusion conditions, but the intended use case is unambiguous.

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

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 that it is a verification step and ties it to a workflow, but it does not disclose what the tool actually returns or what happens on mismatch. No contradiction with annotations.

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?

A single sentence that conveys purpose and usage context without any fluff. It is appropriately terse and the key information is front-loaded.

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 zero-parameter tool with strong annotations, the description is sufficient for an agent to know when to call it, but it omits details about the expected result or failure behavior. Given the simplicity, this is a minor gap, but it could be more complete by stating that it returns a boolean or status.

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 tool has zero parameters, so there is nothing to explain. The description is not required to add parameter semantics, and the baseline of 4 for zero-parameter tools is appropriate.

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 names a specific verb ('Verify') and a specific resource ('My TU Delft login and its account match'), and adds a contextual constraint ('before reading official results'). It is distinguishable from siblings like check_mail_auth or check_auth, though it could be more explicit about what 'account match' means.

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 description implies when to use it ('before reading official results'), giving a clear context, but it does not explicitly state when not to use it or direct to alternatives. There is no comparison with other auth-check tools like get_login_status or begin_mytu_login.

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

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

Annotations already establish destructiveHint=true and idempotentHint=true, so the description has a lower bar to meet. It adds genuine value by specifying what is not destroyed ('Downloaded files and the login session remain'), which helps the agent understand the blast radius beyond the raw annotation flags. It does not detail return behavior, but that is less important for a parameterless action with no output 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?

Two short sentences carry the full meaning with zero filler. The primary action is front-loaded, and the important safety caveat is placed second without 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 parameterless, no-output-schema tool with strong annotations, the description provides everything needed for correct invocation: what resource is affected, what persists afterward, and by extension what the destructive scope is. There are no missing inputs or outputs to explain.

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 input schema is empty and parameterless, so there is no parameter ambiguity for the description to resolve. Per the baseline for zero-parameter tools, the description need not compensate for missing schema semantics, and it doesn't need to add more.

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 states a specific action ('Clear') on a specific resource ('the current account's searchable local text cache'), making the tool's purpose immediately unambiguous. It also adds a meaningful boundary — downloaded files and the login session remain — so the agent knows exactly what is and isn't affected.

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 intended use is implied clearly by the action and resource, and the note about what remains gives some decision context. However, the description does not explicitly say when to choose this tool over alternatives like get_index_status or start_course_sync, nor does it mention when clearing is appropriate.

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

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

Beyond the annotations, the description adds concrete behavioral detail: the action must occur exactly once, group submissions affect the selected group, and retrying should be preceded by a history check. It also states the side effect of uploading files, which is important since readOnlyHint is false.

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 focused sentences, each carrying useful information: the action, the precondition, the group side effect, and the retry heuristic. There is no filler and the core behavior is front-loaded.

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 confirmation tool with no return schema, the description covers the important parts: what it does, when it is allowed, what side effects to expect, and how to handle uncertainty. It does not describe a successful response, but that is not critical for this action.

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 0%, so the description must compensate. It implicitly maps 'unexpired preview' to the confirmation token and 'student explicitly approves' to the confirmed flag, but it never names the parameters or explains where the token comes from. The parameter names are self-explanatory, but provenance is left to inference.

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 names a specific verb and resource: 'upload the unchanged files in an unexpired preview exactly once.' It clearly scopes the tool to confirming file-based assignment submission and distinguishes it from sibling tools like confirm_text_submission by emphasizing files and an unexpired preview.

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 description gives an explicit precondition: 'Call only after the student explicitly approves that assignment, files, comments and any group effects.' It also provides a clear retry policy: inspect submission history if the outcome is uncertain. It does not name the sibling alternative tools explicitly, but the context alone is strong enough to avoid confusion.

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

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

Annotations already indicate a non-read-only, non-idempotent write operation. The description adds that it verifies API membership and that official registration is separate, which provides context beyond annotations. However, it does not disclose potential side effects or failure modes, so the added behavioral detail is moderate.

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 concise (three sentences) and front-loads the main action. The note about official registration is useful but could be seen as extra. No fluff; it earns its place.

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 confirmation tool with no output schema, the description covers the core action and usage condition, but lacks details on the token source (preview step), error handling, or what 'verify API membership' entails. Given the complexity of a two-step registration, more completeness would be expected.

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 0%, so the description must compensate. It does not explain the confirmationToken or the confirmed flag beyond implying 'explicitly approves' which maps to confirmed=true. The schema already constrains confirmed to true, so the description adds minimal value for parameters. The token's origin and format are not addressed.

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 states a specific verb ('Enrol') and resource ('exact course from an unexpired preview'), and clarifies the verification step. It clearly differentiates this from the official TU Delft registration and implies it is the confirm step after a preview. Siblings include prepare_course_registration, so the purpose is unambiguous.

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 instructs to call only after the student explicitly approves, which is a clear usage condition. It also distinguishes from official registration, but does not explicitly mention the prerequisite prepare_course_registration step. Still, the guidance is sufficient to know when it applies.

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

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

Annotations indicate readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true. The description goes beyond annotations by explaining that it rechecks membership and live group details, permits only one enrollment request, and verifies membership. It also warns to 'Never retry an uncertain result automatically', which is critical for agents. No contradiction; it adds valuable behavioral context.

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 sentences, concise and front-loaded. The first sentence sets purpose and prerequisites, the second adds safety and non-retry guidance. No unnecessary words.

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 tool with a simple action, the description covers prerequisites, behavior, and warning. It doesn't describe return values, but no output schema exists, so that is acceptable. It could mention what happens if the token is expired or already used, but the 'never retry' hint covers the main edge case. Overall sufficient.

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 0%, so the description must explain parameters. It mentions 'confirmationToken' implicitly through 'confirmation token', and 'confirmed' is implied by 'explicitly approves' and the const true. However, it does not explicitly state the meaning of each parameter or constraints like minLength. Baseline is 3 for no coverage, and description partially compensates.

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?

Description clearly identifies the action (joining a group), the target (exact group in an unexpired preview), and the required condition (after student approves). It distinguishes from prepare_group_enrollment, which likely prepares the enrollment; this confirms it. Purpose is specific and unambiguous.

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?

Describes when to use: after student explicitly approves, in an unexpired preview, with a confirmation token. It does not explicitly mention alternatives but the phrase 'rechecks own membership and live group details, permits one enrollment request, verifies membership' implies it is the final confirmation step after prepare_group_enrollment, which is clear enough.

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

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

The description adds substantial behavior beyond the annotations: it rechecks the native form/history, allows exactly one submission POST, verifies the new submission, and explicitly prohibits automatic retries. This meaningfully complements destructiveHint and non-idempotent flags without contradicting them.

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?

Three dense sentences, each earning its place: the first states the core action and preconditions, the second describes the verification and single-POST behavior, and the third adds a crucial retry caution. The most important information is front-loaded.

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?

The definition covers preconditions, side effects, one-shot semantics, verification, and retry policy. Since there is no output schema, a brief mention of the success/failure response shape is missing, but the description is still strong enough for an agent to invoke this dangerously non-idempotent tool safely.

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 0%, so the description carries the parameter-semantics burden. It maps confirmationToken to the unexpired preview and confirmed to the student's explicit approval, and it clarifies what the approval covers. It does not explicitly name the parameters, but it gives enough meaning for an agent to understand their roles.

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 names a specific verb and resource: submit/confirm an exact literal text submission. It adds precise conditions (unchanged text, unexpired preview, explicit student approval) that clearly separate it from file-based or assignment-submission confirmations and from prepare_text_submission.

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?

Clear preconditions are given: the text must be unchanged, the preview must be unexpired, and the student must explicitly approve the assignment, text, overwrite, and group effects. It also warns against retrying uncertain outcomes. It does not explicitly name an alternative tool, but the usage context is otherwise clear.

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

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

The annotations give readOnlyHint=false, idempotentHint=false, and the description adds meaningful operational detail: 'Body is literal plain text; replyAll defaults to false', 'Returns a verified draft and Outlook link', and the caution to 'Never sends'. The retry guidance aligns with the non-idempotent behavior. No contradictions with annotations.

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 three sentences with no filler. The first sentence fronts the core purpose and scoping, the second states two key parameters, and the third gives return value and retry strategy. Every sentence earns its place.

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 tool with no output schema, the description states the return (verified draft and Outlook link) and also gives a safety net for retry behavior. It clarifies the exact usage condition and that it never sends. The combination of parameters, behavior, and retry guidance provides what an agent needs to call it appropriately.

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 only 33% (only messageId has a description). The description compensates by adding literal plain text semantics for body and stating the replyAll default. The schema already clarifies that messageId is the exact ID from a mail tool, so the description fills the low-coverage gap for the other two 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 clearly specifies the action: 'Save an unsent reply to an exact message in your own Outlook mailbox.' It is distinguished from any sending tool by explicitly stating 'Never sends' and from read-only tools by the create/save verb. The phrase 'Use only for a reply the student requested' adds further scope differentiation.

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 description provides explicit when-to-use ('Use only for a reply the student requested') and a clear constraint ('Never sends'). It also gives retry guidance ('inspect Drafts before any retry'), but does not explicitly name an alternative tool. The absence of a direct sibling tool makes this sufficiently actionable.

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

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

Annotations already declare idempotentHint=true and destructiveHint=false, and the description does not contradict them. It adds that the download goes to a private local directory and returns path and extracted text, but it does not disclose side effects like overwrite behavior or storage limits. The description provides some additional context but not rich behavioral detail.

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 sentence that immediately states the core action and expected return values. There is no filler or repetition, and the key information is front-loaded.

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 tool with four parameters, no output schema, and moderate complexity, the description is insufficiently complete. It does not explain the parameters, describe the exact return format (beyond 'local path and extracted text'), or address error cases or prerequisites. An agent would need to inspect the schema and infer behavior, which is risky.

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 50% (courseId and topicId have descriptions), but the description does not mention any parameters. It does not compensate for the undocumented offset and maxChars parameters, which are non-obvious (offset likely for pagination, maxChars for truncation). The description adds no value beyond the schema's existing field descriptions.

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 states a specific verb ('Download'), a resource ('course topic'), and an outcome (return local path and extracted text). It clearly distinguishes from siblings like read_material by emphasizing the download-to-local-directory aspect, which is not implied by other tool names.

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 description gives clear context about what the tool does and where it downloads, but it does not explicitly mention when to use it versus alternatives like read_material or get_course_content. There are no exclusion criteria or alternative tool references, leaving selection to the agent's inference.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true. The description adds that the tool returns 'attachment metadata' (not the attachment content) and can be filtered by an ISO timestamp, which is behavior beyond the annotation hints. It is consistent with the read-only nature, so no contradiction.

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, well-structured sentence. It front-loads the main action and resource, then appends the optional filter without redundancy. Every word contributes to the meaning.

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?

Given there is no output schema, the description does not describe the response structure, pagination, or potential default behavior. It covers the core purpose and parameter, but for a read tool that returns a list of announcements with metadata, more detail on return format or limits would improve completeness.

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 only 50%: only courseId has a description. The description explains the 'since' parameter as an optional ISO timestamp for filtering, which the schema omits. This adds meaningful semantic for the undocumented parameter, partially compensating for the coverage gap.

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 specific verb ('Read') and names the exact resource ('course announcements and attachment metadata'), and adds an optional time filter. This clearly distinguishes it from sibling tools like read_announcement_attachment, which reads a specific attachment file.

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 description implies when to use it (to fetch announcements and their metadata), but it does not explicitly state when not to use it or mention alternatives such as read_announcement_attachment for downloading individual attachments. No exclusions or competing scenarios are provided.

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

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

Annotations already cover read-only, idempotent, open-world, and non-destructive behavior. The description adds useful context above that by specifying the exact payload (submission history and feedback), which is helpful but does not need to restate the annotation traits. No contradictions with annotations.

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?

A single, well-crafted sentence that front-loads the verb and resource. There is no unneeded explanation or fluff, and it fully communicates the key distinction of the tool.

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?

The description honestly covers what a caller should expect: specific assignment, submission history, and feedback. It excludes an exhaustive list of all response fields, but since there is no output schema, the description does most of the needed work for a simple read-only operation. It does not mention edge cases like missing feedback or multiple submissions, but that is borderline.

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%: both courseId and assignmentId already carry clear and identical descriptions in the schema. The tool description adds no further parameter detail, so the baseline of 3 applies.

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 imperative ('Read') with a specific resource ('one assignment') and distinguishes itself from list_assignments by explicitly including submission history and assessment feedback. It leaves no doubt about the tool's role among its siblings.

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 description states the purpose and scope, so an agent could infer when to call it (when a specific assignment's details are needed). It does not explicitly name alternative tools or provide when-not-to-use exclusions, which is the only gap.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds meaningful behavior details: it preserves series IDs, occurrence IDs, and source coverage, and states that fallback gaps are explicit. It also mentions the max range of 366 days. This goes beyond annotations without contradicting them.

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 concise sentences with no filler. The primary purpose is front-loaded, and the behavioral details (preserving IDs, explicit fallback gaps) are efficiently stated. Every sentence adds value.

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?

There is no output schema, so the description must convey what is returned. It mentions the preservation of series IDs, occurrence IDs, and source coverage, and explicitly notes fallback gaps. It doesn't describe the exact return structure or pagination, but for a read tool with openWorldHint, this is reasonably complete. It could mention the response format (e.g., a list of events), but it's adequate for an agent to understand the nature of the result.

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 only 33% (only courseId has a description). The description adds some parameter meaning by specifying 'explicit ISO timestamp range' and the max duration, which helps interpret the from/to parameters. However, it doesn't detail the exact format beyond what the schema pattern already provides, and it doesn't mention courseId at all. The description partially compensates for the coverage gap but not fully.

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 reads course calendar events including server-expanded recurring occurrences, with a specific scope (explicit ISO timestamp range of at most 366 days). This is a specific verb+resource+scope, and it distinguishes itself from any potential sibling like get_upcoming_deadlines by focusing on calendar events rather than deadlines.

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 description implies usage (when you need calendar events in a time range) but does not explicitly mention alternatives or exclusions. There are no direct calendar sibling tools, so the context is clear enough, but it doesn't explicitly guide the agent on when not to use it or what to use instead for other calendar-like needs.

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

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

Annotations already cover read-only and idempotent safety. The description adds a non-obvious side effect: it indexes titles/descriptions locally, which an agent should know before invoking. This is valuable behavioral context beyond the annotations, though it doesn't detail the local index mechanics or whether it can be re-run safely (idempotent hint covers that).

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 sentences, front-loaded with the primary retrieval purpose, followed by the side-effect caveat. No filler words.

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 one-param read tool, the description covers the main result and side effect. However, it doesn't connect the local index behavior to sibling tools like search_course_materials or get_index_status, leaving an agent to infer the purpose of the indexing side effect.

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 the courseId parameter has a clear description ('Exact Brightspace numeric identifier from another tool'). The tool description adds no further parameter detail, which is fine given high schema coverage.

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?

Clearly states the tool's function: fetching the nested course outline, lecture topics, document IDs, and recording links. The verb 'get' plus the enumerated resource makes the purpose specific, though it doesn't explicitly distinguish this from similar course-reading siblings like read_course_page or get_study_guide.

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?

No guidance on when to choose this tool over alternatives. It doesn't mention prerequisites, context, or exclusions. The local indexing side effect is mentioned but not tied to when this tool should be used versus search_course_materials or get_index_status.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds valuable behavioral context: 'LTI/external links are descriptors until their target is read; a listed link does not imply integration.' This is important for agents to avoid misinterpreting linked services as active integrations. It also mentions 'verified course metadata', which sets expectations about data quality.

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 two concise sentences, front-loading the purpose and scope, then adding a crucial caveat. No filler or redundancy; every sentence earns its place.

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?

Given the tool's simplicity (one parameter, no output schema), the description covers the key return concepts: a list of linked tools and verified metadata. The LTI caveat is essential for correct interpretation. It doesn't specify return format or pagination, but for a discovery tool, this is sufficient. Annotations cover the safety profile, so nothing critical is missing.

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 covers the single parameter (courseId) with 100% coverage, including a helpful description: 'Exact Brightspace numeric identifier from another tool.' The tool description does not add parameter-specific details, but the schema already provides sufficient meaning, so the baseline of 3 applies.

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 purpose: 'Discover the tools actually linked by a course', with a specific verb and resource. It enumerates what is included (native navigation, own progress, groups, external services) and adds a distinguishing detail about verified metadata. This separates it from siblings like get_course_content or list_courses without needing to name them.

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 description implies when to use the tool—when you need to know which tools are linked to a course. It does not explicitly name alternatives or exclusion conditions, but the context is clear enough that an agent can infer it from the purpose. A small gap is the lack of explicit 'use this instead of X' guidance, but it's not misleading.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds context by specifying 'locally' and 'for this signed-in account', which clarifies scope and account-specificity. It does not disclose additional behavioral traits like output format or potential delays, but the annotation coverage is strong, so a 3 is appropriate.

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, concise sentence that immediately states the action and object. It is front-loaded and contains no redundant wording. Every word earns its place, making it highly efficient.

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?

The tool has one optional parameter and no output schema. The description clearly states the purpose but does not mention that the courseId parameter filters results, nor does it hint at the output structure (e.g., a list of content items). For a read-only status tool, this is adequate but not fully complete; an agent might wonder whether the courseId is required and what the response looks like.

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%, meaning the parameter (courseId) is fully described in the schema as 'Exact Brightspace numeric identifier from another tool.' The tool description itself adds no additional parameter semantics. With full schema coverage, the baseline is 3, and the description does not enhance beyond that.

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 states a specific verb ('Report') and a clear resource ('which course content has been indexed locally'). It is not a tautology and conveys the tool's core function. However, it does not explicitly differentiate from closely related siblings like get_sync_status or clear_local_index, though the phrasing 'indexed locally' does hint at the distinction.

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 description provides no guidance on when to use this tool versus alternatives. It does not mention get_sync_status (which reports sync status) or start_course_sync (which initiates indexing), nor does it state exclusions or prerequisites. The agent must infer the use case solely from the purpose statement.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds context that this tool deals with interactive login progress and that it is process-specific. It does not describe the return format or what 'progress' entails, but given the simple nature and existing annotations, it provides sufficient additional behavioral context without contradiction.

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, efficient sentence: 'Get progress of an interactive login in this process; use check_auth to verify a saved session.' It front-loads the primary action and immediately provides a relevant alternative, with zero wasted words. This is exemplary conciseness and structure.

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, no-parameter tool, the description is fairly complete. It states what it does and distinguishes from a key alternative. However, it does not clarify what 'progress' means (e.g., possible return values) nor does it mention the existence of service-specific status tools (get_mytu_login_status, etc.) that might be more appropriate for certain login flows. Given the simplicity, this is a minor gap but leaves the agent to infer some context.

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 input schema has zero parameters, so schema coverage is 100% (vacuously). The description adds no parameter-specific information, which is appropriate since none exist. Per the calibration baseline, a tool with no parameters earns a 4, as the description does not need to elaborate on inputs.

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 function: 'Get progress of an interactive login in this process.' It uses a specific verb (Get) and resource (progress of an interactive login), and distinguishes itself from check_auth by explicitly noting that tool is for verifying a saved session. However, it doesn't differentiate from the service-specific status tools like get_mytu_login_status or get_mail_login_status, which are siblings, so the purpose is clear but not fully contrasted with all alternatives.

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 description provides a clear usage alternative: 'use check_auth to verify a saved session.' This tells the agent when not to use this tool and points to a specific alternative. It implies that this tool is for checking the progress of an interactive login, which is a distinct scenario. However, it does not mention the other status getters (e.g., get_mytu_login_status) that exist for specific login flows, leaving some ambiguity about which status tool to use in those contexts.

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

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

The annotations already establish a safe, read-only, idempotent profile, so the bar for additional disclosure is lower, as per the rubric. The description adds a meaningful behavioral trait beyond the annotations: 'Mail access lasts only for this MCP process,' which tells the agent that the login state is non-persistent and tied to the process lifetime. 'Read' is fully consistent with readOnlyHint=true, so there is no contradiction.

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 short sentences, both earning their place: the first declares the core action and scope, the second adds a critical access-lifetime caveat. The information is front-loaded with no redundancy or filler. This is a model of concise definition writing.

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 parameterless, read-only status check with a full annotation safety profile (readOnly, openWorld, idempotent), the description covers purpose, scope, and a key behavioral constraint in two sentences. No output schema exists, so the only real gap is the shape of the returned status value, but that omission is minor for such a trivial status-check tool.

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 tool has zero parameters and 100% schema description coverage, so the baseline of 4 applies. The description's mention of 'this process's' clarifies which implicit state the tool reads (the current MCP process's mail login), which is the only meaningful semantic context for a parameterless call. There is no parametric burden for the description to carry.

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 states a specific verb ('Read') and a well-scoped resource ('this process's university email login progress'), which makes the tool's function immediately clear. The phrase 'this process's' and 'university email' implicitly differentiate it from generic sibling status tools like get_login_status and from mutation tools like begin_mail_login. However, it never explicitly names a sibling alternative or states what it is not, so the differentiation is implicit rather than stated.

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 description implies the usage context: an agent would call this to check the progress of the university email login flow, and the 'lasts only for this MCP process' warning signals that status is transient. But it does not explicitly state when to prefer this over check_mail_auth or get_login_status, nor does it mention prerequisites (e.g., that begin_mail_login must be called first) or exclusions. The guidance is implied, not made explicit.

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

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 the valuable context that grades come from Brightspace and are not the official record, which is a meaningful distinction. It does not contradict annotations and provides extra scope information.

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 concise sentences with zero redundancy. The core purpose is front-loaded, and the distinguishing note about the official study record is placed immediately after, making it efficient and clear.

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 read-only tool with one parameter and no output schema, the description is nearly complete. It states what it does and how it differs from official grades. It doesn't explicitly say the grades are for the given course, but that is implied by the parameter and tool name. Minor gap, but adequate.

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%—the courseId parameter is documented as an 'Exact Brightspace numeric identifier from another tool.' The description adds no parameter-level information beyond what the schema already provides, so the baseline of 3 applies.

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 specific verb ('Read') and resource ('current student's Brightspace grades'), and immediately distinguishes from the 'official study record'. This clearly separates it from sibling tools like get_official_grade and list_official_grades, making the purpose unambiguous.

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 description signals that this tool returns Brightspace grades, which are 'separate from the official study record.' This implies when to use it instead of official-grade tools, though it does not explicitly name alternatives or state when not to use it. The context is sufficient for an agent to infer proper usage.

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds value by specifying scope (only own memberships) and what data is included ('self-enrollment configuration and dates where published'), and further confirms it avoids fetching other groups' rosters. This matches annotations and adds useful context.

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?

Taut two sentences with zero precision waste. The first sentence is a clear verb+resource statement, and the second adds scope; no redundant phrases or heavy wording.

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?

Given a simple tool (2 params, 1 required) with strong annotations and no output schema, the description provides enough about output (categories, memberships, self-enrollment config, dates) and that it is safe. It could be improved by explicitly stating the default scope of categoryId (if omitted, all categories), but overall it is complete for the tool's complexity.

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% for both parameters, and each has a clear description ('Exact Brightspace numeric identifier from another tool'). The tool description does not add extra meaning or constraints beyond this, so the baseline of 3 applies.

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 specific verb ('Read') and a concrete resource ('course group categories and your own verified memberships'), and clearly distinguishes it from sibling tools by stating what it does not do ('without fetching other groups' rosters or preparing a group'). This differentiation is strong and actionable.

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?

It gives clear contextual guidance: this tool is for reading your own memberships, not for preparation/enrollment, and not for fetching rosters. However, it does not explicitly name alternative tools (e.g., 'use prepare_group_enrollment to join'), leaving the selection slightly more indirect than a true 5.

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

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

Annotations already cover readOnly/openWorld/idempotent, and the description adds genuinely useful context beyond them: the result is 'an explicitly partial browser snapshot' and 'displayed progress does not establish course completion,' which prevents the agent from treating the data as authoritative. No contradiction with annotations.

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?

Three short sentences, each earning its place: purpose, response content, and the partial-snapshot caveat. The verb and scope are front-loaded with no filler or repetition of schema details.

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?

With no output schema, the description carries the burden of describing the return value, and it does so at a conceptual level (summary or section, availableSections, partial snapshot). It does not detail the shape of the progress fields, but for a read-only tool with rich annotations and moderate complexity, the essential guidance is present.

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 50%: courseId is fully described in the schema, but section is not. The description partially compensates by explaining sections are 'discovered from its actual summary links' and noting the response 'Includes availableSections,' which hints at how valid section values are obtained without documenting each enum option.

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 states a specific verb and resource ('Read your own visible course progress summary') and a conditional variant ('a selected section discovered from its actual summary links'). The 'your own visible' qualifier distinguishes it from official-grade siblings like get_official_grade and get_my_grades, though 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?

The scope ('your own visible course progress') implies when to use it, and 'discovered from its actual summary links' hints at a workflow. However, it does not name alternatives or exclusion conditions, so an agent must infer when to prefer this over overlapping siblings like get_study_overview or get_my_grades.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds context beyond annotations by specifying the exact resource (My TU Delft login progress) and that it is process-bound ('this process's'), which is not in the schema or annotations. It does not contradict any annotation and provides useful behavioral context for a read-only status check.

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 two short sentences that are front-loaded with the primary purpose and immediately follow with the routing guidance. Every word earns its place—no filler or repetition of the tool name or schema.

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 zero-parameter, read-only status tool with no output schema, the description is complete: it states what the tool reads, scopes it to the current process, and directs to the proper alternative for a related but distinct need. Nothing an agent needs to call it correctly is missing.

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 tool has zero parameters, so the description has nothing to explain. With no parameters, the baseline is 4 since there is no parameter information to provide; the description correctly omits parameter details that don't exist.

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 states a specific verb ('Read'), a clear resource ('this process's My TU Delft login progress'), and scopes it to the current process. It distinguishes from sibling status tools like get_login_status and check_mytu_auth by naming the alternative and its purpose, making the tool's role unambiguous.

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 description explicitly instructs when to use a different tool: 'Use check_mytu_auth to verify a saved login.' This gives a clear alternative and implies that this tool is for checking progress, not verifying credentials. It effectively tells an agent when to pick this tool over its sibling, fulfilling the usage guidance dimension.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds that it requires an exact ID and that it reads official OSIRIS results, which is useful but not extra behavioral detail like response format or error conditions.

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 one concise sentence that front-loads the action and the key constraint (exact ID). No wasted words.

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 read operation with one parameter, the description is sufficient for basic use. However, given no output schema and no mention of return format or potential errors, an agent might lack expected output details, but the tool's simplicity lowers the bar.

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 0% with only one parameter resultId. The description mentions 'exact ID' and reference to list_official_grades, which gives some semantic guidance, but it does not compensate for absence of schema documentation on the format or constraints like length or allowed characters.

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 reads a specific official OSIRIS result by ID, distinguishing it from list_official_grades which lists grades. It is not fully explicit about the distinction from other read tools like get_my_grades, but the context is specific enough.

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 description implies usage: read a result after obtaining its ID from list_official_grades, which gives clear context for when to use it, but does not explicitly mention alternatives like get_my_grades. It provides a enough guidance to route the agent.

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

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

Annotations already declare this a safe, idempotent read, so the bar for extra context is lower. The description adds meaningful behavioral detail: the login is process-scoped and the saved recording session is verified when read_recording runs, which clarifies the lifecycle beyond what the annotations convey.

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 short sentences with no filler. The primary action is front-loaded, and the second sentence provides just enough lifecycle context to make the tool's role understandable without 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?

Given there is no output schema, the description could more explicitly state what kind of value the agent should expect from 'progress' (e.g., a boolean, a step count, or a status string). It is adequate for invoking the tool with zero parameters, but the return semantics are left ambiguous.

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?

This tool takes zero parameters, so the baseline is 4. The description does not need to explain parameter behavior and correctly focuses on what the status read represents rather than any argument details.

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 specific verb ('Read') and identifies a precise resource: the progress of this process's interactive Collegerama login. It also distinguishes itself from related tools like read_recording and begin_recording_login by framing it as a progress-check for an existing login flow.

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 description implies when to use the tool—before read_recording, to check whether the interactive login has completed—but it never states this explicitly. It also does not mention alternatives or exclusion conditions, leaving the agent to infer the intended placement in the login sequence.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds behavioral specifics beyond annotations: it 'Verifies exact code/year and reports output limits' and states 'No login or LTI identity handoff,' providing useful operational details without contradiction.

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 two concise sentences with the purpose front-loaded. Each sentence adds essential information: what it reads, what it returns, verification behavior, and auth requirements. No wasted words.

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 tool with 3 parameters and no output schema, the description covers the purpose, content returned, verification, output limits, and auth requirements. It does not describe the return structure, but that's unnecessary without an output schema. It is sufficiently complete for an agent to invoke correctly.

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 0%, so the description must compensate for parameter clarity. It explicitly mentions 'exact course code and academic year' but does not explain the 'language' parameter or the patterns/constraints. The description partially clarifies the key inputs but leaves some semantic gaps.

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 function: 'Read the official public Study Guide' for a specific course code and academic year, and lists the content it returns. It implicitly distinguishes from search_study_guide by emphasizing 'exact' code/year, making the purpose unambiguous.

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 description provides clear context for when to use the tool: it requires an exact course code and academic year, and notes that no login is needed. However, it does not explicitly name alternative tools like search_study_guide for cases where the exact code/year is unknown, leaving that to inference.

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

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

Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds meaningful context beyond that: it reports missing or partial sources, surfaces conflicting dates, and explicitly does not infer completion or start attempts. These caveats are useful for an agent deciding whether this tool's answer is authoritative.

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 dense sentences with the main purpose front-loaded and the behavioral caveats in the second sentence. There is no fluff, though the long comma-separated list of content types makes the first sentence slightly heavy.

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 3-parameter aggregate read tool with no output schema, the description gives a solid high-level list of what is returned and important caveats. However, it does not describe the response shape, explain how days or includeAnnouncements affect results, or clarify the meaning of 'single sourced' well enough to fully compensate for the missing output schema.

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 0%, so the description needed to compensate by explaining courseIds, days, and includeAnnouncements. It only indirectly covers courseIds with 'selected courses' and includeAnnouncements with 'recent announcements'; days is never mentioned, and no parameter-level meaning or constraints are added in prose.

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 names a specific operation ('Get a single sourced overview') and lists concrete content types (due dates, calendar deadlines, access closing times, events, announcements), so an agent can tell this is an aggregate read across courses. It does not explicitly distinguish itself from overlapping siblings like get_upcoming_deadlines or get_calendar, but the aggregation scope makes the purpose reasonably clear.

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 description implies when to use it: whenever a consolidated multi-source overview across selected courses is needed. It does not state when not to use it or name alternatives, such as using list_assignments, list_quizzes, get_calendar, or get_announcements individually, so the routing guidance is only implicit.

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

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

Annotations already carry the safety profile (readOnlyHint, idempotentHint, openWorldHint, destructiveHint=all covering the read/benign nature), so the burden is lowered. The description adds value by listing what the status reports (state, coverage, errors, resumption offset) but offers no detail on edge behavior such as a missing job ID or the meaning of the state values. No contradiction with annotations.

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?

A single sentence that front-loads the action and resource ('Get a background sync job's state') and compresses the return areas into a short list. Every word earns its place; there is no preamble, fluff, or repetition.

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 single-parameter, read-only status tool with a strict UUID schema and no nested objects, the description is close to complete. Since there is no output schema, naming the four return areas (state, coverage, errors, resumption offset) is helpful, though it stops short of defining the state values or the channel for error/coverage semantics. Overall adequate for the simplicity level.

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 0%, but the single parameter jobId is self-explanatory and fully constrained by the schema's type, format, and pattern. The description ties the parameter to the resource ('a background sync job'), disambiguating what ID to pass. It adds just enough context for correct invocation but nothing beyond that.

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 specific verb ('get') plus a specific resource ('background sync job') and lists the exact data returned (state, coverage, errors, resumption offset). This makes it clearly distinct from the login, mail, and content siblings, though it does not explicitly disambiguate from the closely related get_index_status.

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?

There is no guidance about when to call this tool versus alternatives. An agent gets no instruction on the polling pattern with start_course_sync (the tool that presumably creates these jobs) or on how to choose between get_sync_status and the similarly named get_index_status. The only sense of usage is trivially inferable from the tool's name.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false Senator, so safety profile is covered. Description adds scope limitation ('published assignment deadlines') and explicitly notes incompleteness (other deadline sources), which is useful. Missing details like return format or default behavior but annotations cover the main behavioral traits.

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 sentences: first clearly defines the tool's function, second warns about alternative sources. Front-loaded with the primary purpose quickly, no filler words. Highly efficient.

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?

Given 2 parameters (one with strong schema description), no output schema, and clear sibling context, the description is mostly complete. It explains the scope and what it does not cover. The only missing piece is a brief explanation of the days parameter semantics, but schema provides default/range. Overall adequate for agent to correctly call the tool.

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 0%, so the description must compensate. The description does not explain the parameters (courseIds, days) beyond what the schema provides. The schema already includes descriptions for courseIds (Brightspace numeric identifier from another tool) and days has default/max/min but no semantic context. The description's omission of parameter meaning is a gap, but the schema itself does decently with types and defaults, so baseline 3 is fair.

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 ('collect'), resource ('published assignment deadlines'), and scope ('from selected courses'). Distinguishes from siblings like list_assignments and get_calendar by noting other deadlines can appear in quizzes, calendar and instructions.

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 when to use: for published assignment deadlines, and explicitly excludes quizzes, calendar, and instructions, advising to check those separately. Guides the agent away from relying solely on this tool for all deadlines.

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

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

The annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety behavior is well covered structurally. The description's 'Read' matches those annotations and adds return-content context, but it does not discuss pagination, ordering, or error behavior.

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 one efficient, front-loaded sentence. Every phrase adds value by specifying either the resource or the fields returned, with no filler or repetition.

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 one-parameter list tool, the description covers the purpose, the required parameter input, and the principal return fields despite lacking an output schema. It would benefit from a note on scope or pagination, but the absence is minor for this simple read operation.

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 input schema is the main source of parameter meaning: it defines courseId as an exact Brightspace numeric identifier from another tool and supplies a pattern. The description adds no additional parameter information, so the baseline for high schema coverage applies.

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 opens with the verb 'Read' and names the resource ('assignments'), and then enumerates the useful return fields: instructions, due dates, closing times, and attachment IDs. It is clear, but it does not explicitly distinguish itself from the sibling get_assignment for retrieving a single assignment.

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?

No guidance is provided about when to use list_assignments rather than get_assignment, list_official_grades, or other course-related tools. The correct usage context must be inferred entirely from the tool name and brief description.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful context by clarifying that it 'uses the observed learner page' and explicitly states 'no group membership changes or peer roster reads,' which reinforces the read-only nature and clarifies what it does not do beyond the annotations. This adds value without contradicting the annotations.

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 two sentences, front-loading the core purpose and then adding a clarifying constraint. Every sentence carries meaning: the first defines the action and scope, the second clarifies the data source and exclusions. There is no filler or 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 list tool with no output schema and full schema coverage for parameters, the description is sufficiently complete. It states the resource, what attributes are returned, the source page, and what it does not do. Minor gaps include not specifying pagination or output format, but these are not critical given the simplicity of the tool and the coverage provided by annotations and schema.

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%: both courseId and categoryId have descriptions ('Exact Brightspace numeric identifier from another tool'). The tool description itself does not add parameter-specific details beyond the schema, though it mentions output attributes (category, capacity, membership, joinability) which are not directly tied to input parameters. Since the schema fully documents the parameters, a baseline of 3 is appropriate.

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 verb 'read' and the resource 'native Brightspace groups offered for self-enrollment', with specific attributes (category, capacity, own membership, joinability). This distinguishes it from sibling tools like get_my_groups (which reads the user's current groups) and prepare_group_enrollment/confirm_group_enrollment (which modify membership). It is unambiguous and actionable.

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 description provides context on when to use it by explicitly stating it reads available groups for self-enrollment and by excluding operations: 'no group membership changes or peer roster reads.' This tells the agent it is not for enrolling or reading rosters, though it does not name specific alternative tools. The exclusion of membership changes and roster reads helps differentiate from enrollment and roster-related siblings, but explicit alternatives would strengthen the guidance.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds behavioral nuance by clarifying that 'active' may not correspond to the current academic year, which affects interpretation of results. There is no contradiction with annotations.

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 three short, front-loaded sentences. Each sentence carries essential information: the core action, the search capability, and a caveat about active semantics. There is no padding or redundant detail.

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?

Given there is no output schema, the description appropriately mentions the return contents ('IDs and access dates'). It covers both parameters and the key semantic caveat. It doesn't mention pagination or limits, but for a course listing tool this is acceptable. The annotations cover safety, so the description is sufficiently complete for an agent to call it correctly.

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 0%, so the description must explain parameters. It does so effectively: 'Search by course name or code' explains the query parameter, and 'Active does not necessarily mean the current academic year' clarifies the semantics of activeOnly. Both parameters are given meaning beyond the raw schema, fully compensating for the lack of schema descriptions.

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 states a specific verb ('List'), a specific resource ('your enrolled Brightspace courses'), and the output ('with IDs and access dates'). It clearly distinguishes from sibling tools like list_assignments or list_quizzes, which target different domains. The search capability is also mentioned, adding to the tool's identity.

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 description gives clear context on what the tool is for and even warns about the meaning of 'active' ('does not necessarily mean the current academic year'), which guides usage. However, it does not explicitly state when not to use it or name alternatives. Since the siblings are mostly unrelated (mail, grades, etc.), the intended use is fairly obvious, so a 4 is appropriate.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds meaningful behavioral context beyond annotations: it explains the non-recursive scanning behavior, the need for verified parent folders, and the return payload (paths, sizes, pagination). This is valuable disclosure not present in annotations.

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 two sentences with no fluff, front-loading the main action and then providing key behavioral details. Every sentence earns its place, and the structure is efficient and scannable.

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?

Given the tool has 5 parameters (2 undocumented in schema) and no output schema, the description provides some critical context (non-recursive scanning, return data) but omits parameter-specific guidance (e.g., pagination semantics, folderPath format). It is functional but not fully complete for an agent to call it confidently without additional inference.

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 only 40% (only courseId and groupId have descriptions). The description mentions 'pagination' and nested folder behavior, which partially informs startAt, maxItems, and folderPath, but it does not explain these parameters' formats or default behaviors. The description does not compensate for the missing schema documentation.

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 verb 'List' and the resource 'files or folders in your verified own-group locker', with specifics on return data (paths, sizes, pagination). It is distinct from sibling read tools like read_group_locker, though it does not explicitly name alternatives, which is a minor gap.

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 description implies usage context by specifying 'your verified own-group locker' and the non-recursive scanning rule, but it does not explicitly contrast with sibling tools or state when this should be chosen over read_group_locker or read_group_locker_file. The recursion caveat is helpful but no direct alternatives are named.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds useful behavioral context: it only lists the user's own folders, supports a parent folder filter, and instructs to follow nextCursor for pagination.

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 short sentences with no filler. The primary purpose is front-loaded, and the pagination note is appended cleanly. Every word earns its place.

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 read-only list operation, the description covers the core functionality and pagination. It doesn't specify return format, but no output schema exists and the annotations already convey the safe nature. Slight gaps on error handling and authentication are acceptable given the simplicity.

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%, with both cursor and parentId adequately described in the input schema. The description adds no additional parameter details beyond echoing 'exact folder ID' for parentId, so it meets the baseline without exceeding 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?

The description clearly states the action (list) and resource (mail folders), and specifies two modes: listing the user's own folders or children of a specific folder ID. This distinguishes it from siblings like list_mail_messages, which operate on messages rather than folders.

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 description provides context for when to use the tool (listing folders, optionally children of a given ID) and mentions pagination via nextCursor. It doesn't explicitly name alternatives, but the resource type is clear enough to differentiate from message-listing tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds two useful behavioral facts beyond annotations: reads do not mark messages as read, and results are ordered newest first. This is meaningful context for an agent deciding whether to call this tool.

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 sentences with no waste. The purpose is front-loaded, then scope/order, then a behavioral note and the key sibling pointer. Every sentence earns its place and the structure is ideal for an agent scanning quickly.

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 list tool with no output schema, the description covers the essential return type ('message summaries'), ordering, default folder, and the read-only behavior. It doesn't mention pagination or cursor usage, but the schema documents cursor and its pattern, so an agent can infer it. Given the low complexity and rich annotations, this is nearly complete.

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 covers cursor and folderId with descriptions, leaving limit undocumented. The description adds no parameter-level detail beyond the default inbox, which is already in the schema's folderId default. With 67% coverage, the description does not compensate for the missing limit semantics, but limit is self-explanatory (integer with min/max). Baseline 3 is appropriate.

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: 'List message summaries from your own Outlook folder' with explicit ordering 'newest first' and default scope 'inbox'. It clearly distinguishes itself from the sibling read_mail by noting that full bodies require that tool, so an agent can tell them apart without opening schemas.

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 description implies when to use it (for summaries) versus read_mail (for full bodies), and clarifies the default folder behavior. It does not mention search_mail or list_mail_folders, but the core alternative (read_mail) is explicitly addressed, giving an agent clear context for typical usage.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: it explains that unpublished or missing results are not inferred, and that pagination fields describe coverage of the current response only. This is meaningful additional transparency.

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?

Three sentences, each earning its place: the first defines the resource and distinguishes it from Brightspace, the second gives pagination instructions, and the third clarifies a behavioral boundary. No fluff, no repetition of schema or annotation content.

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 paginated read tool with two optional parameters and no output schema, the description covers the essential usage: what it reads, how to paginate, and what it does not infer. The only minor gap is that it doesn't describe the response shape, but with no output schema and a simple list operation, the pagination instructions largely compensate. The distinction from Brightspace gradebooks also helps contextualize the tool within the larger sibling set.

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 0%, so the description carries the burden for parameter meaning. However, the description does not explicitly explain 'limit' or 'offset' parameters. It does mention pagination concepts (nextOffset, hasMore) which indirectly relate to offset, but it doesn't add direct semantic value for the parameters themselves. With 0% schema coverage, a 3 is appropriate because the description partially compensates through pagination context but doesn't fully document the 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 clearly states the tool reads a page of official OSIRIS results from My TU Delft, explicitly distinguishing it from Brightspace course gradebooks. The verb 'Read' plus the resource 'official OSIRIS results' makes the purpose unambiguous, and the distinction from Brightspace gradebooks differentiates it from sibling tools like get_my_grades.

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 description explicitly explains pagination usage: 'Continue with nextOffset while hasMore is true' and clarifies that 'complete describes coverage of this response only.' It also implicitly distinguishes this from Brightspace gradebooks, which helps an agent choose this tool over get_my_grades or list_assignments. This is strong, actionable guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds 'Does not start an attempt,' which is a domain-specific behavioral clarification, but this largely restates the read-only nature already encoded in the annotations. It does not add details about response behavior or potential side effects beyond that.

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 short sentences deliver the core purpose and a critical exclusion with zero filler. The main action is front-loaded, and every word adds meaning. Excellent conciseness for an agent-facing description.

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 single-parameter read-only listing tool, the description is largely complete: it states what is returned (quiz metadata and availability) and what is not done (start attempt). There is no output schema, so the description partially covers return semantics; it could add pagination or filtering details, but those are not essential for this simple operation.

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 the single courseId parameter described as 'Exact Brightspace numeric identifier from another tool.' This gives the agent clear source and format guidance. The tool description itself adds no parameter-specific meaning, but the schema already carries the full burden, so baseline 3 is appropriate.

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 identifies a specific verb and resource: 'Read quiz metadata and availability.' It also draws a boundary by adding 'Does not start an attempt,' which helps distinguish it from quiz-attempt operations. However, it does not explicitly contrast it with sibling list tools like list_assignments, so it stops short of a 5.

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 description gives clear context on when to use the tool: whenever quiz metadata and availability are needed. The explicit statement 'Does not start an attempt' serves as a useful when-not clarification. It does not name an alternative tool or provide broader decision logic, but the exclusion is valuable.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds meaningful behavior beyond these: it does not fetch provider pages, media bytes, or transcripts, and it defines how pagination and merging should work. This gives the agent a precise mental model with no contradiction.

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 compact and front-loaded with the core purpose, followed by return contents, pagination, and negative scope. Every sentence adds useful information, though the 'nextStartAt' vs 'startAt' phrasing could be tightened.

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?

With no output schema, the description responsibly enumerates the return contents and behavioral boundaries. It covers pagination and non-fetching behavior adequately for a read-only listing tool. The main gap is the unclear mapping between the pagination token and the startAt parameter, plus the lack of any mention of maxDetails.

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 only 33%, so the description must compensate for undefined parameters like startAt and maxDetails. It mentions 'Resume with nextStartAt' but never explains that the input parameter is startAt, nor what maxDetails controls. The description adds no direct semantic value for two of the three 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 states a specific verb ('Discover') and resource ('recording and published caption links'), and scopes it to the visible course outline and bounded module/topic metadata. It also differentiates the tool from nearby siblings by specifying what it returns (provider labels, exact sources, native read_material targets) and what it does not fetch.

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 description gives clear usage context: it is for discovering links without fetching media, and it explains pagination behavior ('Resume with nextStartAt and merge by URL; coverage applies to the current call'). It does not explicitly name as alternatives read_recording or read_material, but the boundary it draws is sufficient for most selection decisions.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true. The description adds value by specifying exactly what is discarded (pending actions) and what remains (cached course documents stay local until explicitly cleared), which goes beyond the annotation hints and gives useful behavioral context.

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 two sentences with no filler. The primary scope (removing logins, closing email, discarding actions) is front-loaded, and the clarifying note about cached documents is placed second. Every word earns its place.

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 tool with no parameters and no output schema, the description covers the scope (all logins and email), the consequence (discarding pending actions), and the residual state (local cache remains). It is complete enough for an agent to invoke correctly, though it could explicitly mention that it is the 'all-at-once' logout compared to siblings.

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 tool has zero parameters and schema coverage is effectively 100% (no properties). Per the baseline rule, a score of 4 is appropriate since there is no parameter information needed and the description correctly focuses on behavior rather than 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 specific verb ('Remove') and enumerates the affected resources: saved Brightspace, recording, and My TU Delft logins, plus email access and pending actions. This clearly distinguishes it from sibling logout tools (logout_mytu, logout_mail) that target only one service.

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 description clearly implies this is the global logout covering multiple services, providing context for when to use it. However, it does not explicitly name alternatives or state 'use this instead of logout_mytu/logout_mail', so it lacks explicit exclusion guidance but is still clear.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, and the description adds valuable context: the session is 'process-local' and 'Saved Outlook drafts remain in your mailbox.' This clarifies what is and isn't destroyed without repeating the annotations.

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 two sentences with no wasted words. The primary action is front-loaded in the first sentence, and the second sentence provides a concise, relevant caveat.

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 zero-parameter logout operation, the description fully conveys what action is taken, the scope (process-local), and what is preserved (drafts). No output schema is present, but for a logout action the return value is not essential for correct invocation.

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 tool has zero parameters, so the schema fully covers all inputs (100% coverage). The baseline for zero-parameter tools is 4, and no additional parameter semantics are needed.

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 states a specific verb and resource: 'Close the process-local Microsoft email session.' It clearly differentiates from sibling tools like logout_mytu and logout by naming the Microsoft email session. The second sentence adds clarifying scope about drafts remaining.

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 action itself implies when to use the tool (when closing the email session), but no explicit guidance distinguishes it from alternatives such as logout or logout_mytu. There are no stated exclusions or conditions for selecting this tool over siblings, leaving the choice mostly to inference from the name.

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

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

Annotations already disclose destructiveHint=true and idempotentHint=true; the description adds useful context by naming the local login and login browser as what is removed/canceled. It does not contradict annotations, though potential side effects like token invalidation are not mentioned.

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?

A single well-formed sentence with no filler. The main action is front-loaded and every clause contributes meaning.

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 zero-parameter, no-output-schema logout tool with annotations covering the safety profile, the description names the target and operation completely. An agent has enough information to invoke it correctly.

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 tool has zero parameters and the schema is fully covered by an empty properties object. The baseline 4 applies because there is no parameter ambiguity for the description to clarify.

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 ('Remove') and resource ('current account's local My TU Delft login'), plus a second distinct action ('cancel its login browser'). This clearly differentiates it from siblings like logout_mail and the generic logout.

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 phrase 'current account's local My TU Delft login' implies the tool is scoped to My TU Delft local login, but it does not explicitly explain when to choose this over logout, logout_mail, or a server-side logout. Usage is implied rather than directly stated.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the agent knows this is a safe read-only operation. The description adds valuable context beyond annotations: it confirms the tool does not upload, describes the return values (course, assignment, group, filenames, hashes, comments), and mentions the intended usage of showing the preview to the student. No contradictions with annotations.

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 two sentences with no redundant words. It front-loads the core action, then adds the critical qualifier 'Does not upload' and the group requirement. Every sentence earns its place, and the structure is scannable for an agent.

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 preview tool with 5 parameters, no output schema, and no nested objects, the description covers the essential points: purpose, the no-upload behavior, group requirement, and return values. It does not mention error conditions or prerequisites like authentication, but those are likely handled by other context. The description is sufficient for an agent to decide when and how to invoke this tool correctly.

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 60%, with courseId, assignmentId, and groupId already described as 'Exact Brightspace numeric identifier from another tool'. The description adds meaningful context for groupId by noting it is required for group assignments and should come from get_my_groups. However, it does not clarify the format or constraints of files or comments beyond what the schema provides (array of strings, max length). The description partially compensates for the coverage gap but not fully.

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 action ('Preview uploading') and the resource ('specific local files to an individual or group file assignment'). It explicitly distinguishes from the confirm step by saying 'Does not upload', which separates it from siblings like confirm_assignment_submission. The scope is precise and unambiguous.

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 description provides a clear condition for when to use this tool: it is for previewing before upload, and it explicitly states the requirement for groupId when dealing with group assignments, referencing the source (get_my_groups). It does not name alternative tools explicitly, but the 'Does not upload' statement implies that the confirm tool is the follow-up. This is adequate guidance, though it could be more explicit about when to choose this over prepare_text_submission.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the key behavioral fact that no enrolment occurs and that it is a preview step, which is useful but does not go much beyond what annotations and the tool name suggest.

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 short sentences, front-loaded with the core purpose and immediately followed by the key non-enrolment caveat. Every word earns its place and there is no redundant restatement of the tool name.

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 single-parameter read-only preview tool, the description covers what is previewed, the no-enrolment guarantee, and the expected flow before confirmation. Since there is no output schema, the description partially describes the output by naming membership state and available enrolment action, which is adequate for this complexity level.

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 0%, so the description must compensate, but it does not explain the courseUrl parameter beyond the parameter's own self-explanatory name. It hints that the tool identifies an exact course, but does not clarify what kind of URL is expected, where to obtain it, or how it relates to the previewed course/code/semester.

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 specific verb ('Preview'), a specific resource ('an exact Discover course'), and states the outcome (course, membership state, available enrolment action). It also explicitly disclaims enrolment ('Does not enrol'), which clearly separates it from sibling confirm_course_registration.

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 phrase 'before confirming' gives clear sequencing context and the disclaimer 'Does not enrol' implies this is the safe pre-confirmation step. It does not explicitly name the alternative tool, but the context is sufficient for an agent to infer when to call it.

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

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

The description explicitly states 'no place is reserved and no membership changes,' which reinforces the readOnlyHint and destructiveHint annotations and adds the important nuance that no reservation is made. This goes beyond the annotations by clarifying the operation has no side effects on group capacity or membership.

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?

Three short sentences convey purpose, side-effect behavior, and usage guidance without redundancy. Each sentence earns its place, and the most important scoping information is front-loaded.

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?

The description is sufficient for an agent to call the tool correctly given the rich annotations and fully documented schema. It does not describe the returned preview shape, but the instruction to present the exact preview implies the output itself is the preview, so the gap is minor.

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 schema already explains that each parameter is an exact Brightspace numeric identifier. The description adds the source context 'from list_available_groups' and mentions binding course, category, and group, but does not materially change parameter understanding beyond what the schema provides.

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 it previews joining an exact native Brightspace group and explicitly scopes the group source to list_available_groups. The contrast with membership changes and approval makes it distinguishable from confirm_group_enrollment without needing to open schemas.

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 phrase 'Present the exact preview before requesting approval' gives clear sequencing guidance and implies this tool is the pre-confirmation step. It does not explicitly name the alternative confirm_group_enrollment or state when not to use it, so a small inference remains.

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

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

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint=false, lowering the bar. The description adds valuable behavior beyond those hints: it confirms no side effects ('without filling the editor or submitting'), discloses that it reports 'overwrite/group effects', and exposes a size limit. This is consistent with annotations and gives extra operational context.

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 sentences with no fluff: the first states the purpose and return values, the second gives the groupId condition and a size/approval note. Every clause earns its place, and the main action is front-loaded.

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?

With no output schema, the description explicitly lists what is returned (exact course, assignment, text, hash, prior submissions, overwrite/group effects) and covers the key operational constraints (groupId, limit, no mutation). It gives enough for an agent to invoke it correctly and know what to expect back.

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 75%, so the schema already documents patterns for courseId, assignmentId, and groupId. The description adds meaning by explaining that groupId is specifically required for group assignments, and it restates the 256 KiB UTF-8 length limit in operational terms. This goes beyond the structured data without duplicating 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?

The description uses a specific verb ('Preview') and resource ('literal plain text for a native text assignment'), and distinguishes itself from submission tools by stating it returns details 'without filling the editor or submitting.' It also enumerates the exact return values, so an agent can tell it apart from siblings like confirm_text_submission or prepare_group_enrollment.

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?

It gives a concrete precondition ('Group assignments require an explicit own groupId') and usable constraints ('Limit 256 KiB UTF-8; show the full preview before approval'). It does not explicitly name sibling alternatives such as confirm_text_submission or say when not to use the tool, so it falls just short of full guidance.

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

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

The description reveals that the operation can read, index, or download and that it returns 'sourced extracted text and optional local path', which adds behavioral context beyond the idempotent/readOnly annotations. It does not detail side effects of indexing or where downloading writes files, but it does not contradict the annotations (readOnlyHint=false is consistent with download/index).

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 sentences, front-loaded with the core purpose, and no filler. The cross-reference to get_announcements is placed where it is immediately actionable.

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 6-parameter tool with no output schema, the description states the inputs' origin, the action, and the return shape ('sourced extracted text and optional local path'). It could specify how offset/maxChars/download affect the call, but an agent has enough to invoke the tool correctly.

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 50%, and the description helps for the three required IDs by pointing to get_announcements as their source. However, offset, download, and maxChars have no schema description and only 'optional local path' hints at download's effect; the description does not fully compensate for the undocumented optional 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 opens with a specific verb phrase—'Read, index or download a file belonging to an exact course announcement'—which names the exact resource and scope. It further disambiguates by directing the agent to get_announcements for the required IDs, so it cannot be confused with other attachment-reading siblings.

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?

It gives a useful prerequisite ('Use announcement/file IDs from get_announcements'), but it never states when to choose this tool over read_assignment_attachment, download_material, or read_material. There is no explicit exclusion or alternative selection condition, so usage context is only implied.

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

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

The annotation readOnlyHint is false, implying the operation may have side effects, but the description says 'Read or download' which suggests a read-only action. This is a direct contradiction. The description also does not disclose any potential side effects, permissions, or other behavioral traits, leaving the agent with a misleading impression.

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, efficient sentence that front-loads the core purpose and includes a helpful pointer for obtaining the file ID. There is no wasted wording.

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 tool with 6 parameters and no output schema, the description leaves significant gaps. It does not clarify the behavior of the optional parameters, the return format, or any side effects, and it contradicts the readOnlyHint annotation. The agent would need to infer too much to use it correctly.

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 covers only 50% of parameters (courseId, assignmentId, fileId have descriptions), and the description adds the crucial detail that file IDs come from list_assignments/get_assignment, which is useful. However, it does not explain the optional parameters offset, download, and maxChars, which are also undocumented in the schema. The description only partially compensates for the missing schema coverage.

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 verb (read/download) and the resource (attachment belonging to a specific assignment), and it even directs the agent to obtain file IDs from list_assignments/get_assignment. It does not explicitly differentiate from siblings like read_announcement_attachment or read_my_submission_file, but the resource scope is unambiguous.

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?

It tells the agent where to get the file ID (from list_assignments/get_assignment), which provides context for using the tool. However, it does not state when to prefer this tool over other attachment-reading tools, nor does it mention any exclusions or prerequisites beyond the ID source.

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

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

Annotations already convey idempotence and non-destructiveness; the description adds that only the current user's response determines the feedback owner and that the attachment is published. However, the non-read side effects implied by 'index' and 'download' are not explained despite readOnlyHint=false.

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 sentences with purpose front-loaded; every clause earns its place. There is no filler or redundant restating of the tool name.

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?

With no output schema and six parameters, the description leaves optional behavior (offset, download, maxChars) unexplained and does not describe what the tool returns in read versus download/index modes. It covers basic call prerequisites but not enough for confident invocation of all modes.

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 covers only 3 of 6 parameters (50%), and the description compensates only for file/course/assignment IDs via 'Exact Brightspace numeric identifier from another tool' plus the get_assignment_feedback source. offset, download, and maxChars remain undocumented in both schema and description.

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 three specific actions ('Read, index or download') on a clearly named resource ('published feedback attachment') and identifies the ID source ('File IDs come from get_assignment feedback'). This distinguishes it from sibling attachment readers such as read_assignment_attachment or read_announcement_attachment.

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 clear context for when to use it: reading published feedback attachments for assignments or group assignments, with a prerequisite ('File IDs come from get_assignment feedback') and owner scoping. It does not explicitly name alternatives or exclusion conditions, so it falls short of a 5.

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

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

Annotations already carry readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral value not present in the annotations: the result is a 'partial browser snapshot' (acknowledges incompleteness), the page must be 'same-origin' (a real access constraint), and 'no form interaction' (a hard limitation). This is constructive behavioral context rather than a repeat of the annotations.

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?

A single 21-word sentence with no waste and no filler. Every clause earns its place: the verb and resources, the fallback condition ('when an API cannot expose it'), the outcome caveat ('partial browser snapshot'), and the exclusion ('no form interaction'). It front-loads the core action and each remaining fragment carries semantic weight.

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 one-parameter, no-output-schema tool whose annotations already declare read-only, open-world, and idempotent behavior, the description covers what is read, the case that triggers it, the limitation of the result, and the constraint on the input. The description could explicitly state what the return payload contains, but since the outputs (visible text, links, embedded media) are already listed as the objects being read, nothing essential is missing.

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 offers only 'url: string, uri' with 0% description coverage, so the description must compensate. It does so by narrowing the valid value set to 'a same-origin Brightspace page (a Brightspace page)', which is materially more information than the raw URI type. It still leaves relative-vs-absolute formatting open and doesn't fully specify page eligibility, but for a single-string parameter the compensation is substantially adequate.

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 specific verb ('read') with concrete resources ('visible text, links and embedded media') on a defined target ('a same-origin Brightspace page'), and the condition 'when an API cannot expose it' positions this as a browser-snapshot fallback. This clearly distinguishes it from API-backed siblings like get_course_content, read_course_service, and read_material. The 'partial browser snapshot' clause further cements the resource without ambiguity.

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 description explicitly states when to use this tool: 'when an API cannot expose it', giving a clear fallback context relative to API-backed siblings. It also gives a when-not condition via 'no form interaction', telling the agent not to expect form capabilities. It stops short of naming specific alternative tools, so the guidance is clear but not maximally explicit, which keeps it a 4 rather than a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, but the description still adds meaningful behavioral context: the university/provider receives identity, role, and course claims; the response is an initial partial page or anonymous public course info; and the tool does not join groups or edit the service. This exceeds what annotations alone convey and contains no contradiction.

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 three well-organized sentences that front-load the action and resource, then explain the behavioral mechanism and output, and close with a crucial non-effect ('Does not join groups or edit the service'). No sentence is wasted.

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?

With only two required parameters, no output schema, and a non-trivial LTI handoff behavior, the description covers what the agent needs: what is read, what happens during handoff, what kind of response to expect, and what side effects do not occur. The output form is described well enough given the lack of an output schema.

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 50%: courseId has a description, but service does not. The description partially compensates by naming the two service values ('Study Guide' and 'Group Self Enrollment') and framing the courseId as an observed course link identifier. It could more explicitly tie courseId to the 'from another tool' schema hint, but the overall meaning is sufficiently conveyed.

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 identifies a specific verb ('Read'), a specific resource ('observed Study Guide or Group Self Enrollment course link'), and a distinctive mechanism ('normal LTI sign-in handoff'). It distinguishes this from sibling tools like read_course_page and get_study_guide by noting the observed-link LTI flow and the source/course-match result.

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 description clearly implies when to use this tool: when reading an observed Study Guide or Group Self Enrollment course link via the normal sign-in handoff. It does not explicitly name alternatives or exclusion cases, but the context is clear enough for an agent to route to this tool over plain course-page readers.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so 'Reads only' is redundant. However, the description adds behavioral value by explaining how result scope changes with forumId and topicId, which goes beyond the structured annotations and 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?

The description is just two short sentences, front-loads the default behavior ('List forums'), then explains the optional parameter escalation in a compact way. There is no filler or repetition beyond the redundant but harmless 'Reads only.'

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 hierarchical listing tool, the description is largely complete: it covers the default call, the two optional parameter levels, and the safety profile. It does not describe return format, but for simple discussion listing this is not a major blocker, especially with no output schema present.

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 baseline is 3, but the description goes further by defining the relationship between the parameters: forumId alone selects topics, and both forumId and topicId select posts. The schema alone only labels them as numeric identifiers from another tool.

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 states a specific verb ('List') and resource ('forums'), and the tool name 'read_discussions' makes the scope unambiguous. The conditional phrasing also distinguishes the forum/topic/post hierarchy without needing to name sibling tools.

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 description gives direct, actionable guidance: omit optional IDs for forums, add forumId for topics, and add both forumId and topicId for posts. It does not explicitly name alternative tools or say when not to use this tool, but it fully explains the main decision an agent faces when invoking it.

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

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

Beyond the annotations, the description adds valuable behavioral context: membership verification, the return contents ('visible files and links'), and exclusions ('does not upload, delete or download'). This is significant extra transparency, especially with no output schema present.

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?

Each of the three sentences earns its place: purpose, parameter source, and behavioral scope. It is front-loaded with the main action and avoids redundant restatement of the tool name or 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?

Given no output schema, the description adequately conveys the return type ('visible files and links'), the membership requirement, and the non-mutating scope. It could more explicitly distinguish this tool from list_group_locker_files or describe output structure, but it is sufficiently complete for invoking the tool correctly.

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 already describes both parameters as 'Exact Brightspace numeric identifier from another tool', so schema coverage is 100%. The description adds one useful hint ('Use groupId from get_my_groups'), but does not substantially expand on each parameter beyond the schema.

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 states a specific action ('Read the shared locker page') and a specific resource ('exact group you belong to'), and explicitly lists what it does not do ('does not upload, delete or download locker files'). This clearly differentiates it from file-level siblings like list_group_locker_files and read_group_locker_file.

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?

It gives clear usage context: read the page for an exact group you belong to, and use groupId from get_my_groups. It does not explicitly name alternatives or say when not to use this tool, but the constraints are strong enough for an agent to select it appropriately.

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

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

Annotations already provide idempotentHint=true and destructiveHint=false. The description adds valuable behavioral context beyond those: it rechecks group membership and ancestor folders, returns bounded extracted text or an unsupported-format warning, and explicitly states it does not upload or change locker files. The 'index' behavior is slightly ambiguous, but overall this is strong supplementary disclosure.

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?

Three sentences, all informative: the core action is front-loaded, behavioral guarantees follow, and exclusions are stated without repetition. No filler or redundant restatement of the tool name.

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?

The description covers the file source, membership revalidation, and return type at a high level. But with no output schema and multiple undocumented parameters, it leaves gaps around download behavior, offset and maxChars semantics, and error handling beyond unsupported-format warnings. It is minimally viable but not fully complete.

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 only 33%, and the description does not compensate for the undocumented parameters. filePath is loosely implied to come from list_group_locker_files, but offset, download, and maxChars get no semantic explanation. The description adds little beyond what the schema already states.

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 states a specific action (read/index/download) on a precise resource (an exact file returned by list_group_locker_files). It clearly distinguishes this tool from sibling tools that operate on folders or file listings, so an agent can select it without opening the schema.

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 description provides a clear prerequisite: the file must be an exact file returned by list_group_locker_files. It also rules out upload/change behavior, helping to prevent misuse. However, it does not explicitly name alternative tools or state when to use a different file-related tool, so it stops just short of full routing guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context beyond those annotations by specifying the return scope ('bounded plain text and recipients') and explicitly stating negative behaviors ('Does not download attachments or change read status'). This gives an agent concrete expectations for side effects and output content.

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 efficient sentence that front-loads the core action, then covers the most important return contents and non-effects. Every clause earns its place, with no redundant or filler language.

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 one-parameter read operation with no output schema, the description provides enough behavioral and output context: it names what is included, what is excluded, and confirms no state change. It could additionally mention how to obtain a valid messageId, but the schema already states the ID comes from a mail tool, and sibling discovery tools are evident.

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 the schema already describes messageId as 'Exact message or folder ID returned by a mail tool.' The description does not add any new meaning to the parameter beyond reinforcing that it identifies an exact message. Baseline 3 is appropriate because the schema carries the parameter documentation burden.

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 states a specific verb ('Read') and resource ('an exact message from your own Outlook mailbox'), and adds precise scoping details: bounded plain text and recipients. It also explicitly differentiates from sibling tools by noting it does not download attachments or change read status, distinguishing it from listing, searching, or draft-creation tools.

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 usage context is implied rather than explicit: 'Read an exact message' suggests the caller already has a messageId, and sibling tools like list_mail_messages and search_mail are the likely discovery tools. However, the description never states 'use this when you have a messageId' or explicitly contrasts with list/search alternatives, so guidance is implied rather than stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds valuable caveats: 'Code and formulas are not executed' (a safety note) and 'Returns text in chunks with nextOffset' (pagination behavior), which go beyond the annotations. This aligns with and enriches the annotated 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 concise, packed into three sentences with the core action and formats front-loaded, followed by important caveats and return structure. No redundant filler; every sentence contributes value.

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 tool with strong annotations, the description covers supported formats, safety (no execution), pagination (chunks, nextOffset), and external resource behavior. It lacks explicit detail on the exact output structure or how courseId/topicId relate, but given the absence of an output schema and the read-only annotations, it is fairly complete.

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 50%: courseId and topicId have descriptions ('Exact Brightspace numeric identifier from another tool'), but offset and maxChars have only defaults/ranges. The description implies 'chunks' and 'nextOffset', clarifying the offset parameter's purpose, but does not explain maxChars or the relationship between courseId and topicId. It partially compensates for the schema gap but not fully.

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 verb ('Extract and index') and the resource ('lecture material'), and enumerates supported formats (PDF, DOCX, etc.). It is specific enough to understand the tool's function, though it does not explicitly distinguish itself from siblings like download_material or read_course_page, which also deal with course content.

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 description implies the tool is for extracting text content from lecture materials, but provides no explicit guidance on when to prefer it over alternatives. It does not mention exclusions (e.g., 'use download_material for binary files') or name sibling tools, leaving the agent to infer usage based on the formats listed.

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