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

Annotations cover the safety profile (readOnly, idempotent, non-destructive, closed world). Description adds real behavioral context: cached data, default six-day window, Europe/London fallback timezone, unknown-date count, and non-persistent overrides. That's meaningful disclosure beyond 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?

Four compact sentences, all informative, front-loaded with the core behavior. No filler, though the mix of windowing, timezone, and override details in a single paragraph is dense.

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-output-schema tool, the description covers the essentials: data sources, default window, timezone behavior, and override persistence. However pagination params (limit, offset) and the return structure remain entirely undocumented.

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 description must compensate. It clarifies date range semantics (YYYY-MM-DD, Europe/London default window) and mentions per-call language/timezone overrides, mapping to locale/display_timezone. But limit and offset are 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 a specific verb-and-resource combination: unifying cached classes, assignment deadlines, and active local tasks into a paged agenda. Distinguishes from study_deadlines and study_tasks which likely cover single-source views, though it doesn't name them 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?

Implies use for viewing a combined schedule in a time window but never states when to prefer this over study_deadlines, study_tasks, or study_status. No explicit when-not 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 declare readOnlyHint=false (a write) and destructiveHint=false, consistent with 'Save'. The description adds genuine context beyond the annotations: privacy exclusions (no cookies/passwords/auth links) and the retention rule that 'items missing from this page are retained'. This is real behavioral 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 short, front-loaded sentences with the purpose first and constraints following. Efficient, though slightly terse and stream-of-consciousness in the constraint list.

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 complex nested write schema with no output schema, the description conveys intent, privacy rules, and retention semantics but gives no field-level guidance for the many nested properties or their enums. Adequate at the intent level, thin at the structural 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% and the single parameter is a deeply nested object with many undocumented fields (source enum, items array, kind/status enums). The description hints at excerpts, scope/coverage, and no guessed dates, partially compensating, but leaves most fields without semantic guidance.

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 ('Save evidence actually read in the browser'), which is clear on its own. However, it does not differentiate from overlapping siblings like study_collect or study_evidence, so an agent must still infer which of these capture-type tools applies.

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?

Implies usage (when you have read something in the browser) and gives negative constraints ('No cookies, passwords, auth links or guessed dates'), which is useful. But it never states when to prefer this over alternatives such as study_collect or study_evidence, nor any prerequisites.

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 only say readOnly=false, destructive=false, openWorld=false. The description adds genuine behavioral value beyond that: upsert semantics ("Repeating the same item and collection updates that entry"), the meaning of archived=True, and an explicit impact boundary (no school record changes).

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, front-loaded with the action and item types, then upsert behavior, then the safety boundary. No filler, though the archived clause is slightly terse.

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 0%-coverage schema with no output schema, the description adequately covers what gets saved, upsert behavior, archiving, and the blast radius. It omits what the call returns and any permission requirements, which are minor gaps.

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 carry the load. It explains archived=True, tags/notes, and the collection target, which covers most parameters, but says nothing about item_id's expected form or the "Inbox" default exposed in 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?

Specific verb ("Save") plus enumerated resources (school page, course resource, internship, event) and a destination (local collection). It is clearly a write-to-collection tool, though it never names a sibling like study_collections or study_capture 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?

Implies when to use it (saving an observed item) and clarifies scope with "no school record changes," but gives no explicit when-not or alternative (e.g., how it differs from study_capture or study_collections).

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 declare read-only, idempotent, non-destructive behavior, so safety is covered. The description adds almost nothing beyond that: it doesn't explain pagination, default result detail, handling of archived items, or what 'linked to the latest cached evidence' actually means operationally.

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, compact sentence with no filler. It is front-loaded with the core action, though the trailing clause about cached evidence could be clearer.

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 six undocumented parameters, no output schema, and ambiguous behavioral hints, the description is inadequate. It does not explain what constitutes a 'collection', how results are returned, or how the cached evidence linkage affects results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description does not mention any of the six parameters (limit, query, detail, offset, collection, include_archived). With no parameter documentation anywhere, the description fails to compensate for the severe 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?

States a specific verb (Search) and resource (saved school resources, notes, tags), which gives partial clarity. However, the phrase 'linked to the latest cached evidence' is vague and confusing, and the description doesn't clearly distinguish this tool from siblings like study_search or study_evidence.

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 use this tool versus alternatives such as study_search or study_evidence. The description implies searching saved collections but offers no context, prerequisites, or exclusions.

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 only declare readOnlyHint=false, openWorldHint=true, destructiveHint=false. The description adds real context: it creates server-side state (a job_id), it is interactive rather than headless, it permanently sets up a reusable profile, and session expiry can force a re-login. That is meaningful disclosure beyond the annotations, though it says nothing about permissions or concurrency on the same 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?

