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

With no annotations, the description carries the full burden. It usefully discloses a mutation-side effect and a validation gate (submission blocked on unanswered/errored questions) plus the force_submit escape hatch. It omits other important traits for a write tool: whether submission is irreversible, whether answers are persisted when submit=false, and any permission/auth requirement.

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 core action is front-loaded in one sentence, followed by the two pieces of information that actually need elaboration: the answers key/value format and the submission gate. No filler, though the backtick-heavy formatting is slightly noisy.

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 5-parameter mutation tool with a nested object, no annotations and no output schema, the description covers the answer format and the blocking rule but leaves out what the call returns, how errors/partial failures surface, and how to obtain valid question ids. Adequate but not 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 0%, so the description must compensate, and it does for the hardest parameter: `answers` is documented as mapping question_id or question order number to normalized values (single letter, combination, true/false, blank text). force_submit's intent is also covered. `submit` (defaulting to true), `task_id` and `course_id` are 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 first sentence gives a concrete verb and resource: fill objective questions with provided answers and optionally submit. It is clearly distinct from read-oriented siblings like uplus_inspect_homework and uplus_list_homeworks, though it never names a sibling explicitly to sharpen the boundary.

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 states a real when-not condition — submission is blocked while questions are unanswered or errored, and force_submit should only be used after deliberately reviewing the outcome. It does not, however, route the agent to a prerequisite step (e.g. using uplus_inspect_homework to obtain question ids) or explain when to leave submit=false.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It says the tool checks session validity but does not explain whether the check has side effects, what it returns, whether it refreshes a token, or how an invalid session should be handled.

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 with no wasted words, and the core purpose is front-loaded. It is appropriately sized for a no-parameter status-check 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?

For a simple zero-parameter tool, the description is sufficient to invoke it but incomplete for interpreting the outcome. Because there is no output schema and no annotations, the description should ideally state what the check returns and what an agent should do when the session is invalid.

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%, so there is no parameter semantics gap. The baseline for a no-parameter tool is 4, and the description introduces no misleading parameter expectations.

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 ('Check') and a precise resource ('persisted U+ login session') with an explicit condition ('still valid'). It clearly distinguishes this authentication-status check from the sibling tools, which all perform listing, inspection, answering, uploading, or lifecycle operations.

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 on when to call this tool versus alternatives, nor any indication of what an agent should do based on the result. The context implies it is an authentication check, but no explicit usage conditions, prerequisites, or follow-up actions are 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?

No annotations are provided, so the description carries the full burden. It does disclose that the session is process-shared, which is useful, but it says nothing about idempotency when no session is open, whether subsequent calls fail, or whether closing invalidates login state (relevant given the uplus_check_login sibling).

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; the scope constraint lands immediately.

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-argument teardown tool this covers the essentials, but with no annotations and no output schema the description should say more about post-close state and whether re-login is required.

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 takes zero parameters, so the schema imposes no documentation burden and the description adds nothing it needs to.

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 (Close) and resource (browser session) with scope qualifier 'held by this server process'. That scope is what separates it from the data-fetching siblings, 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?

Usage is only implied: you close the session when finished with it. There is no explicit 'call this after X' or 'do not call while doing Y', and no mention of what to do if no session exists.

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?

With no annotations, the description carries the full burden. It discloses what is returned (status plus a structured question brief) and that the operation 'opens' a homework, but it never says whether opening has side effects (locking, marking as viewed), what auth or enrollment is required, or what happens on invalid IDs.

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 action and return value, with the second sentence adding genuine workflow value. Minor reStructuredText markup and whitespace add a little noise but no substantive waste.

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 are no annotations and no output schema, so the description must cover behavior and returns; it names the return shape only generically ('status plus a structured question brief') without describing the brief's structure or status values, and it leaves both required parameters entirely unexplained.

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% and both parameters (task_id, course_id) are undocumented in the schema. The description never mentions either parameter, so an agent must infer that a homework is identified by a task/course pair with no guidance on format or source.

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: 'Open a homework and return its status plus a structured question brief.' It also implicitly distinguishes itself from the sibling uplus_answer_homework by naming it as the downstream consumer, though it does not explicitly contrast with uplus_list_homeworks.

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 establishes a clear workflow context: this tool is the step that produces the brief used to build the answers map for uplus_answer_homework. It stops short of stating exclusions, prerequisites, or conditions under which this should be skipped.

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?

With no annotations provided, the description carries the full burden. It does disclose one meaningful behavioral trait — results are scoped to the signed-in account, not arbitrary users — which is real value. However, it says nothing about failure behavior when unauthenticated, result size/ordering, or whether the list is paginated.

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. The scoping constraint ('signed-in account') arrives immediately, and nothing is repeated from the schema or title.

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 tool with an output schema (so return values need not be described), the description covers the essentials and the account scoping. The only gap is the precondition of being signed in, which is the main thing an agent could get wrong.

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 takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The schema is empty and fully self-explanatory.

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 (List) and resource (courses) with a clear scope qualifier (attached to the signed-in account). It is easily distinguishable from siblings like uplus_list_homeworks or uplus_list_experiments, though it doesn't explicitly name those 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 gives no explicit when-to-use or when-not-to-use guidance, and no prerequisites. A sibling named uplus_check_login exists, but the description never states that authentication must be established first or what to do if the session is absent.

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?

