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

With no annotations, the description must disclose safety and mutation behavior, but it does not state whether booking is read-only, creates or changes records, requires additional permissions, or returns URLs versus data. The per-lab constraint is useful but insufficient for a booking-related 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?

The description is two sentences and front-loads the booking-resource locations before the lab prerequisite. It is reasonably tight, though the phrase 'opening another lab's scope' is somewhat vague.

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 annotations, no output schema, and an undocumented single parameter, the description should clarify the return behavior and parameter format. It provides useful resource and lab context but leaves core operational details missing.

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

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

The only parameter, id_or_name, has 0% schema description coverage and is not explained in the description. The description says 'item' but does not clarify whether the value should be an item ID, name, URL, or something else.

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 says where to book an item and names three resources: its page, the SharePoint list behind it, and the booking directory. However, it is unclear whether the tool returns booking locations, opens a booking UI, or performs the booking itself, and it does not clearly distinguish itself from siblings such as ipa_page, ipa_item, or ipa_open.

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 one useful prerequisite: confirm the user's lab via ipa_status before opening another lab's scope. It does not say when to use this tool instead of related siblings like ipa_page or ipa_item, so usage is only implied.

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

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

With no annotations at all, the description carries the full burden and does not disclose read-only vs mutating behavior, scope of results, pagination, or any permission requirements. The one behavioral signal is the implicit 'read' framing, but the enumerated return fields (title, summary, URL, source repository) duplicate what the existing output schema already provides.

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?

Very short and front-loads the resource scope, then the kind values. The first clause is a noun fragment rather than a statement of action, and the parenthetical '(interactive HTML in the library)' adds modest value, but nothing is bloated.

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?

An output schema exists, so the description needn't explain return structure, and with one optional parameter the surface is small. Still missing: whether results are the complete library or filtered, and how this differs from the many sibling retrieval tools — an agent could easily pick the wrong 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% and the schema types kind as an unconstrained string with no enum, so the description's 'kind: course | presentation | viewer' is the only place the valid values appear — genuine added meaning. It doesn't say whether omission returns all kinds, which keeps it short of a 5.

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 resource precisely (courses, presentations, viewers as interactive HTML in the library) and enumerates the kind categories, which distinguishes it from generic siblings. However, it never states the action — no verb like 'list' or 'retrieve' — so the agent must infer that this returns build records rather than doing something to them. No sibling (ipa_search, ipa_find, ipa_item, ipa_page) is referenced to disambiguate.

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 indication of when to use this tool instead of ipa_search, ipa_find or ipa_item, all of which plausibly retrieve similar library content. The kind enumeration hints at a filtering use case but the description never says whether kind is required in practice or what happens when it is omitted (list everything?).

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

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

With no annotations at all, the description carries the burden; "Every item on the site" implies a read-only enumeration, but read-only status, result-set size, and pagination behavior are never stated. The enumeration of returned fields partially duplicates the output schema instead of adding behavioral context like whether hidden/unbookable equipment is excluded.

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 tight sentences, front-loaded with what the tool returns, followed by the filter mechanic. The field enumeration is slightly listy, but nothing is filler and the essential information lands first.

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?

An output schema exists, so the returned-field list is a bonus rather than a necessity, and the tool is only two optional params. An agent can call it correctly; the only real gap is the unspecified lab identifier format and kind vocabulary, which matters given 0% schema coverage.

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

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

Schema description coverage is 0%, so the description must compensate for both params — and it does only partly: it names both filters and illustrates kind with 'scope', but never says whether lab is a name, id, or alias, whether matching is exact or substring, or what the full set of kind values is.

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 resource concretely ("Every item on the site") and grounds it with examples — microscopes tagged kind 'scope', hoods, VM desktops — plus the fields returned. It's clearly a bulk listing rather than a lookup, though it doesn't name a sibling like ipa_item or ipa_search to contrast with.

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?

"Filter by lab and/or kind" implies the intended usage pattern, and the 'scope' example shows how kind is used in practice. There is no explicit when-to-use-this-vs-ipa_item/ipa_search guidance and no statement that results are unfiltered when both params are omitted.

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

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

With no annotations at all, the description carries the full burden: it conveys that this is a non-mutating listing, discloses the returned attributes (including OneDrive download state, which is non-obvious), and warns that raw acquisitions are large so listing should precede reading. It omits auth/permission needs and pagination behavior, which are the remaining gaps.

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 the folder forms, with the operational caution appended. No filler; every clause adds either path syntax or usage 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?