Three sentences, front-loaded with the action, then mechanics, then the return value and follow-up. Each sentence carries information, though the 'without a host browser, screenshots or Save As' clause is slightly dense and could be trimmed.

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 input schema fields and no output schema, the description fully carries the burden: it explains the interactive step, the reusable-profile side effect, the returned job_id, the polling sibling, and the expiry caveat. An agent has everything needed 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 takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The description's mention of job_id is an output, not an input, so no further 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?

States a specific verb and resource: starting an interactive campus login in a dedicated local Chrome profile. This is clearly distinguishable from siblings like study_school_status or study_school_job, and the description explicitly names study_school_job as the polling companion.

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?

Explains the operating model: the user enters credentials/MFA directly, and later course/resource/download jobs reuse the profile without a host browser. It also tells the agent to poll study_school_job, but it does not state when to avoid this tool (e.g., if a session already exists) or how to detect that case beyond the expiry note.

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, non-destructive and closed-world, so safety is covered. The description does add one genuinely useful behavioral detail beyond the annotations: results include assignments with unknown dates even though a date range is required. It says nothing about ordering, pagination, or result shape.

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 tight sentence, front-loaded with the verb and resource, that also carries the two most important qualifiers (inclusive range, unknown-date inclusion). No 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?

For a simple two-parameter read tool with no output schema, the description covers purpose, range semantics, and the notable unknown-date behavior. The main gap is the absence of any guidance on ordering or how the two parameter values are interpreted relative to assignment dates.

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 both parameters (start, end) are undocumented in the schema. The description compensates partially by specifying the date format (YYYY-MM-DD) and that the bounds are inclusive, which is real added value, but it leaves questions like timezone handling and whether the range is on due date or start date unaddressed.

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 (assignment deadlines) with a clear scope constraint (between two dates, inclusive) and an extra behavior (unknown-date assignments). It doesn't name or differentiate against near siblings such as study_agenda or study_plan, so it falls 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?

There is no when-to-use guidance, no indication of prerequisites, and no reference to alternatives like study_agenda or study_plan. The agent must infer from the description alone that this is the deadline-focused view.

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 declare this is a mutation (readOnlyHint=false) with a safe, non-destructive, open-world profile. The description adds real value beyond that: it is asynchronous (returns a job_id), requires polling to completion, and operates through a plugin-owned session. The refresh statement ('checks by a new transfer') is vaguely worded.

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, front-loaded sentences. The list of excluded manual actions is slightly verbose but reinforces the automation contract; the job_id/poll and refresh notes are correctly placed at the end.

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?

No output schema exists, so the description must explain returns; it does by naming the job_id and the polling tool. Safety is covered by annotations. Remaining gaps (error behavior, meaning of 'observed') are minor for a 2-parameter async 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 coverage is 0%, so the description carries the burden. It constrains item_ids to 1..30 observed resources, which is useful, but the refresh semantics are stated opaquely as 'checks by a new transfer', leaving the default-true behavior only partially explained.

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?

Names a specific verb (download) and resource (Learn resources) with batch scope (1..30). It is clear what the tool does, though it does not explicitly differentiate itself from the closely related siblings study_download_resource and study_downloads.

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?

States the automation context (plugin-owned session, no manual URL/browser/screenshot) and gives a concrete follow-up workflow: poll study_school_job for verified paths and checksums. It stops short of stating when to prefer this over the sibling download 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 declare a non-read-only, open-world write, and the description adds real behavioral context beyond that: signed URLs are transient and never persisted, reuse is cached without remote freshness checks, and success yields a verified local file with checksum. It stops short of stating auth/permission requirements or failure modes.

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?

Dense and front-loaded: the primary action leads, followed by the URL-sourcing constraint, persistence caveat, and return/reuse semantics. No sentence is filler, though the block is terse enough to feel clipped on parameter 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?

