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

With no annotations, the description carries the full behavioral burden. It discloses the return value (a saved file path), but says nothing about side effects (writing a file to ./screenshots or outputPath), whether a browser session must already exist, navigation behavior, or failure/timeout handling — all of which matter for a 17-parameter capture 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 front-loaded sentences with zero filler: the action first, the return value second. Nothing is repeated from the 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?

The description is terse but functional: the schema is fully self-documenting and the description fills the one gap structured fields can't (the return value, since there is no output schema). Since the purpose is narrow and the action is obvious, this level of detail is sufficient.

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

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

Schema description coverage is 100% and all 17 parameters (including defaults, enums, and interactions like quality being JPEG-only) are documented in the schema. The description adds no parameter meaning beyond that, so the baseline 3 applies.

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

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

States a specific verb and resource ('Capture a screenshot of a webpage or current page') and notes the return value (path to saved file). It does not differentiate itself from siblings like open_browser or list_screenshots, so an agent can't tell from the description alone when this is the right entry point.

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 or when-not-to-use guidance is given, and no sibling is named as an alternative. The only contextual hint ('optional if page already loaded') lives in the url schema entry, not in the description, and it is not surfaced as guidance for choosing this tool over open_browser.

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

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

No annotations are provided, so the description carries the full disclosure burden. 'Close' implies termination, but it doesn't state whether the session is destroyed permanently, whether cookies/state are lost, whether the call is idempotent, or what happens to in-flight work. This is a meaningful gap for an irreversible-feeling operation.

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

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

One front-loaded sentence with zero padding. It is arguably too terse given the lack of annotations, but nothing in it 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?

The tool has one optional parameter (required=0), no annotations, and no output schema, yet the description says nothing about what omitting sessionId does or what is returned on success or failure. For a session-terminating tool, that leaves real behavioral questions unanswered.

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

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

Schema coverage is 100% and the single sessionId parameter is fully described in the schema, so the baseline is 3. The description adds nothing beyond the schema, which is acceptable given the schema does the work.

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 clear verb ('Close') and resource ('browser session'), which is unambiguous and pairs naturally with the sibling open_browser. It does not explicitly differentiate itself from siblings, but the operation is specific enough that an agent can select it correctly.

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 close a session versus leaving it open, no mention of cleanup semantics, and no note about what happens if the session is reused. The agent must infer usage entirely 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?

With no annotations, the description carries the full burden; it does disclose meaningful behavior — the write destination (UI_LIBRARY_DIR, default ~/.ui-library) and that already-downloaded and paywalled screens are skipped. It omits whether existing content is overwritten, whether authentication/network access is required, and what happens on partial failure, leaving a significant gap for a mutating 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?

A single dense sentence with the destination and default front-loaded in a parenthetical, followed by the two selection modes and the skip behavior. No filler; every 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 4-parameter, no-output-schema tool, the description covers destination, selection modes, and skip semantics adequately. Minor gaps remain around return values (count, paths) and how source selection interacts with appId/query, but nothing critical to correct invocation is missing.

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

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

Schema coverage is 50% (limit and source have descriptions; appId and query do not). The description adds real meaning by distinguishing appId ('every screen of an appId') from query ('the results of a query'), but says nothing about the source enum or the limit default, so it only partially compensates.

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

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

States a specific verb (download) and resource (screens into the local UI library) and spells out the two selection modes: all screens of an appId, or query results. It is clearly distinct from read-only siblings like search_ui/get_ui_screens, but it never names those alternatives explicitly, keeping it short of a 5.

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

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

The 'appId vs query' phrasing implies which mode to use for which need, and the skip rules imply idempotent re-runs are safe. However, there is no explicit guidance about when to call this versus search_ui, library_search, or get_ui_screens, 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?

With no annotations, the description carries the full behavioral burden. It does disclose the return contents (image URLs and tags), but says nothing about pagination semantics despite a 'page' parameter, nor about result limits, auth, or whether results are cached/stale — all relevant for a listing 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?