An output schema exists, so return values need no further explanation, and the description covers path syntax and the read-cost tradeoff for a 2-parameter tool. The only real hole is the undocumented `max_files` cap, which matters for folders with many raw files.

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 does well for `folder` by giving three literal path shapes ('data/equipment/<id>', 'data/psf/<session>/raw', 'data/laser-power'). However `max_files` (default 200) is never mentioned in the description or schema, leaving one of two 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 and resource ("List the files of a library folder") and backs it with three concrete folder-path examples plus the exact fields returned (size, URL, OneDrive download status). An agent can immediately tell this is a folder-listing operation, distinct from search/find-style siblings like ipa_search or ipa_find.

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?

"Raw acquisitions are large: list before reading, and read only what is needed" gives explicit sequencing and cost guidance for using this before a read tool. It stops short of naming an alternative tool (e.g. ipa_item / ipa_page) or stating exclusions, so it is clear context rather than full when/when-not 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?

With no annotations, the description carries the burden, and it does disclose useful traits: results are ranked candidates, ties are broken by the user's lab, and there is a cross-tool dependency on ipa_status. It does not state that the operation is read-only, whether it searches across all labs or only the current one, or what happens on zero matches.

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 lines, front-loaded with the question the tool answers, then examples, then the tie-break rule and the escalation rule. Every element earns its place 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?

For a one-parameter lookup with no output schema, the description covers what comes back (ranked candidates), how ranking is influenced, and how to resolve multi-lab ambiguity. The main residual gap is failure behavior when nothing matches, which an agent would need before calling.

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% on the single 'query' parameter, so the description must compensate, and it does with concrete example inputs ('the spinning disc', 'the Nikon scope', 'Dobby') that reveal the field takes loose natural-language descriptions rather than IDs or exact names. It stops short of specifying matching rules (substring vs fuzzy, aliases).

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 frames a specific job: resolving a vague user reference ('the spinning disc', 'Dobby') into ranked item candidates, which is a clear verb+resource in effect. It never names the sibling it is not (notably ipa_search and ipa_item), so an agent must infer whether to use this or the search tool.

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 real procedural guidance for the ambiguous case: consult ipa_status for the user's lab, use the lab to break ties, and ask the user rather than guessing when multiple labs match. However, there is no explicit statement of when to reach for ipa_find versus ipa_search/ipa_item, which is the primary routing decision an agent faces.

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

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

With no annotations at all, the description carries the full burden and does substantial work: it discloses this is a read operation and precisely what content comes back, including that immersion/NA are parsed from the tag and that PSF is per-objective and laser power per-line. It omits not-found/error behavior and whether name lookups can be ambiguous, which for a zero-annotation tool is the remaining gap.

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 payoff ('everything the site knows about one item') before the field enumeration, and the sibling routing sentence is placed last where it belongs. The parenthetical field list is long but each element tells the agent something about coverage, so it largely earns its length.

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 enumeration of returned sections effectively substitutes for one and is complete enough for an agent to decide whether this tool answers its question. The missing piece is identifier handling for the sole required parameter and failure behavior, which matters for a lookup-by-name 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% and the single parameter id_or_name is never mentioned in the description. The agent gets no hint whether an ID or a display name is expected, how names are normalized, or what happens if the name is ambiguous — arguably the most important ambiguity for a lookup 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?

States a specific retrieval: 'Everything the site knows about one item, structured', then enumerates the exact resource sub-types returned (objectives, light paths, laser lines, outline, booking, measurements). It explicitly contrasts itself with the sibling ipa_page ('for the prose'), so an agent can distinguish the structured-record tool from the prose tool without opening a 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?

It gives one clear routing rule: use ipa_page when you want prose, ipa_item when you want structured data. However no guidance is offered on when to prefer ipa_item over the many overlapping siblings (ipa_equipment, ipa_psf, ipa_laser_power, ipa_find, ipa_search), even though the description implies this tool aggregates the same measurements those siblings cover. Usage is implied rather than stated.

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

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

With no annotations, the description carries the full burden and does well: it discloses the returned fields (dated measurements plus deltas since first and previous), the empty-state behaviour (explicitly reports nothing measured, then gives the protocol and a contact), and the analytical caveat that cross-light-path comparison is invalid. It does not mention permissions or response size, which keeps it short of a 5.

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

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