With no output schema, the description helpfully enumerates return values (local file, checksum, source page) and the caching rule, covering the result side well. The parameter side is left largely undocumented despite five inputs, so the definition is only adequate for a tool of this 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 description coverage is 0% across five parameters, and the description only implicitly covers download_url (the original-file URL) and refresh (the reuse toggle). item_id, filename, and max_megabytes receive no explanation anywhere, so the agent is left guessing their format and effect.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Save an observed Learn resource directly') and contrasts it with the browser Save As workflow, so the agent knows what category of action this is. It does not distinguish this from sibling tools such as study_download_files or study_downloads, which occupy similar space.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a clear condition for use: the resource URL must come from visible link/iframe DOM, not browser Save As. It also explains the reuse/refresh decision rule. It names no sibling alternative, so the agent must infer the boundary against study_download_files itself.

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, destructiveHint=false, and openWorldHint=false, so the safety and idempotency profile is covered. The description adds value by specifying the returned fields (local paths, checksums), which implies there are no side effects on the file system or remote sources. It does not, however, describe any ordering, pagination, or scale limits on the list.

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 wasted words. The returned fields are enumerated efficiently, and there is no preamble 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 read-only listing tool with annotations covering the safety profile and no output schema, the description is close to adequate but has clear gaps: it does not explain the item_id filter, does not state ordering or scope, and does not differentiate the tool from download-oriented siblings. It stops at what the tool returns without saying how to use it.

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 the single parameter 'item_id' is completely undocumented in both the schema and the description. The description does not explain what item_id filters by (a specific course file, folder, or source page) or that omitting it lists everything. This leaves a meaningful gap for an agent trying to scope the list.

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 ('saved course files') with the fields returned (paths, source pages, sizes, SHA-256 checksums). This distinguishes it from download-oriented siblings like study_download_resource and study_download_files by making clear it's a listing of already-downloaded files, though it doesn't name those siblings 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?

Implies usage as a read/list operation of local saved files, but offers no explicit when-to-use guidance or routing to alternatives like study_download_files for initiating downloads or study_read_file for opening a specific file. Adequate but leaves the agent to infer selection.

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 the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. But the description adds little: no mention of what 'dated source text' contains, how pagination terminates, or what happens when offset exceeds available content. 'include_items' effects are implied but not explained.

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, no filler. The clipped style hurts readability slightly but every clause carries information.

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?

A 4-parameter tool with no output schema, no schema descriptions, and no annotations gaps left to the description. The description omits the required parameter entirely, never explains the paging termination condition, and doesn't clarify the relationship to sibling read tools. Inadequate for the 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 0%, so the description must compensate — and it only partially does. It explains next_offset (offset) and include_items, but says nothing about max_chars, the required observation_id, or default behaviors. Two of four parameters are undocumented everywhere.

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 verb ('Read') and resource ('dated source text') with a paging mechanism ('in pages'). But 'source text' is vague against siblings like study_read_file, study_read_resource, study_read_service, and study_collections — it doesn't explain what kind of source this is or how it differs from those read 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?

No when-to-use versus alternatives. The sibling set contains four other 'read' tools, yet nothing routes the agent between them. Only usage hint given is the paging mechanic (continue with next_offset), which is operational, not selection 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=false, openWorldHint=false and destructiveHint=false, so safety direction is partly covered. The description adds real value by clarifying the write target is a local file with no publish/subscribe side effect, but omits whether an existing file is overwritten or appended to, which matters for a defaulted filename like 'edinburgh-study.ics'.

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 zero filler; the positive purpose is front-loaded and the disambiguating constraint follows immediately. Nothing is repeated from the title 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 simple three-parameter local write tool this is close to sufficient, and the no-publish caveat covers the main behavioral risk. Still missing: what the call returns (no output schema exists), the expected date format, and overwrite semantics for the target file.

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% across three parameters, so the description must carry the burden and largely does not. It hints that records come from a deadline/event range and that output is an .ics file, but never states the format of start/end or that filename is the local output path, leaving two required parameters semantically undefined.

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: 'Write observed deadline/event records to a local .ics file.' An agent can tell this exports rather than ingests, which implicitly separates it from sibling study_import_calendar. It stops short of naming that sibling or the agenda/deadlines tools it draws data from, so differentiation is inferable rather than explicit.

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 negative clause 'Does not publish or subscribe any calendar' usefully rules out the network-publishing interpretation an agent might otherwise assume. However, there is no positive when-to-use guidance and no reference to study_import_calendar as the inverse operation, leaving the choice between export/import/agenda 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 readOnly, idempotent, non-destructive and closed-world behavior, so the safety profile is covered structurally. The description does add one useful behavioral fact beyond annotations — that it functions in hosts without skills, resources or prompts — but says nothing about output shape, exhaustiveness, or whether guidance is static or context-dependent.

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

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

Two compact sentences with the topic scope front-loaded and no filler. The style is fragmentary rather than prose, but every clause carries information and nothing is repeated from structured fields.

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 should tell an agent what a help invocation yields, and it does not (guidance text? structured steps? per-topic content?). Combined with zero schema coverage on both parameters, the definition is minimal-but-usable rather than 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 carry parameter meaning. It partially does: "student workflow", "client setup", "language" and "capability" plausibly map to the student/hosts/languages/capabilities enum values. The locale parameter is left entirely unexplained, and the enum-to-phrase mapping is loose enough that an agent must guess which topic selects which guidance.

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 the guidance areas (student workflow, client setup, language, capabilities) but offers no verb and no statement of what the tool actually returns, so the purpose is inferred rather than stated. It is distinguishable from action-oriented siblings like study_task_create or study_read_file only by implication (a help/guidance tool), not by explicit 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?

