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

No annotations are provided, so the description carries the full burden. It does useful work by disclosing the return payload (access level enum of open/session/api/blocked, entry URLs, alternate route, block reason) and implying a read-only lookup, but it says nothing about prerequisites, whether 'blocked' results are an error, or how the lookup is scoped.

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, purpose first, return contract second, with zero filler. Every clause carries information the 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?

With no output schema, the description's enumeration of return fields is genuinely needed and present. But for a tool with an undocumented free-text input and two close sibling tools, the description should clarify query shape and routing; those omissions leave it only minimally 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% — the single required 'query' parameter has no documentation anywhere. The description could have compensated by explaining what a query looks like (site name, URL, task description?), but 'for a task' only vaguely gestures at it. This is the main functional 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 states a specific verb and resource ('Find sites in the atlas') and clarifies scope with 'for a task', so an agent knows it is a discovery/search operation. It does not, however, differentiate itself from the sibling atlas_site or atlas_guard, so the agent can't tell from the text alone which of the three to reach for.

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?

Beyond the phrase 'for a task', there is no statement of when this tool should be used, when it should not, or which sibling (atlas_site, atlas_guard, browser_search) covers related needs. The agent must infer the routing decision entirely on its own.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the return behavior (allowed vs. blocked reason), but does not mention side effects, auth requirements, rate limits, or whether the check itself has any operational impact.

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

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

Two short sentences with zero filler; the core question is front-loaded and the return behavior is stated immediately after.

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 check with no output schema, the description gives only a basic indication of return values. It leaves the URL format and the structure of a blocked reason vague, which is a modest gap but not fatal for such a narrow tool.

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

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

Schema description coverage is 0% for the single required url parameter. The description only repeats 'this URL' without adding format, scope, or examples beyond the schema's type: string declaration.

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 query about URL automation permission and what the tool returns (allowed or blocked reason), making the purpose clear. It does not explicitly differentiate itself from browser-action siblings, but the check/guard purpose is still evident.

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 question form — an agent can infer this checks whether automation is permitted for a URL — but the description gives no explicit when-to-use guidance, no exclusions, and no named alternatives among the many browser sibling tools.

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

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

No annotations or output schema are provided, so the description carries the burden. It discloses that the result includes a full entry and button map, but says nothing about read-only behavior, side effects, permissions, or error cases.

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?

It is a single front-loaded sentence with no filler. The parenthetical clarifies the button-map contents efficiently.

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 retrieval tool with no annotations or output schema, the description explains some return content but leaves the parameter meaning and sibling alternatives undefined. That is adequate but has clear gaps for reliable 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?

The only parameter, site, is a required string, and schema coverage is 0%. The description does not say whether site expects a name, ID, URL, slug, or other identifier, so it adds no usable meaning beyond the property name.

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

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