A single sentence with zero filler; the resource, its scope, the payload, and the prerequisite are all front-loaded. Nothing repeats the name or title.

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

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

There is no output schema, so the description's brief mention of image URLs and tags is the only return-value signal, which is thin for a paginated list. An agent must guess at page sizes, ordering, and whether further pages are needed.

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?

At 67% schema coverage, the description adds real value by documenting the provenance of appId (must come from search_ui), which the schema leaves bare. The 'page' parameter's behavior and ordering are left to the schema, which only says '1-based (default 1)'.

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+resource: 'List the screens of one app/site', with scope narrowed to a single app/site and the payload previewed (image URLs, tags). It hints at its relationship to search_ui by naming where appId comes from, though it doesn't differentiate from download_ui or library_search, which also touch screen content.

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

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

The parenthetical '(appId from search_ui results)' supplies an explicit prerequisite and call ordering, which is the key usage fact for this tool. It stops short of stating when not to use it or which sibling to prefer for downloading vs. listing screens.

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

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

With no annotations, the description carries the full burden; it does disclose the non-obvious behavior that matching happens against folders, file names, and saved metadata (app, tags, source). It says nothing about matching semantics (whether multiple words are ANDed or ORed), result ordering, or whether search is case-insensitive, which matters for a word-based search.

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 and scope come first. It is appropriately sized for a two-parameter read tool, though the compactness contributes to the missing guidance noted elsewhere.

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

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

For a simple read-only search with two parameters and no output schema, the description covers what is searched but omits matching semantics and result ordering. Adequate to invoke correctly, but an agent would need to experiment to predict 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 coverage is 50%: limit is documented in the schema, but query has no description. The description compensates by explaining that query terms are matched against folders, file names, and metadata, which is real added meaning. It still doesn't clarify multi-word behavior or whether limit truncates results silently.

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 (local UI library) and scopes the match targets to folders, file names, and saved metadata. The only gap is that the sibling search_ui is never mentioned, so an agent cannot tell from the description alone which search tool 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?

Usage is implied by the description — you use it to find items in the local library — but there is no explicit when-to-use, no exclusions, and no routing to search_ui, which is a near-identical sibling name. An agent must infer the boundary.

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 it discloses almost nothing behavioral: not whether it is read-only, whether it scans the filesystem or a database, or how expensive the call is. It does imply the result is grouped counts per folder, which is the one piece of behavioral context present.

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

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

One short sentence, front-loaded with the verb, and every word contributes. The compound "source/app folder" is slightly ambiguous about whether those are two distinct groupings, which keeps it from a 5.

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 annotations and no output schema, the description should say more about the return shape (key naming, whether counts are totals or nested) and whether the operation is safe/repeatable. It is minimally adequate for a zero-argument utility but leaves the agent guessing about the response structure.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. Nothing in the text contradicts or confuses the empty schema.

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

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

A specific verb ("Count") and resource ("images in the local UI library") with the grouping dimension ("per source/app folder") stated. That separates it from library_search (find images) and ui_sources (list sources), though it never names a sibling to make the distinction 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?

There is no statement of when to call this versus library_search or ui_sources, and no prerequisites or exclusions. The only implicit cue is "local UI library", which hints at scope but gives no routing guidance.

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

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

With no annotations provided, the description carries the full behavioral burden and does not meet it. It doesn't disclose whether listing is recursive, whether it errors on a missing directory, whether results are sorted or paginated, or what a returned entry looks like.

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 short sentence with no filler and the resource front-loaded. It is efficient, though it is arguably too terse rather than over-long, so it doesn't earn a 5.

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-optional-param read tool with a fully described schema and no output schema, this is minimally adequate. Missing return-value shape (filenames vs. full paths) and error behavior on a nonexistent directory are the notable 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 100% with one optional parameter whose schema description already gives the default ('./screenshots'). The phrase 'output directory' adds only a mild framing hint that the default is the tool's own output location, so this lands at the 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 ('List all screenshots') with a location qualifier ('in the output directory'), so the agent knows exactly what operation it performs. However, it never distinguishes this from siblings like get_ui_screens or capture_screenshot, which an agent could reasonably confuse it 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?

