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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=true, so the safety profile is largely covered. The description still adds real behavioral context beyond that: the manual-only restriction on auth fields, the exact accepted key values for press, and the recommendation to defer the export click to campus_export. It omits whether actions are reversible or how page-state staleness is 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?

Four short sentences, front-loaded with the core purpose followed by per-action rules and the sibling routing note. No filler, though the opening sentence is slightly vague compared to the crisp action-specific lines that follow.

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 4-parameter, 0%-schema-coverage automation tool with no output schema, the description covers action semantics and key routing decisions but leaves ref and provider undefined and says nothing about failure behavior or what a successful act 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 partly does: it explains what value means for select and check, and constrains press's value set. However, 'ref' (presumably an element handle obtained from campus_inspect) and 'provider' are never explained, leaving two of four 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?

The description gives a specific verb+resource: operating a visible UI control to choose tables, fields, dates and filters. It distinguishes itself from campus_export by naming that sibling as the tool for the final export click, but the abstract phrasing 'operate a current visible control' leaves the exact mechanism (browser automation on refs) somewhat implicit.

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

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

It gives concrete per-action guidance (select takes an option value, check takes 'true'/'false', press is limited to Enter/Tab/Escape/Arrows/Space) and an explicit exclusion (login/OTP/password fields are manual-only) plus a routing rule to campus_export for provenance. It does not clarify when to choose click versus fill, which is the main remaining ambiguity.

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 say not read-only, not destructive, not idempotent, open-world. The description adds what the annotations cannot: it waits for in-flight downloads and preserves the profile locally, so state survives the close. It is silent on whether anything in the browser session is lost.

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 action and its timing constraint. Every clause (the downloads wait, the profile retention) conveys information an agent could act on.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-enum-parameter lifecycle tool with annotations and no output schema, this covers the timing, the target, and the persistence outcome. What remains unsaid is whether a stuck download blocks the close and what result is returned, which a 4 tolerates.

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?

One required parameter with 0% schema description coverage, but it is a closed enum (csmar, cnrds) carried by the input schema. The description scopes the action to 'a provider browser', which ties the enum to the subject being closed; little else is 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 (close) and resource (a provider browser), names the lifecycle sibling campus_open, and adds the distinguishing condition 'after active downloads finish' plus the profile-retention behavior. An agent can tell it apart from campus_downloads and campus_open immediately.

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

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

The phrase 'after active downloads finish' is an explicit prerequisite and timing condition, so an agent knows not to call it prematurely. It stops short of naming alternatives or saying when not to close, which keeps it at 4.

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 and openWorldHint=true, so safety profile is covered. The description adds valuable context beyond annotations: persistence across restart, and crucially that it reports browser downloads rather than server/provider progress. It does not mention pagination or receipt format, but the added behavioral context is substantive.

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 no wasted phrasing; the scope statement and the 'browser downloads, not provider progress' distinction come early. Slightly fragmented but efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so the description should clarify what receipts contain, but it does not. For a read-only listing tool the safety and scope are adequately conveyed, but with 0% param coverage and no return-value description, it falls short of fully complete.

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

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

Schema description coverage is 0%, so the description must compensate. It explains wait_seconds (wait 0–30 seconds) usefully, but says nothing about the required 'provider' parameter or its enum values (csmar/cnrds), leaving the most important disambiguation 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?

The description states a specific verb and resource: it lists this session's local export receipts, and explicitly scopes it to 'browser downloads, not provider-side export job progress.' However, it does not name the sibling it differs from (e.g., campus_export), leaving the boundary slightly implicit.

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

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