The core content — what is returned and how deltas are computed — is front-loaded, and every later sentence adds usable information (the scope id source, the empty case, the light-path caveat). Slightly loose phrasing ('says so and gives the protocol and whom to ask') costs a little, but there is 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 three-parameter read tool with no output schema and no annotations, the description is unusually complete: it covers output contents, delta semantics, empty results, and the id source for scope. The remaining gap is the unaddressed optionality of all parameters, which matters given a null default on scope.

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 that 'scope' is an id from ipa_find, and implicitly covers line_nm and path via 'laser line' and 'light path'. However, it never maps these terms explicitly to the parameter names, never states units or format for line_nm, and says nothing about the fact that all three parameters are optional and default to null.

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 specific quantity (laser power at the sample), the breakdown dimensions (scope, laser line, light path), and the shape of the result (every measurement by date with per-cent deltas). It is clearly a measurements-retrieval tool and does not overlap with siblings like ipa_psf or ipa_status, though it never states an explicit verb such as 'return' or 'list'.

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 supplies one concrete prerequisite — the scope must be an id obtained from ipa_find — and warns that comparisons are only valid within a single light path, which is real usage context. It gives no guidance on the case where scope is omitted (all three parameters are optional with null defaults), nor states when the tool should be preferred over other measurement endpoints.

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

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

No annotations, so the description carries the full burden. It does disclose two real behavioral facts: the action targets the user's actual browser (a client-side side effect) and only site URLs are accepted (a validation constraint). It says nothing about what happens on a rejected URL, whether a new tab/window is opened, or what the call 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 sentences with the core action front-loaded and the input restriction immediately after. Nothing is padded, though the second sentence could be tightened to name the exact accepted URL form.

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

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