"On-demand" and "Works in MCP hosts without skills, resources or prompts" imply the context of use (call it when self-service guidance is needed in a host lacking skills/prompts), which is real guidance. However, it never states when to prefer this over siblings, nor any when-not condition, so the guidance stays implied rather than 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, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds genuinely new behavioral context beyond that: the output is a cached overview and can be stale, with a stated mitigation (refresh the relevant service). It does not describe pagination or size limits, but the caching disclosure is meaningful added value.

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, no filler. The contents of the hub are front-loaded and the caching caveat follows it, so an agent gets the substance before the operational nuance.

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 telling the agent what comes back, and it does so by enumerating the four content categories. With no parameters and annotations covering the safety profile, little else is required; only the mechanism for refreshing stale data remains unnamed.

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 and schema coverage is 100%, so there is nothing for the description to compensate for. A 4 is the baseline for a parameterless 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 gives a specific verb ('Show') and a clearly scoped resource ('the personal school hub'), then enumerates what the hub contains: service access coverage, indexed resource counts, saved collections, and outstanding local tasks. That enumeration implicitly separates it from siblings like study_collections or study_tasks, though no sibling is named explicitly, which keeps it just 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?

It implies usage ('show the hub') and gives one useful conditional rule: the view is cached, so refresh the relevant service when current information is requested. However, it never names which tool performs that refresh (study_school_status, study_services, study_read_service), leaving the agent to guess the alternative. Usage is implied rather than routed.

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 establish this writes state (readOnlyHint=false), stays local (openWorldHint=false) and is non-destructive, so the safety bar is pre-covered. The description adds bounded-range and recurrence/exception semantics, but says nothing about duplicate handling, merge vs replace behavior, or whether the import is idempotent — gaps that matter for a write 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 dense, front-loaded sentences with no filler: the core operation and scope come first, then the two disambiguating constraints. Nothing is wasted, though the compression leaves parts of the schema unexplained.

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, 5-required write tool with an empty parameter description coverage and no output schema, the description is thin. An agent still cannot determine the expected date format, the meaning of each source value, or what file_path points at.

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% across 6 parameters, so the description must carry the load and it only explains source_url and the semantics enum. file_path, start/end date format, and the five values of the source enum (learn, myed, timetable, library, university) are left entirely undocumented in both places.

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?

Names a specific verb (Import) and resource (.ics export), and scopes it with a bounded inclusive date range plus recurrence/exception handling. It reads clearly against the sibling study_export_calendar, though the inverse relationship is implied 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?

Gives two real constraints — source_url must be the content page not a secret subscription URL, and semantics=deadlines is only for Learn due-date feeds — which is meaningful guidance. However it never states when to import versus export, nor prerequisites such as having downloaded the .ics first or needing study_connect_school.

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 openWorldHint=true, destructiveHint=false, and readOnlyHint=false, and the description adds useful operational context beyond them: persistent campus session, no host browser, bounded pagination, evidence recording, and job_id return. It does not contradict the annotations, though it does not cover rate limits or auth requirements in depth.

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 delivery mechanism, then quickly covers pagination, return value, polling, and login fallback. Every sentence adds operational value with no 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?

For a job-starting tool with no output schema, the description usefully explains the job_id return and polling follow-up. However, with 0% schema description coverage, it should explain what the query and max_pages parameters control, and it does not.

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% for two parameters. The description never mentions 'query' and only hints at 'max_pages' through the phrase 'bounded pagination,' leaving both parameters largely unexplained.

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: 'Refresh Learn courses' through the plugin's own persistent campus session. It is clear what the tool does, but it does not explicitly distinguish itself from sibling live tools such as study_live_resources or study_live_myed.

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 concrete follow-up guidance: 'poll study_school_job' and 'On needs_login use study_connect_school.' This tells the agent what to do after invocation and on a common failure path, though it does not give explicit when-not-to-use guidance versus sibling 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 declare readOnlyHint=false, openWorldHint=true and destructiveHint=false; the description adds real context beyond them by disclosing the asynchronous job pattern (returns job_id, poll study_school_job) and the possibility of an extra SSO sign-in. This explains why a 'read' tool is not flagged read-only, 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?

Three short sentences, front-loaded with the action and resource, followed by the return value and caveat. No filler, though the 'same dedicated campus profile' phrase is an unexplained reference.

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?

No output schema exists, but the description compensates by naming the return value (job_id) and the polling tool, plus the SSO caveat and the assurance that records are not modified. Only the shape/content of the returned links is left unspecified.

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, and the description adds no parameter detail because none is needed. Baseline for a zero-parameter tool 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?