No annotations are provided, so the description carries the full behavioral burden; 'List' plus an output schema implies a read-only operation, and the mention of 'submission state' is useful extra context beyond the name. It still omits auth requirements, pagination, and whether results cover all experiments or a filtered set.

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?

One short sentence with the resource and scope front-loaded and no filler. It is efficient, though slightly under-specified rather than genuinely terse-and-complete.

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?

Since an output schema exists, return values need not be explained, and the description covers scope and the notable 'submission state' field. Given a single-parameter read tool, the remaining gaps (auth, pagination) are 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 coverage is 0% with a single required parameter, so the description must compensate. 'For one course' does clarify that course_id scopes the result to a single course, which is the key semantic, but the expected ID format (numeric vs string identifier) is left unstated.

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 ('List') and resource ('experiments') plus the scope ('one course') and an extra data point ('submission state'). This separates it from siblings like uplus_list_homeworks or uplus_list_courses by resource name, though it never explicitly contrasts itself with 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 phrase 'for one course' implies the tool is scoped by course_id, and the listing nature is implicit in 'List'. However, there is no explicit when-to-use guidance, no mention of prerequisites (e.g. whether login is required, cf. the uplus_check_login sibling), and no stated alternative for other resource types.

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?

With no annotations, the description carries the full burden, and it does disclose a real behavioral trait: refresh_page_state opens each answer page to read the button label, implying extra requests and cost. It omits prerequisites (the existence of uplus_check_login suggests auth may be required), any rate/pagination behavior, and whether listing itself is a pure read.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the core purpose, then the optional flag's caveat. No padding, though the backtick/markdown formatting is slightly at odds with plain-text spacing.

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, all-optional read tool with an output schema and no annotations, the description covers purpose, scoping, and the one non-obvious parameter's tradeoff. Return values needn't be explained given the output schema, so nothing essential for correct invocation 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?

Schema coverage is 0%, so the description must compensate, and it mostly does: it explains course_id's default semantics (omitted = every configured course) and what refresh_page_state actually does and when to enable it. It adds meaning beyond the bare boolean type, though it doesn't specify course_id's format (ID vs name).

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 homeworks") plus the scoping rule (one course vs all configured courses when omitted), which is enough to distinguish it from uplus_list_courses or uplus_inspect_homework. It stops short of explicitly contrasting with the closely related inspect/answer siblings, so an agent must infer the boundary.

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 conditional for the refresh_page_state flag ("use it when API status looks ambiguous"), which is genuine usage guidance. However, it never says when to call this tool rather than uplus_inspect_homework or uplus_answer_homework, so tool-level selection is left 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?

With no annotations, the description carries the full burden and discloses meaningful behavior: it distinguishes submitted/pending/outstanding/takeover items, collects objective questions for the client model, tries built-in auto-answer rules only when auto_answer=True, and restricts submit=True to homework with valid answers while never auto-submitting files or subjective items. It does not disclose prerequisites such as login state, whether submissions are reversible, or where the Markdown report is saved.

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 front-loaded with the core action and then uses three tightly scoped bullets. Every sentence adds useful behavioral or parameter context, and there is no repetition or filler.

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 absence of annotations and an output schema, the description covers the behavioral flow well: discovery, classification, answer briefing, auto-answer fallback, and submission constraints. It is still missing some information an agent might need, such as the report's return value or save location and any authentication prerequisite, so it is strong 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 0%, but the description fully explains both boolean parameters. auto_answer is defined as trying built-in rules first with unanswerable items remaining in takeover, and submit is defined as submitting only homework that received valid answers, with file and subjective items excluded. This adds substantial meaning beyond the bare parameter names.

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: 'Run a full patrol over configured courses and save a Markdown report.' It then enumerates the key sub-actions (listing homeworks/experiments, building an answer brief, submitting valid answers), making clear this is an aggregate orchestration tool rather than one of the sibling list/inspect 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?

It gives clear context for when to use it: a full patrol across configured courses, with explicit behavior for the submit and auto_answer options. However, it does not explicitly name alternatives like uplus_list_homeworks or uplus_inspect_homework, nor does it state when not to use this aggregate sweep.

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?

No annotations are provided, so the description carries the full disclosure burden. It does not say whether an upload replaces an existing attachment, what the file size or format limits are, whether it is irreversible, or what the call returns — significant gaps for a write operation.

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 and its target.

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 three-required-parameter mutation tool with no annotations, no parameter descriptions, and no output schema, the description is too thin. An agent lacks the information needed to supply correct IDs safely or anticipate the result of the upload.

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% and the three parameters (task_id, course_id, file_path) are undocumented in the schema. The description only hints that file_path is a local filesystem path ('local file'); task_id and course_id get no explanation at all, nor any note on where to obtain them.

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 gives a specific verb and resource ('Attach a local file') plus the target ('a homework that requires upload'), which is enough to distinguish it from siblings like uplus_answer_homework or uplus_inspect_homework. It stops short of explicitly naming an alternative, but the purpose is 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?

'to a homework that requires upload' implies the triggering condition, but the description gives no explicit prerequisites (login state, valid task_id/course_id, file type restrictions) and never mentions when not to use it or which sibling to use for other homework actions.

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