For a one-parameter, no-output-schema, no-annotation tool this is close to adequate: the effect and the input constraint are both stated. It stops short of telling an agent how to construct a valid URL for a booking or file, or what to expect when the URL is refused.

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% — the single 'url' property is an untyped string with no description. The sentence 'Only URLs of the site are accepted' is the only constraint on that parameter, and it leaves open whether relative paths, absolute URLs, or specific booking/file URL formats are valid.

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 ('Open') plus the three resource types it accepts (site page, booking list, library file) and the destination ('the user's browser'). An agent can picture the effect without opening the schema, though it doesn't explicitly distinguish itself from siblings like ipa_page or ipa_files.

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 'in the user's browser' implies this is for handing a resource to the human to view rather than fetching data programmatically, which is useful implicit routing. But no sibling is named as an alternative and there is no explicit when-to-use/when-not-to-use statement.

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

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

With no annotations, the description carries the full burden, and it does disclose meaningful behavior: output is Markdown, reads are truncated on long pages to an outline plus the first part, and section fetches return the remainder. It omits what happens on an unknown page id or a non-matching section title, and never mentions max_chars truncation, so the failure and truncation contract is only half covered.

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-loads verb, resource, and format, then moves to parameter examples and the long-page behavior in a compact block. Three sentences with little waste; only the trailing 'cite the page's URL' instruction slightly stretches the boundary into usage policy, but it is short and actionable.

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

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

For a 3-parameter tool with no annotations and no output schema, the description covers the read semantics and truncation model reasonably well. The unexplained max_chars parameter and the absent error behavior (invalid id, unknown section) leave gaps an agent would likely hit on first use.

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

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

Schema coverage is 0%, so the description must compensate: it explains 'name' as a page id with four examples and 'section' as a section title with three examples, which genuinely adds meaning. The third parameter, max_chars, is never mentioned, leaving a documented gap against the 0% baseline.

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 a page of the site (Markdown)') and grounds it with concrete id examples ('dudin_scope_sdc-nikon', 'lab-vms'). It does not, however, differentiate itself from plausible siblings like ipa_item or ipa_open, so an agent still has to infer 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?

Gives real usage guidance for the optional section parameter — 'A long page without a section gives its outline and the first part; ask for sections to read the rest' — which tells the agent how to iterate. But it never says when to prefer this over sibling tools (ipa_item, ipa_open, ipa_search) or when not to use it, so the routing decision is left implicit.

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

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

With no annotations, the description carries the full burden, and it does disclose two genuine behavioral traits: results are ordered 'Newest first' and an empty result set produces a specific fallback (protocol plus whom to ask). It never states that the operation is read-only, what permissions or access scope are needed, or how many sessions are 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?

The resource is front-loaded in the first two words, with returned fields, ordering, and the empty-state behavior following in compact parenthetical clauses. Dense but every clause carries information; only the inline 'for deconvolution' aside is slightly 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?

Return content is described thoroughly enough that the absence of an output schema is tolerable, and the empty-state behavior is covered. But with three undocumented parameters, no annotations, and no clarification of the 'path' argument, an agent still lacks what it needs to construct a correct filtered call.

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

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

Schema coverage is 0% and all three parameters are bare titles, so the description must compensate — it partially does by indicating that scope and objective act as filters and by giving a concrete objective tag example ('100x-146-oil'). However, the 'path' parameter is never explained and is easily confused with the output field 'local path of each channel's PSF image', leaving one of three parameters genuinely ambiguous.

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 enumerates exactly what the tool yields — per-session FWHM in x/y/z per channel versus expected, chromatic shift, and the local PSF image paths — which makes the resource unmistakable even though no verb is stated. It does not differentiate itself from similarly named siblings such as ipa_laser_power or ipa_equipment, so an agent must infer the boundary from domain nouns alone.

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 parenthetical 'for deconvolution' hints at the downstream use case, and the mention of filtering context (scope, objective tag, date) implies a lookup workflow, but there is no explicit when-to-use, when-not-to-use, or named alternative among the twelve siblings. Usage is inferable rather than stated.

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

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

No annotations exist, so the description bears the full disclosure burden. It usefully discloses match semantics (regular expression, case-insensitive) and the shape of each hit (page, nearest heading, line), but says nothing about behavior on invalid regex, result truncation, or search cost/limits across 'every page'.

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, zero filler. Scope and match semantics are front-loaded before the illustrative examples, and every clause carries information an agent can 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?

An output schema exists, so the hit fields need not be fully explained. Still, for a 0%-coverage two-parameter tool, the description omits result-count limiting behavior and failure modes, leaving gaps an agent would hit on invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It does clarify that 'pattern' is a case-insensitive regular expression, which is real added meaning, but 'max_hits' (default 40) is never mentioned, leaving truncation behavior 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 and resource ('Search every page and the measurement READMEs') with an explicit scope, which is more than most siblings convey. It does not differentiate itself from sibling lookup tools such as ipa_find or ipa_page, so an agent must infer the boundary.

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

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

Concrete example queries ('is napari installed', 'TeamViewer', 'correction collar', a filter name, a software version) imply when this tool is appropriate. However, it never states when not to use it or names an alternative like ipa_find, so the routing decision against siblings is left to inference.

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

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

With no annotations, the description carries the full burden, and it does disclose that this writes persistent state ("Remember") and that it should be invoked once after asking the user. It does not say what happens on a repeat call (overwrite vs. merge) or what omitting an optional field does — all three parameters are nullable with default null, so an agent cannot tell whether null clears a stored value or leaves it untouched.

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 the identity purpose front-loaded and the conditional library caveat second; nothing is padded. The line-wrapped parenthetical is slightly awkward but costs no comprehension.

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 and no annotations, but the operation is simple (three optional scalar fields). The description covers what to store and when, yet leaves the nullable-parameter semantics and repeat-call behavior undefined, which are the two things an agent is most likely to get wrong on a persistence tool.

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

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

Schema description coverage is 0%, so the description must compensate. It does real work for `lab` by enumerating the accepted values (Aumeier, Dudin, Kaksonen, Kruse, Roux, other) that the schema lacks as an enum, and it glosses `library` as the synced library location. `name` is only implied by the tool name, and no format or path expectation is given for `library`.

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: persist the current user's identity (name, lab) and, if auto-detection failed, their synced library location. The parenthetical enumerates the concrete fields it handles, so an agent knows exactly what gets stored. It does not differentiate from siblings, but no sibling plausibly overlaps with a user-profile setter.

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?

"Ask the user once, then call this" gives explicit timing and a one-shot discipline, and "if auto-detection failed" gives a clear condition for supplying the library. No alternative tool is named, but there is no competing candidate among the siblings for this operation.

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

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

With no annotations, the description carries the full burden and does well: it discloses the returned diagnostics and, importantly, that it surfaces remediation/setup steps when the library is missing. The read-only nature is strongly implied by a zero-parameter status check but never stated outright, and no auth or cost notes are given, keeping it at a 4.

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 diagnostic purpose and followed by the call-first rule. The interrogative phrasing is slightly less crisp than a declarative statement but wastes no words and each clause earns its place.

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

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

For a zero-param, no-output-schema tool, the description supplies enough: what is checked, when to call it, and what it offers on failure. It never states the return shape beyond the three facts, but with no output schema that is a minor gap rather than a blocking one.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline is 4. No argument syntax is needed and none is provided, which is correct.

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 three questions enumerate exactly what the tool reports: library presence, sync freshness, and current user identity. The verb is implicit ('check status'), but the resource and returned facts are unambiguous and distinct from siblings like ipa_find or ipa_search. It stops short of explicitly naming a sibling it is not, so it is a 4 rather than 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?

'Call first when anything fails' is explicit, actionable when-to-use guidance that an agent can follow without inference. It also covers the missing-library case and says the tool supplies setup steps. It does not name alternatives or exclusions, so it falls short of the 5 bar.

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