It gives a clear exclusion ('not provider-side export job progress') that helps disambiguate from export-job tools, and hints the wait option. But it does not state when to prefer this over campus_inspect or campus_export, nor when to set wait_seconds versus polling later.

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 significant behavioral details beyond annotations: query_note requirements, wait_seconds range (0–30), async packaging handling (inspect job page or call campus_downloads, don't resubmit), and that files are retained with checksums and provenance manifests but contents are not returned. It also notes that received files need validation. This is rich context, though it doesn't mention permissions or reversibility.

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 main action, then follows with key constraints and caveats. It is reasonably concise, though some sentences (e.g., about validation) could be integrated more tersely.

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 mutation tool with no output schema and incomplete parameter documentation, the description covers important behavioral aspects like async handling and file retention. However, it omits details about provider and ref, and doesn't describe the return value or failure modes. 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?

With schema description coverage at 0%, the description must compensate. It only partially does: query_note semantics are explained ('must document table, fields, filters, date range and format') and wait_seconds range is given (0–30). But provider and ref are not described at all, leaving two of four 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?

The description states a specific action: click the selected export/download button and retain the browser export locally. This is a clear verb+resource, though the phrasing ('selected') implies a prior selection step handled by sibling tools like campus_act or campus_open, which isn't explicitly 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?

It gives clear context for when to use it (clicking the selected export button) and provides alternatives for async packaging: inspect the job page or call campus_downloads instead of resubmitting. It doesn't explicitly list when-not-to-use, but the guidance is strong.

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?

Adds significant context beyond readOnlyHint/openWorldHint: it omits input values, hidden fields, cookies and storage; each call expires older refs; and frames cap at 250 controls with control_offset paging. These are real behavioral traits an agent needs.

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, then organized into omissions, ref expiry, usage caution, and paging. Dense but every sentence contributes; could be slightly tighter.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description covers return contents (text/controls, refs, hints, downloads), exclusions, ref lifecycle, and paging limits. It lacks explicit guidance on ref usage in sibling tools (campus_act), a minor gap.

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 carries the burden. It explains control_offset paging and the 250-control frame limit, and implies provider selects the tab/frame set, though it doesn't detail provider enum effects.

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 visible text and controls across provider tabs and frames. It's distinct from siblings like campus_act (interaction) and campus_export (downloads), though it doesn't explicitly name those distinctions.

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 an inspection/read step within a campus workflow, but doesn't state when to use it versus campus_search or campus_scroll, or prerequisites like having opened a provider.

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, idempotentHint=false, destructiveHint=false. The description adds genuinely new behavioral context: it reuses a dedicated private profile and never touches the everyday browser profile, plus a provider-specific auto-login behavior. That is meaningful disclosure beyond 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?

Short, front-loaded with the primary action, and each sentence carries information (action, URL constraint, profile privacy, login routing). No padding, though the provider routing note is slightly compressed.

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?

Covers the action, the URL constraint, privacy behavior, and login routing, which is adequate for an openWorld non-idempotent browser-launch tool with no output schema. What an agent still lacks is return/state information and explicit handling of what happens if the URL doesn't match the provider.

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 schema itself documents little. The description adds a key constraint ('URL must belong to that provider') and names the two provider contexts, which gives the provider enum real meaning. However, the 'url' parameter's purpose and format remain largely implicit.

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

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

States a specific verb and resource: 'Open the local provider browser'. An agent can identify the action clearly. It does not explicitly contrast itself with siblings like campus_school_login beyond a passing hint, so it falls short of full sibling 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?

Provides concrete routing guidance: CSMAR may auto-login on campus, and for CNRDS the agent should use campus_school_login instead. This names an alternative and a condition. It doesn't cover the full set of siblings or when-not-to-use cases, so not a 5.

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

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

Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false. The description adds meaningful context beyond them: the click is performed 'without credentials' and will not attempt hidden auth endpoints or force an unavailable login, which reassures the agent this is a bounded, non-destructive interaction. It omits what happens on success/failure and any rate or IP-requirement detail.

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

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

Three short sentences, front-loaded with the core action and followed by what it does not do. No filler, though the third sentence (IP diagnostic) is the least essential and slightly loose in placement.

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 tool with annotations covering the safety profile and no output schema, the description covers the action and its non-goals adequately. The gap is the undocumented provider parameter and no guidance on failure handling, so it is only minimum-viable.

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 never mentions the single required 'provider' parameter or explains its enum values (csmar, cnrds). The enum is self-describing but the description adds no meaning about what provider selects or how it maps to the visible login button.

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: 'Click a unique visible school/institution login button, without credentials.' An agent can tell this is a campus login action distinct from open/inspect/search. It stops short of naming which sibling to prefer when a login button is absent, so no explicit sibling 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?

Usage is implied rather than stated: it clarifies it will not guess hidden endpoints or force login, and offers a diagnostic ('missing button outside campus often means the user's IP was not recognized'). This helps the agent interpret failure, but it never says when to use this vs. campus_act or another sibling, nor what to do on failure.

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

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

Annotations already disclose readOnlyHint=false, idempotentHint=false, and openWorldHint=true, so the mutation/idempotency profile is covered. The description adds one genuinely useful behavioral detail — that it can reach controls inside an embedded frame — but says nothing about timing, scrolling failure, or how the ref is resolved.

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. It is efficient, though the terseness leaves required context out rather than being 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 2-parameter tool with no output schema and 0% schema coverage, the description should at least explain the ref/provider pair and any session requirement. Instead it covers only the action and the frame case, leaving the invocation details incomplete.

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 and fails: 'ref' and 'provider' are never explained. Only a weak implication that 'ref' identifies the control to scroll, and no hint that 'provider' selects a session (csmar/cnrds) 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 (scroll) and resource (a visible control into view), plus a distinctive scope note about embedded frames. It differentiates itself from siblings like campus_open, campus_inspect, and campus_close, though it doesn't name them.

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

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

There is no guidance on when to scroll versus using another tool, nor any mention of prerequisites (e.g., that the element must exist or that a provider session is required). The agent must infer that this is needed when a target is off-screen.

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=true, idempotentHint=false, and destructiveHint=false. The description adds real operational context beyond those: it auto-detects a single input, falls back to Enter submission, and warns that results may load asynchronously requiring re-inspection. It stops short of describing prerequisites such as login state or what happens when multiple candidate inputs exist.

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?

Roughly four short sentences, front-loaded with the core action followed by the fallback and the async caveat. No filler, though the input-detection mechanics occupy more space than the primary search semantics.

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 non-idempotent, open-world tool with no output schema and zero schema description coverage, the description covers the fallback invocation path and the async-results caveat well, so nothing about calling it correctly is missing. It omits provider semantics and any login/session prerequisite implied by the campus_school_login sibling.

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 4 parameters, so the description carries the burden and does explain the two optional refs ('from the same latest inspection', 'if ambiguous'). However, the required 'keyword' and the 'provider' enum (csmar/cnrds) are never mentioned, leaving half the interface undocumented in both schema and prose.

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

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

States a specific verb and resource ('Search the currently visible catalogue using its website search box'), which is meaningfully distinct from siblings like campus_scroll, campus_act, and campus_inspect. It does not explicitly name or contrast a sibling, but the scope ('currently visible catalogue') makes the intended object of the search unambiguous.

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

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

Usage is implied rather than stated: use it when you need the site's own search box. It gives useful invocation branching (auto-detect vs. pass input_ref/submit_ref) and implicitly routes to campus_inspect via 'inspect again when needed', but there is no explicit when-to-use vs. when-not or named alternative.

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