States a specific verb and resource ('Read MyEd university service links') and names the follow-up sibling study_school_job. However, it does not distinguish itself from close siblings like study_read_service or study_services, so an agent still has to guess which read tool to pick.

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 via 'using the same dedicated campus profile' and the polling instruction for study_school_job. There is no explicit statement of when to choose this over study_read_service, study_services, or study_live_resources.

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 declare readOnlyHint=false and openWorldHint=true, and the description meaningfully supplements them by disclosing the async job_id pattern and the plugin-owned login dependency. It does not contradict the annotations and covers behavior they cannot express.

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?

Dense but front-loaded, with the core action first and the job_id/polling detail immediately after. The trailing coverage-gap sentence is a bit of an outlier but still earns its place as a scope 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?

No output schema exists, and while the description explains that a job_id is returned and how to poll it, it omits the semantics of query and max_folders for a tool with an entirely undocumented schema. Adequate for the async pattern but incomplete on inputs.

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 carry the burden, yet it only clarifies course_id ('native or cached id from course results'). The query and max_folders parameters are never explained, leaving two of three parameters undocumented in both schema and text.

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 ('Find files/documents/assessments') plus the mechanism ('opening a known course and nested folders using DOM'), which distinguishes it from search-oriented siblings like study_search. It does not explicitly name which sibling to prefer, 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?

Gives clear operational context: requires a known course, uses plugin-owned login, and must be followed by polling study_school_job. The clause about explicit coverage gaps hints at when it is not sufficient, but no direct alternative tool is named for those gaps.

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 readOnly, idempotent, non-destructive, and the description reinforces this ('changes no remote calendar'). It adds real behavioral context beyond the annotations: London-time computation, exclusion of cached classes and exact deadlines, defaults treated as explicit assumptions, and that unscheduled work is returned.

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 no filler, front-loading the core action and scope before the behavioral caveats. Nothing 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 no output schema and 6 undocumented parameters, the description should carry more weight than it does. It partially covers return behavior ('Returns unscheduled work') but leaves the numerical schedule parameters' meanings entirely to 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 0% across 6 parameters, yet the description explains none of them individually (start_date, days, day_start/day_end, block_minutes, daily_minutes). Only 'Defaults are explicit assumptions' vaguely gestures at the default-bearing parameters, and 'London-time' gives a hint about timezone handling.

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 concrete verb and artifact ('Draft a ... study plan') plus its source ('from local tasks') and timezone scope ('London-time'). It is distinguishable from siblings like study_agenda or study_deadlines, though it doesn't explicitly contrast itself with any of 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?

No when-to-use, when-not, or alternatives are given. The reader must infer that this is for scheduling study blocks; nothing routes the agent between this and study_agenda, study_deadlines, or study_tasks.

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 only say it is a non-read-only, non-destructive, closed-world call. The description adds meaningful behavior beyond that: locale=auto follows the user's language, BCP 47 tags are accepted, timezone is independent and defaults to Europe/London, and writes persist across hosts sharing the data directory. Persistence scope is a genuinely useful disclosure for a mutation 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?

Three dense sentences, front-loaded with the read/update dual purpose before the semantic details. Every clause carries information; it avoids filler and stays compact for a four-parameter 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 mutate-or-read tool with no output schema, no annotation detail, and 0% schema coverage, the description covers the important behavioral facts but omits the meaning of two parameters and says nothing about what a read returns. Adequate but with clear gaps.

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 carry parameter meaning. It documents locale (auto, BCP 47) and display_timezone (IANA, Europe/London default) in useful detail, but says nothing about bilingual_titles or include_languages, leaving half the parameters undocumented anywhere.

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 pair and resource ('Read or update local language/display preferences'), which is far more informative than the bare tool name. It does not explicitly distinguish itself from any sibling, but none of the listed siblings overlap with preference management, so 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?