The description names the resource ('one site's full entry') and details its content (button map with pages, controls by role and name), so the purpose is clear. It does not explicitly distinguish this tool from siblings such as atlas_find or atlas_guard, so it falls short of a 5.

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

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

There is no statement of when to use this tool versus atlas_find/atlas_guard or when not to use it. The closest guidance is an implicit 'fetch a site entry' use case, which is not sufficient for reliable tool selection.

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

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

With no annotations, the description carries the whole burden, and it handles the most important behavioral fact. It reports the return signal: moved=false means there was nowhere to go back to. It doesn't say what happens on failure at a tab boundary or what the moved=true payload contains, but the core edge case is disclosed.

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

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

Two short sentences, no filler. The core action comes first and the edge-case signal follows, so every sentence 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?

This is a simple, single-parameter navigation tool with no output schema. The description covers the action and the one surprising return value. Only the moved=true payload and any failure modes are unstated.

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

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

The tool has only one parameter, and the schema documents it at 100% coverage: 'tab id returned by browser_open'. The description adds nothing about the tab parameter. That is acceptable given the schema's completeness, but it earns no extra credit.

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: 'Go back one page in the tab's history.' That clearly separates it from browser_goto, browser_open and browser_close. It never names a sibling explicitly, so it stops short of full differentiation, but the action itself is 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 by the action: go back a page when you need to return to the previous location. No exclusion cases are given, and it never points to an alternative such as browser_goto for a forward jump. An agent can infer the right call, but nothing is 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 human-like pointer pace, the hard safety stop on pay/buy/submit/delete-like controls returning 'ask the human', and that the result url reflects where the tab ended up. It stops short of covering failure modes or whether the call waits for navigation to settle.

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

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

Three dense sentences, zero filler, with the locator strategy stated first and the safety behavior and return semantics following.

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, yet the description explains the meaningful return field (result url). Safety and targeting are covered; only error/edge behavior is left implicit, which is a minor gap for a click tool.

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

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

Schema coverage is 67%, and the description mostly reinforces what the schema already says (css as fallback vs role+name). It adds no detail on tab, index, name, or pace beyond the field-level descriptions, so the undifferentiated 'role' and 'name' params remain unexplained in 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?

Specific verb (click) plus target resource (a control) and the two ways to identify it (role+name preferred, css fallback). An agent can distinguish it from sibling browser_type without opening the 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 clear preference guidance on locator strategy (role+name over css) and flags the class of controls that will abort, but says nothing about when to reach for this over siblings like browser_type or browser_run, nor prerequisites such as the tab needing to be open.

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 side effect that empty episodes are not recorded, that result overrides the automatic verdict, and that a verdict is produced. It stops short of saying whether closing can fail, whether the tab state persists, or what the returned episode 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?

Four tight sentences, each doing distinct work, and the primary action is front-loaded before the result semantics and the lesson_record pointer. Nothing is redundant with 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?

For a 2-parameter tool with no output schema, the description covers what is returned (the episode verdict), the null-episode edge case, and the follow-up workflow. The remaining gap is sibling selection against browser_close_mine, which matters given how similar the names are.

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 only 50% and the description compensates: it explains that result declares success/partial/fail and overrides the automatic verdict, which is meaning the bare enum does not convey. The tab parameter is already documented in the schema as the id from browser_open, so no loss there.

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 ('Close a tab') plus a scope qualifier ('this server opened') and the outcome it returns ('episode verdict'). It does not distinguish itself from the sibling browser_close_mine, which is the one ambiguity an agent would want resolved.

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 guidance on the result parameter and on when to reach for lesson_record ('if something tripped you up'), which implies usage context. However, it never states when to use this versus browser_close_mine or when closing is inappropriate, so the routing decision 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 behavioral burden. It discloses the key scope constraint that only server-opened tabs are closed, and that omitting the port closes across all ports used, but it does not describe irreversible effects, permission needs, or what happens to unrelated tabs.

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

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

The description is a single front-loaded sentence with no wasted wording. The core action and the port/all-ports distinction are both communicated efficiently.

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 cleanup tool with no output schema and no annotations, the description covers the essential action, scope, and default port behavior. It could be stronger with an explicit note about safety around human browser profiles, but the schema already includes that warning.

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%, so the port parameter is already well documented, including its warning about 9222/9223. The description still adds useful semantics by clarifying that port is optional and that omission means closing across all ports this server used.

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 (close), a precise resource (every tab this server opened), and scope behavior (on a port, or all ports it used). It distinguishes itself from the broader browser_close sibling by emphasizing that it targets only tabs opened by this server.

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 usage context: cleanup of tabs opened by this server, optionally narrowed to one port or applied to all ports it used. It does not explicitly name browser_close as the alternative for closing a single tab, but the scope is sufficiently clear for an agent to choose correctly.

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 burden, and it does disclose real behavior: it performs visible clicks on multiple control types and repeats 'one after another' until done. What's missing is the outcome contract — what it returns, and what happens if no popup is found or a control can't be clicked.

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: the action and its mechanics first, then the trigger condition. Nothing redundant or padded.

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 output schema, the description covers what it does, how, and when to call it. Only the return/result signal and the no-op case are left unstated.

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?

Single parameter with 100% schema coverage; the schema already explains that 'tab' is the id returned by browser_open. The description adds no further guidance on the tab argument, so 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 (close) and resource (popups/overlays covering the page), plus the concrete mechanism (clicking 닫기/close/× and 'do not show today' controls). This implicitly separates it from tab-closing siblings like browser_close and browser_close_mine, though it never says so 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?

Gives a precise triggering condition: 'Use it when a click reports "covered".' That is a clear reactive-use signal an agent can act on. It does not name alternatives (e.g., don't reach for browser_close) or say what to do if nothing gets dismissed.

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 usefully discloses that the call replaces the current page in the existing tab and that blocked sites are refused, but it says nothing about permissions, expected failure modes, or how wait_css/wait_text affect completion.

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, zero filler, with the core action and tab scope front-loaded. The blocked-site caveat follows efficiently.

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

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

For a four-parameter navigation tool with no output schema and no annotations, the description covers the primary behavior but leaves gaps around failure behavior, wait semantics, and how the tab identifier relates to browser_open. It is adequate but not complete.

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

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

Schema description coverage is 75%, with tab, wait_css, and wait_text documented in the schema. The description adds no parameter-level meaning, and the undocumented url parameter is only implicitly explained by 'Go to a URL'.

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 (navigate to a URL) and scopes it to the same tab/episode, which differentiates it from siblings like browser_open and browser_tabs. It does not explicitly name browser_open as the alternative, so the distinction relies on the agent knowing what 'same tab' implies.

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 'same tab (same episode)' implies this is for navigating within an existing browser context rather than opening a new one, but no alternative tool is named and no when-not-to-use guidance is given. The blocked-sites note is a constraint, not usage 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?

Without annotations, the description carries the burden. It discloses that the tool starts Chrome with a debug port, uses its own profile, and is a no-op if already running. However, it omits details like permissions, side effects, return value, and handling of port conflicts.

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

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

The description is a single, front-loaded sentence with zero waste. Every part (start Chrome, debug port, own profile, no-op condition) is useful and directly relevant.

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 a well-documented schema, the description is mostly complete. It covers what the tool does and its no-op behavior. The lack of return-value explanation is mitigated because the schema indicates the port is managed by other tools, but a brief note on return could improve completeness.

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 schema provides a rich description for the single 'port' parameter (100% coverage), so the baseline is 3. The tool description adds no additional parameter semantics beyond what the schema already states.

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 'Start' and resource 'Chrome' with key details: debug port and own profile. It does not explicitly differentiate from siblings like browser_open, but the action of launching a browser instance is distinct enough.

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 note 'no-op if already running' implies a usage condition, but there is no explicit guidance on when to use this tool versus alternatives such as browser_open or browser_goto. The agent must infer the appropriate context.

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 well: it discloses that auto sites use stored credentials without exposing values, manual sites return needs_human, it tries only once, and retries are avoided because they lock accounts. It also states the login happens in a new tab.

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 compact and front-loaded: purpose first, then auto-site behavior, manual-site/failure handling, and retry constraint. Every sentence adds operational value.

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

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

For a two-parameter tool with no annotations and no output schema, the description covers the key behavior: login attempt, credentials handling, needs_human fallback, and no-retry policy. It could be slightly more complete about the success signal, but nothing critical 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%: the port parameter has a detailed schema description, but site has none. The tool description adds useful site-category semantics (auto vs manual) but does not clarify site format or examples, 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 action and resource: make sure the session for a site is logged in, in a new tab. It distinguishes auto sites from manual sites and explains the needs_human fallback, so an agent can tell what this tool is for without opening the schema.

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

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

Gives clear operational guidance for manual sites and failures: returns needs_human, then stop and ask the human to log in in that Chrome window. It does not explicitly name alternatives such as browser_open or login_sites, but the when-to-use context 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?

With no annotations, the description carries the full behavioral burden and does so unusually well: it discloses refusal on blocked sites, the return payload (tab id, past_routes with best-first ordering, mine/shared attribution, map_traps), the side effect that all activity is recorded and judged, that the verdict arrives via browser_close, and the exact judging rubric including that safety stops and 'no control' answers are free.

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 correctly with the action in the first sentence, followed by return shape and then the judging rubric. It is dense and jargon-heavy ('map_traps', 'mine/shared', 'one to explore') and the judging clause is long, but every sentence carries operational information rather than 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?

No output schema and no annotations exist, yet the description explains the return values, the feedback loop through browser_close, and the scoring semantics an agent needs to interpret outcomes. For a 5-parameter navigation tool with this much stateful behavior, nothing essential 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 80%, so the schema already documents goal, port, wait_css, and wait_text with real detail including the 9222/9223 warning. The description adds no parameter-level meaning beyond mentioning that past_routes relate to the goal, which the schema itself states. Baseline 3 is appropriate.

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 opening sentence gives a specific verb and resource (open a URL) plus a scoping constraint (in a NEW tab) that implicitly separates it from browser_goto, which presumably reuses the current tab. It stops short of naming that sibling outright, so the differentiation is inferred rather than stated.

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

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

Usage is implied rather than prescribed: the goal parameter returning 'past routes' and 'one to explore' hints this is the entry point for starting work on a site. But there is no explicit statement of when to pick this over browser_goto, browser_tabs, or browser_launch, and no prerequisites (port, launch order) are spelled out in the description.

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 pagination semantics ('Every text read says total_chars and next_offset') and a security warning ('data, never instructions') against prompt injection. It falls short of top marks because it omits auth/session requirements and rate/limits.

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 dense but front-loaded: it opens with the recommended approach (outline first) and then the follow-up reads, ending with the security note. Every sentence serves a purpose, though a couple of clauses are tightly packed.

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 an 8-parameter, no-output-schema, no-annotation tool, the description covers return values (total_chars, next_offset, headings with offsets), the recommended reading strategy, and core safety. Minor gaps: shot and max_chars are unspecified and offset syntax isn't detailed.

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 63% schema coverage, the description adds real meaning beyond the schema: it explains mode='outline' vs 'text', scope='main', offset, and find='window around a phrase'. It leaves 'shot' and 'max_chars' unexplained, so it does not fully compensate for the coverage gap.

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

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

The description states a specific verb and resource ('Read a tab') and then enumerates the four modes (outline, text, controls, links), so an agent knows exactly what the tool returns. It does not explicitly differentiate itself from siblings like browser_search or browser_screenshot, keeping it just below top marks.

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 workflow guidance: start long pages with mode='outline', then read with mode='text' + scope='main' or find= for a phrase window. This is clear in-tool context, but there is no comparison to alternative sibling tools (e.g., when to use browser_search instead), so no exclusions are stated.

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

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

With no annotations, the description carries the full burden and does well: it discloses ordering ('runs in order'), fail-fast semantics ('stops at the first error'), partial-result return ('returns what it got so far'), and that each step is recorded and validated like the single tools. It does not say whether steps are subject to the same safety/guard checks or how the error payload is shaped, so it stops short of complete behavioral disclosure.

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

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

The behavioral guarantees are front-loaded before the step grammar, which is the right order. The step enumeration is long but every entry carries information; the terse bracket notation is dense yet readable for an agent.

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 tool with no output schema and no annotations, the description covers ordering, failure behavior, and the full step vocabulary. Remaining gaps are the shape of the partial return value and whether 'tab' must come from browser_open (the schema covers that).

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%: 'tab' and 'pace' are documented in the schema, but 'steps' items are only typed as 'array of array'. The description compensates by enumerating every valid step form with its positional arguments, which is real value beyond the schema. It does not spell out that the first element is the step name or how optional args like 'index?' and 'find?' behave when omitted.

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 opens with a specific verb and scope: 'Several steps in ONE call'. It explicitly distinguishes this batch tool from the single-step siblings (browser_goto, browser_click, browser_type) by positioning it as the multi-action round-trip reducer. An agent can tell exactly what this does without opening the 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 states the selection condition clearly: 'use it whenever you already know the next steps', which implicitly routes adaptive/inspect-first workflows to the single tools. It does not explicitly name a when-not case (e.g. when you need to inspect an intermediate result before deciding the next action), so it is clear context rather than complete exclusion 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?

No annotations are provided, so the description carries the full behavioral burden. It says only that a screenshot is taken; it does not disclose whether the capture is visible viewport only, what format or output is returned, whether permissions matter, or whether any side effects occur.

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

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

The description is a single front-loaded sentence with no wasted words. Its brevity is efficient, even if other dimensions reveal missing context.

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 explain what kind of screenshot is returned and any relevant constraints. As written, it omits output format, viewport scope details, and behavioral expectations, leaving the agent under-informed for 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 coverage is 100% and the sole parameter is documented as the tab id returned by browser_open. The description adds no additional meaning beyond the schema, so baseline 3 is appropriate.

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 and resource: taking a screenshot of a tab's viewport. It is clear enough to distinguish from browser_read or browser_tabs, though it does not explicitly name or contrast those alternatives.

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

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

There is no guidance on when to use this tool versus browser_read, browser_tabs, or other screenshots. The description gives no context, prerequisites, or exclusions.

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

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

With no annotations, the description carries the full burden and does well: it discloses interleaving order (one engine at a time), per-domain deduplication, per-result provenance fields and a familiarity count, plus captcha-blocked engines being reported and skipped. It stops short of covering latency, total result limits, or partial-failure reporting beyond captcha.

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 sentences, purpose front-loaded first, then output shape, then reading guidance, then failure behavior. Dense but every sentence contributes; the reading-guidance sentence is the only one that could be trimmed.

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

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

With no output schema and no annotations, the description does the heavy lifting by explaining what each result carries and how results are ordered. It is nearly complete for a search tool; only error/timeout behavior and result-count limits are unaddressed.

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 60%: port, per_domain and per_engine already have useful descriptions, and the engines enum is self-documenting. The description adds real value by stating the default engine set, but says nothing about query semantics or how per_engine/per_domain interact with the interleaving it describes, so the baseline 3 fits.

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 (multi-engine research search) and names the concrete engines involved. It is clearly distinguishable from the tab-control siblings (browser_goto, browser_open, browser_read) because it produces ranked, cross-engine result sets rather than navigating to a page.

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 downstream reading guidance ('read from several domains and engines, prefer unfamiliar ones, do not settle on the first source'), which implies a research use case. However, it never states when to choose this over the sibling browser tools or when not to use it, leaving tool selection 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; it does disclose that this is a non-mutating discovery operation and warns that tab ownership matters. It omits whether results are scoped to the session's browser, whether tabs from multiple windows are included, and any ordering, leaving meaningful behavioral gaps for a no-annotation 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 with no waste; the core action is front-loaded and the safety caveat follows immediately.

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

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

For a simple one-optional-parameter list tool this is nearly adequate, but with no output schema and no annotations the agent gets no sense of the return shape (tab IDs, titles, URLs) or scope, which it would need to act on results with browser_click or browser_read.

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 port parameter already carries a detailed warning about never using 9222/9223 without human consent, so the schema does the heavy lifting. The description adds nothing about the port, so the baseline 3 is appropriate.

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 open tabs"), which cleanly separates it from mutating siblings like browser_open, browser_close, and browser_close_mine. It stops short of naming an explicit alternative, but the operation is 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?

The second sentence gives a safety constraint ("Tabs you did not open may be a human's work: do not touch them") that implies this tool is the safe discovery step before acting on tabs. However, it never states when to call this versus related tools or what to do next, so guidance 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, the description carries the full burden and does disclose useful behavior: character-by-character typing, IME composition for Hangul, and that the value is verified after typing. It does not disclose what happens when verification fails (retry? throw? return a flag), whether typing is destructive to existing content, or permission/auth constraints on a browser mutation.

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 core action and zero wasted preamble. The second sentence is heavily nested with parentheticals, but every clause (Enter rule, target kinds, exclusion list) carries actionable 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 an 8-parameter mutation tool with no annotations and no output schema, the description covers the typing mechanism and one edge case but leaves gaps an agent must guess at: how verification results are reported, what `clear` does, and how ambiguous name/role matches are resolved via `index`.

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 only 50%, and the description compensates only indirectly: the search-field heuristic implies how `name`/placeholder targeting works. Undocumented parameters remain unexplained — notably `clear` (does it wipe the field first?), `index` for ambiguous matches, and `role`, which materially change the outcome of the call.

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 ("Type text into a field") plus distinguishing mechanics (key-by-key, IME composition for Hangul, post-type verification). It is clearly not a click/read/run tool, though it never names a sibling explicitly to route against (e.g. browser_run or browser_click for non-field interaction).

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

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

The description gives one concrete conditional rule (trailing newline presses Enter, and only in search-like fields, with an explicit exclusion list: e-mail/phone/comment/code). That is real when-not guidance about input content, but there is no guidance on choosing between this tool and browser_click, browser_run, or browser_search.

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 and does not disclose what happens on timeout (error vs. silent return), what the default timeout is, whether it blocks the tab, or whether the two wait conditions are ANDed or ORed. 'or the page text contains something' hints at OR semantics but leaves it ambiguous.

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, but 'something' is imprecise and wastes the one clause that could have clarified the text-matching 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?

A polling/wait primitive with no output schema, no annotations, and three of four parameters undocumented in both schema and description leaves critical gaps: timeout behavior, return value, and condition-combination semantics. An agent cannot reliably call this without guessing.

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 only 25% (just 'tab' is documented), so the description must compensate and largely does not. It implies wait_css and wait_text map to CSS/text conditions but never states that at least one condition is required, the timeout unit or default, or whether combining wait_css and wait_text means OR rather than AND.

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

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

Names a specific verb (wait) and the two wait conditions (CSS selector existence, page text containment), which clearly distinguishes it from browser_read or browser_screenshot. It is not vague, but it stops short of naming sibling alternatives.

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

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

No guidance on when to call this versus browser_read, browser_screenshot, or browser_click, and no guidance on choosing wait_css versus wait_text or when to use neither. The agent must infer the polling use case 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 burden and does well: it discloses locality ('stays on this machine'), downstream effect ('shows up from the next browser_open on that page (map_traps)'), and a hard content constraint ('describe the page, never a person; no personal data'). It omits failure/overwrite behavior and any cap on how many pitfalls are kept.

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 imperative and timing, then the format, then persistence, then the safety constraint — no filler sentences, and the example earns its place by showing the expected sentence shape.

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-param local-write tool with no annotations and no output schema, the description covers when, what, where it persists, and privacy limits. Remaining gaps (behavior on duplicate pitfalls, whether an existing lesson can be amended, what a call returns) are minor but not negligible.

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%, so baseline is 3; the description adds real meaning by prescribing that 'text' be one plain sentence including what worked, with a concrete example, and by implying that the optional 'page' scopes the pitfall to a single page of the site. It does not address the 5-200 character bound beyond 'one plain sentence'.

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: 'record a pitfall you hit on a mapped site', with timing ('after a task') and a format constraint. It distinguishes itself from generic memory tools by tying the record to a mapped site/page and to map_traps, though it never names the nearest sibling (memory_record) 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?

The trigger condition is clear and actionable ('After a task: record a pitfall you hit on a mapped site'), and the example clarifies what qualifies. It gives no explicit exclusion against memory_record / map_learned, so the agent must infer which store to use.

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 valuable trait: credential values are never returned, which is important for a credentials-adjacent tool. However, it does not state that the operation is read-only, whether the list is complete or paginated, or how mode auto/manual is determined.

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

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

Two short sentences, front-loaded with what the tool returns and closed with the security-relevant constraint. 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 zero-param, no-output-schema tool, the description covers the returned fields at a high level, but leaves the meaning of auto vs manual mode, list completeness/ordering, and the intended call sequence unexplained. 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?

The tool takes zero parameters, so there is no parameter semantics to explain; the baseline for 0-param tools applies. The description does not waste effort restating inputs.

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 fragment "Sites with a login recipe" conveys the resource and the returned fields (mode, credential existence), but there is no verb (list/read) and no differentiation from siblings like atlas_site or browser_login. An agent can infer it enumerates login-capable sites, but the purpose is only implied rather than stated.

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

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

There is no guidance on when to call this versus browser_login (perform a login) or atlas_site (site details), and no prerequisites or exclusions are mentioned. The agent must guess that this is a discovery/enumeration step before logging in.

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 does carry some behavioral weight: 'Already applied locally' signals these are settled, non-pending entries, and it explains the meaning of a returned field ('shared'). It does not state permissions, ordering, size, or any mutation behavior, though the wording implies a read-only retrieval.

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

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

Two compact sentences with no filler, and the core subject is front-loaded. Minor deduction because the opening is a bare noun phrase rather than a statement of what the call does.

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-input tool with no output schema, the description should at least characterize the returned collection (fields beyond 'shared', ordering, volume). It covers the resource and one field, which is the minimum viable level, but leaves the agent guessing at the response shape.

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

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

The tool takes zero parameters and the schema is an empty object, so there is nothing for the description to disambiguate. Baseline 4 applies for a no-parameter tool.

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

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

The description identifies the resource concretely (button-map fixes and lessons learned from local use), which differentiates it from siblings like lesson_record and memory_recall, but it never states the action — no verb like 'returns' or 'lists'. An agent can guess this is a read of accumulated fixes, but must infer it.

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 explicit when-to-use guidance, no exclusion criteria, and no named alternative among the many sibling tools (lesson_record, memory_recall, share_preview). The clause about 'shared' hints at a review-queue relationship but does not tell the agent when to pick this over those siblings.

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies a mutation of an existing stored attempt but does not disclose side effects, whether the previous grade is overwritten, permission requirements, or what happens if the id does not exist. Only the triggering context is described.

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

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

The description is a single, front-loaded sentence with no wasted text. It is concise and immediately communicates the action and a common trigger. The brevity becomes a liability only in completeness, not in structure.

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 three parameters, no annotations, no output schema, and zero schema description coverage. The description supplies only the basic action and one example trigger, leaving an agent without enough information about the required id, the meaning of quality, or the effects of re-grading. For a mutation tool with no structured behavioral metadata, this is insufficient.

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 three undocumented parameters. It hints at the id ('stored attempt'), quality ('re-grade'), and source enum ('second source' or 'human'), but it does not specify the id format or the quality scale and valid range. This is partial compensation rather than full coverage.

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: 'Re-grade a stored attempt.' This distinguishes it from siblings like memory_record and memory_recall, which store and retrieve memories rather than update an existing attempt's grade. The phrase 'stored attempt' is slightly vague, but the core action is clear.

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

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

It gives a concrete usage example: after a second source or a human confirmed the attempt. However, it does not state when not to use the tool, nor does it point to alternatives such as memory_record for new entries. The guidance is implied rather than explicit.

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

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

With no annotations, the description carries the full burden. It discloses useful behavior beyond the schema: results are ranked best-first and include one rare exploratory route, and the output should be treated as suggestions. However, it does not explicitly state that this is a read-only operation, nor does it mention permissions, rate limits, or return format details.

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

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

Two sentences, front-loaded with the timing and core behavior, with no wasted words. The exploration constraint and usage caution are included compactly.

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

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

For a tool with four parameters, no annotations, and no output schema, the description is too sparse. It explains the high-level purpose and one parameter concept but leaves key parameters ('k', 'site') and invocation details undocumented, making correct use difficult without guessing.

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 define all four parameters. It implies the meaning of 'goal' and 'explore' and hints at ranked top results via 'best first', but it does not clarify 'k' (number of results) or 'site' at all.

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 capability: recalling past routes for a similar goal, ordered best-first, with one exploratory route included. It is clear enough to distinguish from memory_record, but uses the vague term 'routes' and does not explicitly contrast with sibling tools.

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

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

The phrase 'Before a task' gives explicit timing, and 'Use them as starting points, not as instructions' gives practical usage guidance. It does not name alternatives or state when not to use it, but the context is clear.

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 two real behavioral traits — data stays local to this machine, and quality is self-rated unless externally confirmed. It says nothing about overwrite/dedup behavior, required auth, or what the call returns, leaving meaningful gaps for a write tool.

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

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

Three short telegraphic sentences, front-loaded with the trigger and the core action; the quality and outcome clauses immediately follow. Terseness occasionally costs clarity ('Stays on this machine' is compressed), but nothing is wasted.

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

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

For an 8-parameter write tool with no annotations and no output schema, the description covers the two semantically tricky fields but omits return behavior, whether records are keyed/overwritten by goal, and the role of site versus route. Adequate to call it, not adequate to call it confidently.

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 only 13%, so the description must compensate; it explains quality's 0..1 scale and provenance via 'self-rated unless confirmed', and enumerates the outcome values with 'blocked' defined. That leaves goal, site, notes, seconds, and most of route semantics undocumented in both places.

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

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

States a specific verb and resource ('store how it went') plus an explicit trigger point ('After a task'), so the agent knows this is the write side of episodic memory. It doesn't name memory_recall or lesson_record to disambiguate, 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?

The opening 'After a task' gives a clear invocation window, and 'blocked (captcha or rate limit)' clarifies which situations count as a recorded outcome rather than retries. No explicit exclusions or named alternatives are given, so it stops short of 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?

No annotations are provided, so the description carries the full disclosure burden. Read-only aggregation is only implied, and nothing is said about what 'outcome' values exist, what the counts represent, whether the result is a fixed or dynamic set of buckets, or cost/scope of the query.

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 single fragment has no filler, but at roughly eight words it is under-specified for a tool with no annotations and no output schema. Conciseness is achieved at the expense of information rather than through efficient framing of necessary detail.

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

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

With no annotations, no output schema, and no parameters, the description is the only source of behavioral information, yet it omits what the return shape is (counts per outcome?), what the outcome categories are, and how it relates to the sibling memory tools. It is insufficient for an agent to call it confidently.

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 (100% schema coverage), so per the baseline there is nothing for the description to clarify about input semantics.

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 fragment "How much experience is stored, by outcome" indicates an aggregate/statistics read over stored memory entries grouped by outcome, which is a real distinction from retrieval siblings like memory_recall. But it never states a verb or the noun being counted (memory entries? records? lessons?), so the purpose is inferred rather than stated.

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

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

There is no guidance on when to call this versus memory_recall, memory_record, or memory_rate. An agent must guess that this is a summary/metrics view and that memory_recall returns the actual content.

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 "Nothing is sent" is the single most important disclosure for a tool with a mutating sibling — it explicitly declares this is non-destructive. It also describes the content that will be inspected. It does not state what happens when the queue is empty or how large the preview can get, which are the remaining behavioral 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?

Three short clauses, no filler, and the critical "Nothing is sent" disclosure lands early. The human-confirmation instruction sits at the end rather than being front-loaded, which is a minor structural weakness for a gating tool.

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

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

For a zero-parameter preview with no output schema, the description substitutes well by enumerating what the return contains and asserting no side effects. The empty-queue case and any size limits on the preview are the only meaningful omissions.

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 to disambiguate and the baseline of 4 applies. The description instead spends its words on the payload the empty call returns, which is the right use of space.

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 makes clear this is a dry-run of the shared review queue, enumerating exactly what it surfaces (sanitized experience rows, map fixes, lessons for public sites, not yet submitted). It distinguishes itself from the sibling share_upload by framing itself as the preview step. It is phrased as a noun clause rather than a verb+resource statement, which slightly softens the action, but the resource and scope are 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?

"Show this to the human before share_upload" gives explicit sequencing and names the alternative tool that performs the actual send. What is missing is a when-not condition (e.g., nothing queued, already confirmed), so the routing is clear but not complete.

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 usefully discloses the daily auto-run cadence and what kind of data arrives, but says nothing about side effects on local state, idempotency, conflict handling, or failure behavior for a sync 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?

Two short sentences with no filler; the core action is front-loaded and the cadence detail follows. Every clause adds 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 zero-parameter, no-output-schema sync tool the description covers what is transferred and when it also happens automatically, which is largely sufficient. It stops short of explaining what a caller observes after the sync (new items available? local state changes?), but nothing essential for 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?

The tool takes zero parameters, so there is nothing for the description to clarify; baseline 4 applies. No misleading parameter hints are present.

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 (what maintainers merged into the shared database), and enumerates content types (experience, map fixes, lessons). It is implicitly distinguished from share_upload/share_preview by being the pull side, though it never names those siblings.

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?

'...now' hints at a manual, on-demand trigger and the second sentence reveals the daily automatic run, which implies the tool is optional. But it never says when an agent should call it instead of waiting, nor how it relates to share_preview or the memory_* tools.

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

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

With no annotations, the description carries the full behavioral burden and discloses key context: content goes to a shared review queue, a maintainer decides what becomes public, and human authorization is required. It does not describe return values, failure handling, or whether submissions are reversible, which keeps it from 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?

Two sentences, front-loaded with the action and followed by the critical guardrail. Every sentence earns its place and nothing is 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 zero-parameter action with no output schema, the description covers purpose, authorization, and the review-queue outcome. It could add more about what happens after submission or what the tool returns, but it is largely complete for this complexity level.

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

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

There are zero parameters, so parameter semantics are inherently simple and the baseline is 4. The description references 'share_preview content' as the implicit input, which is consistent with the empty parameter 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?

The description states a specific verb (Submit) and resource (share_preview content) and places it into a shared review queue, clearly distinguishing this action from the sibling share_preview tool. An agent can identify exactly what the tool does without opening the 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 an explicit use condition: ONLY when the human has explicitly asked in this conversation to upload or share, and explicitly forbids autonomous use. That is clear when-to-use and when-not-to-use guidance, even without naming alternatives.

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