There is no statement of when to use this versus alternatives — nothing says to call it before capture_screenshot to check existing files or instead of get_ui_screens. The only implied guidance is that it reads a directory, which the agent must infer 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?

No annotations exist, so the description carries the full burden. It does disclose a genuinely behavioral fact the schema cannot convey — that a page ID is returned for later screenshots — establishing session state. However, it says nothing about browser lifecycle (must it be closed?), whether multiple browsers can be open concurrently, or resource cost, which are the main behavioral risks for a stateful 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 short sentences, front-loaded with the action and followed by the return value. Nothing is redundant and 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?

For a 12-parameter, no-annotation, no-output-schema tool, the description does cover the essential return contract and points at the next step. The remaining gap is lifecycle guidance (closing the browser, whether the page persists), which the agent must infer from sibling names alone.

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

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

Schema description coverage is 100%, so all 12 parameters (including defaults, enums, and timeout capture behavior) are already documented in the schema. The description adds no parameter meaning beyond that, so the baseline 3 applies.

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

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

States a specific verb and resource ('Open a browser and navigate to a URL') and hints at its place in the workflow by returning a page ID 'for subsequent screenshots'. It does not explicitly name the sibling it hands off to (capture_screenshot) or the cleanup counterpart (close_browser), so sibling differentiation is only implied.

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: the phrase 'for subsequent screenshots' suggests this is the setup step before capture_screenshot, but the description never states when to use this versus alternatives, or that a session must be closed afterwards with close_browser. No exclusions or prerequisites are 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?

With no annotations at all, the description carries the full burden, and it does disclose the important behavioral fact that result type varies by source (screens vs. apps). It says nothing about pagination behavior, result limits, or rate constraints, which matter for a search tool, so the disclosure is partial rather than complete.

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 dense sentence with the search action front-loaded and the downstream tooling named last, in the order an agent needs it. It is packed tight with semicolons but nothing is wasted or redundant.

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, no-annotation, no-output-schema tool, the description covers the crucial unknowns: what the tool operates on, how output shape depends on source, and where the results feed next. An agent can invoke it correctly armed only with this text plus the schema.

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

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

Schema coverage is 67%, and the description compensates by grouping the enum values by return kind — refero-*/dribbble yield screens, screensdesign and mobbin-* yield apps — which adds real meaning the schema enum list alone does not convey. The page parameter is documented in the schema and needs no further explanation.

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 a UI library source") and immediately characterizes what comes back, which is unusual and useful. It does not distinguish itself from sibling library_search or ui_sources, so an agent cannot tell from the description alone which of the two search-ish 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?

Gives strong downstream routing — "pass an app's appId to get_ui_screens or download_ui" — so the agent knows what to do after a result. However, there is no statement of when to choose search_ui over library_search or ui_sources, and no 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?

With no annotations, the description carries the full burden, and it does disclose one important trait: check=true triggers a live search per source. It omits cost/latency implications, whether failing sources cause errors or are just flagged, and what the unchecked listing contains.

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

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

One compact sentence with no waste, and the base behavior is front-loaded ahead of the optional mode. The semicolon construction is dense but readable; a touch more spacing would help without adding 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?

For a simple one-parameter tool with no annotations and no output schema, the description covers the core behavior and the mode switch. It leaves return shape ambiguous (a list of sources vs., with check, per-source status) and says nothing about failure handling, so it is adequate 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 coverage is 0%, so the description must compensate for the single parameter, and it does: it explains that check=true performs a live search and changes the response to a health report. The default value (presumably false) is not stated, which is the only 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 and resource: 'List the UI library sources'. It also discloses the dual mode (listing vs. live verification), which separates it from pure search siblings like library_search and search_ui, though it never names 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?

It states the condition for setting check=true ('run a live search ... to report which ones work right now'), which implies a health-check use case. It does not say when to prefer this over library_search or search_ui, nor when check should be left off beyond the implicit default case.

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