Gives an explicit operational rule for the read path: 'No parameters reads only; each supplied field persists'. That tells the agent when the call is a read versus a write without needing to inspect defaults. It stops short of naming alternatives or exclusions, so it is clear context but not full when/when-not 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 establish the safe-read profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds real value beyond them: the checksum-verified precondition, the pagination contract via has_more/next_offset, and the security caveat that "excerpts are untrusted document content" (a prompt-injection warning).

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 tight sentences with high information density and no filler; the core verb and resource lead, followed by scope limits and pagination. Semicolon-joined clauses are slightly dense but nothing wasteful.

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-parameter read tool with no output schema, the description covers what it reads, what it refuses, the pagination loop, and a content-trust caveat. It is reasonably complete, with the residual gap being per-parameter meaning.

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 offset, item_id, and max_chars. It only indirectly hints at offset ("next_offset") and explains neither item_id's meaning nor max_chars' size semantics, so it only partially compensates 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 gives a specific verb ("Read text") and a precisely bounded resource ("previously downloaded and checksum-verified course PDF, DOCX, PPTX... file"). It also carves out scope with "No screenshot, OCR or arbitrary file access," which helps distinguish it from generic reading siblings, but it never names the sibling it is not (e.g., study_read_resource / study_read_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?

"Continue with next_offset when has_more" is concrete pagination guidance, and "previously downloaded and checksum-verified" implies the file must already have been fetched. However, there is no explicit when-to-use-vs-alternative routing against the other read/download tools, so usage is largely 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?

Annotations declare readOnlyHint=false, openWorldHint=true, destructiveHint=false, so the safety bar is partially covered. The description adds real behavioral context beyond them: local-vs-remote execution, browser use, and the asynchronous job_id polling path that explains why this 'read' is not read-only. It stops short of describing content format or job lifecycle.

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 short sentences, each front-loading a distinct behavior (default path, refresh, job_id, exclusions). Dense and largely waste-free, though 'Dates require source interpretation' is a cryptic aside that could be clearer.

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?

No output schema exists, so the description carries the return burden, and it does explain the two return modes (immediate content vs. job_id). However, it leaves item_id resolution, poll cadence, and the shape of returned content unspecified, which is a meaningful gap for a 2-param 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?

With 0% schema description coverage, the description must carry parameter meaning. It does clarify refresh=True (obtain current remote contents vs. default local fast path), but item_id is only obliquely described ('observed Learn page/file') and no format/identifier guidance is given.

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 ('Read an observed Learn page/file'), which is a clear scope. It does not explicitly differentiate itself from close siblings like study_read_file, study_read_service, or study_download_resource, so the 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?

Gives useful context for one mode: verified local files return immediately by default, and refresh=True fetches current remote contents. It also notes 'Does not submit forms' as an implicit exclusion, but it never names alternatives or says when to prefer a sibling reader/downloader instead.

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?

Discloses behavior beyond the annotations: the SSO-session ownership, the job_id polling model, and the side effect of capturing text and links into the central search index (which is consistent with readOnlyHint=false). It does not state permissions or rate/scope limits, but the async and persistence traits are genuinely 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?

Front-loaded with the core action and return contract, then layers the parameter guidance and the negative constraint. Dense but every sentence contributes; no 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?

For a 5-param, no-output-schema tool it covers the return contract (job_id to poll), the SSO context, indexing side effect, and the read-only boundary. The gap is max_pages semantics/default and any indication of job result shape, which the annotations alone do not supply.

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 must carry the load, and it does for most parameters: service_id provenance, item_id as an observed link, query as link selection, and the meaning of the section enum including the euclid/Courses case. It omits max_pages entirely, leaving one of five parameters undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Read a school service') plus the async contract ('returning a job_id to poll') and the SSO mechanism. It is clearly distinguishable from write siblings, though it does not explicitly contrast with other read siblings like study_read_resource or study_collect.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete routing ('Use service ids from study_services', 'For formal enrolments use service_id=euclid and section=Courses') and an explicit exclusion ('Does not submit forms, applications or change school records'). No guidance, however, on when to prefer this over the other read tools in the sibling set.

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=true, idempotentHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds that it returns an official service entry or saved source link for reference, which clarifies the output type, but it does not explain return format, pagination, permissions, or other operational details.

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 only two sentences and is front-loaded with a purpose statement. It avoids clutter, though the second sentence is somewhat cryptic and could be clearer for the space it consumes.

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 two undocumented parameters and no output schema, the description is too thin. It does not explain parameter meanings, expected return shape, or how to choose this tool over the many study_* siblings; the annotations cover safety but not invocation semantics.

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 the description says nothing about the two parameters 'target' and 'item_id'. With no schema documentation and no compensating description, an agent has no guidance on what values are valid or how the parameters affect the result.

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 the verb 'Get' and a resource ('official service entry or saved source link'), but the tool name 'study_route' and the concept of routing remain ambiguous. It does not clearly distinguish itself from siblings such as study_read_service, study_read_resource, or study_live_resources; the reference to 'plugin-owned school tools' is indirect at best.

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 second sentence implies this tool is for reference material rather than live content, and that normal live content reads should use the plugin-owned school tools. However, no specific alternative tool is named, and the phrase 'Normal Work usage' is vague, leaving the agent to infer when this tool is actually 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 cover read-only, idempotent, non-destructive, closed-world behavior. The description adds substantial non-obvious context: the wait window (20s default, 25s max), the suppression mechanism via if_updated_at, the terminal state set, and a security warning that source text is untrusted. Little is missing beyond return-value shape.

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

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

Front-loaded with the core action and wait semantics, then layered usage rules in terse clauses with no filler. Each sentence earns its place, though the telegraphic fragment style trades some readability for density.

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 6 parameters at 0% schema coverage, the description steps in well: terminal states, pagination via next_offset, detail levels, wait limits, and the untrusted-content warning. Gaps remain on limit/offset meaning and the result payload shape, but the agent can 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?

Schema description coverage is 0%, so the description must carry the load. It explains wait_seconds bounds, if_updated_at behavior, detail=full usage, and pagination via next_offset, but leaves limit, offset, and job_id semantics undocumented. Coverage of 6 parameters is partial rather than complete.

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 (wait for) and resource (school-job progress/results) and conveys the polling semantics clearly. It does not name or differentiate itself from nearby siblings like study_status or study_school_status, which prevents 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?

Gives concrete operating instructions: continue polling until complete/partial/needs_login/failed, page with next_offset, use detail=full only when needed, pass if_updated_at to suppress unchanged output. This is clear context and conditional guidance, though no explicit exclusion or alternative routing to sibling status 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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds real value by scoping the data as 'plugin-owned local' and disclosing the absence of host-browser side effects, which annotations do not express.

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 what is read and followed by the key side-effect constraint. No filler, no 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 no-argument, annotation-covered read tool with no output schema, the description supplies enough to invoke it correctly. It stops short of describing the returned session/job state, but with no output schema that is not strictly 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 baseline is 4; there is nothing for the description to disambiguate beyond what the empty schema already shows.

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 (Read) and two concrete resources (the plugin-owned local campus session and background jobs). It is clearly distinguishable from siblings like study_connect_school or study_school_job, though it never explicitly names the alternative or contrasts itself with study_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?

Usage is only implied: read this when you want to inspect local campus session/job state. The negative constraint ('Does not open a host browser') hints at a boundary and implies another tool is needed for browser-opening flows, but no alternative is named and no explicit when/when-not is given.

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 readOnly/idempotent/local safety, so the bar is lower; the description adds genuinely useful behavior the annotations don't cover: default page size of 20 compact rows, offset-based continuation, and the compact-vs-full detail mode. It doesn't state rate limits or empty-result behavior, but it adds real value beyond structured fields.

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 short sentences, each carrying distinct information (scope, default page, continuation, detail mode, live-vs-cached caveat), with the most decision-relevant constraint ('Not live search') positioned prominently. No 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?

With no output schema, the description usefully characterizes the return shape (20 compact rows, next_offset for continuation, full excerpts via detail). It's nearly complete for a read-only search tool; only the filtering semantics of kind and course_id remain uncovered.

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. It explains limit (20 default), offset (next_offset continuation), and detail=full, but says nothing about kind's enum values or course_id filtering, and query is left entirely implicit. Partial compensation for six undocumented 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?

States a specific verb (Search) and resource scope (cached courses/resources/events), and the phrase 'Not live search' explicitly separates it from live siblings like study_live_courses and study_live_resources. An agent can pick it out without opening any 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?

Gives a clear when-not ('Not live search' → use live tools for fresh data) and routes pagination ('continue with next_offset') and the detail=full escalation. It stops short of naming the specific live alternative, so it's strong context rather than fully explicit routing.

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 the safe read-only profile, but the description adds genuinely new behavioral context: results include dated per-service coverage (freshness metadata) and the warning that presence in the list does not imply access. That caveat meaningfully changes how an agent should interpret results, which annotations cannot 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 sentences, front-loaded with the action and resource, with no filler. The long category enumeration is informative rather than wasteful, though it is the bulk of the text and could be trimmed for a tool whose return values carry that 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?

There is no output schema, so the description must carry the return-value burden; it partly does by disclosing dated per-service coverage. But it leaves all three parameters unexplained and does not describe the result shape beyond the category list, leaving gaps for a 3-parameter discovery 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% for three parameters (query, detail enum, locale), and the description mentions none of them — no guidance on search syntax, what compact vs. full returns, or locale behavior. The enumerated service categories describe content, not parameter semantics, so the description fails to compensate 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 gives a specific verb ("List") and a concrete resource ("the central school service directory") with enumerated contents (MyEd, Learn, EUCLID, timetable, library). An agent can tell this is the broad directory-listing tool rather than a reader like study_read_service. It never names those siblings explicitly, so no differentiation credit beyond the resource scoping.

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 implied: this is the directory/discovery surface, and the caveat "an entry alone is not proof of access" hints that a follow-up read step is needed. However, no explicit when-to-use, when-not, or named alternative is given, so the agent must infer the routing.

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 the safety profile (readOnlyHint, idempotentHint, non-destructive, closed-world). The description adds two behavioral details not in annotations: it reads cache freshness and previous authentication observations. It does not describe return shape, staleness semantics, or whether it can trigger a refresh.

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, no waste, but the second sentence is a parameter instruction rather than the front-loaded purpose, so the structure mixes concerns. It is compact but not optimally ordered.

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 30 sibling tools, no output schema, no annotations-backed return info, and a 0%-covered parameter, the description is too thin. It does not explain what the status response contains or when the capabilities flag changes the answer, which an agent needs 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 coverage is 0% for the single boolean parameter, so the schema provides no description at all. The description says what to set it for ('implemented, missing and unverified features') but conveys no default behavior, mutual exclusivity, or effect on output. It partially compensates but leaves the parameter underspecified.

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 resource ('cache freshness and previous authentication observations') with a read verb, which is clearer than a bare name. However, 'study_status' vs 'study_school_status' vs 'study_services' are all status-adjacent siblings and the description gives no hint of how it differs from them. The second sentence shifts to describing a parameter, muddying the stated purpose.

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 statement of when to use this tool, when not to, or which sibling (e.g., study_school_status) to prefer for related status questions. The agent is left to infer usage entirely from the description text.

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=false, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description usefully adds validation constraints (estimate 5..6000, priority 1..5, due_at timezone), but does not explain what 'local' scope means or how duplicates/conflicts are 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?

Three short sentences, front-loaded with the purpose and then the validation rules. No filler, though the priority/due_at notes read slightly like a constraint dump rather than integrated guidance.

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 7 parameters, no output schema, and low schema coverage, the description leaves key semantics open: what item_id links to, how due_date differs from due_at, and whether notes are free-form. For a creation tool this is noticeably under-specified.

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 14%, so the description must carry more weight; it does clarify estimate_minutes bounds, priority range, and the timezone requirement for due_at. However, four parameters (title, notes, item_id, due_date) and the due_at vs due_date distinction remain unexplained, leaving the compensation partial.

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 ('Create a local study task') and adds a distinguishing qualifier about explicit estimated minutes. It is clearly separable from study_task_update and study_tasks, though it does not name those siblings 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?

There is no guidance on when to use this versus study_task_update, study_capture, or study_plan, and no prerequisites or preconditions are stated. The agent must infer usage purely 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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, covering the full safety profile. The description's addition of 'local' corroborates the closed-world hint, but it says nothing about return ordering, pagination, or whether archived tasks require explicit status selection.

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 verb, resource, scope, and filter are all packed in 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 one-parameter read tool with no output schema, the essential action is conveyed and annotations cover safety. Gaps remain around return content (what a task record includes) and how omitted status behaves, which an agent would have to infer.

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 some weight, and it does identify the single parameter as an optional status filter. However, it does not enumerate or explain the valid values (todo/doing/done/archived) or clarify the default behavior when no status is supplied — the enum lives only in 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?

States a specific verb+resource: 'Read local study tasks', with a scoping qualifier ('local') and an optional filter ('by status'). This distinguishes it reasonably well from the write siblings (study_task_create, study_task_update), though it does not explicitly differentiate itself from adjacent read tools like study_search or study_agenda.

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?

'Optionally filtered by status' implies the use case (listing tasks, narrowing by state), but no when-to-use vs. when-not guidance is given, and no alternative is named despite several sibling read tools (study_search, study_agenda, study_status) that could overlap.

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 two facts beyond the annotations: archiving is reversible (consistent with destructiveHint=false) and that 'done' does not mean the task was submitted to Learn, which disambiguates status semantics. It does not cover partial-update behavior, permission needs, or what an update returns.

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, front-loaded sentences with no filler. The behavioral caveat about 'done' is placed immediately after the core action, so nothing is buried.

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 four-parameter mutation tool with no output schema and no annotations covering returns, the description is thin. It never explains that omitted fields are presumably left unchanged, what reverting an archive entails, or how notes and estimate interact with updates.

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% across four parameters, so the description must compensate but largely does not. It only hints at the meaning of the status value 'done'; notes, estimate_minutes, and the other status values (todo/doing/archived) remain unexplained.

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?

State a specific verb (update/archive) and resource (a local task), and explicitly scopes it to 'local' tasks rather than anything synced to Learn. This distinguishes it reasonably well from study_task_create and study_tasks, though no sibling is named directly.

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 word 'Update' implies it acts on an existing task rather than creating one, and the 'done' caveat warns about a misuse case. However, there is no explicit when-to-use guidance, no pointer to sibling tools such as study_task_create for new tasks, and no stated prerequisites for updating.

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