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

With no annotations provided, the description carries the full burden of behavioral disclosure and handles it well: it states exactly what the audit inspects and promises 'structured violations with severity and selectors.' It does not contradict any annotation. Remaining gaps are minor — it doesn't explicitly confirm a read-only side-effect profile or describe error behavior for an invalid tabId.

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: core action first, then the seven audited check categories, then the return shape. No filler, no restatement of the tool name, and every clause adds information an agent needs to invoke it correctly.

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

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

For a single-parameter tool with no output schema and no annotations, the description is largely complete: it covers what the tool does, what it checks, and what it returns (violations with severity and selectors). What's missing is any edge-case guidance (e.g., behavior when the page is unloaded or the tabId is stale), but the capability is adequately specified 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?

Schema description coverage is 100% — the single required tabId is already documented as 'Chrome tab ID to audit.' The description's phrase 'on a page' adds nothing beyond that. Since the schema fully carries parameter documentation, the baseline of 3 applies and the description neither improves nor degrades it.

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-object pair, 'Run a WCAG accessibility audit on a page,' and enumerates concrete check categories (color contrast, alt text, form labels, heading structure, lang attribute, empty links, tabindex misuse). This clearly distinguishes it from siblings like neuron_seo_audit (SEO-focused) and neuron_audit_page (generic audit) without needing to open any schema.

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

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

The use case is implied clearly: call this when a page's accessibility compliance against WCAG needs verification. However, it names no alternatives and gives no exclusions — notably, the sibling neuron_seo_audit is the obvious non-accessibility counterpart and is never referenced, nor are DOM-inspection tools like neuron_query_dom routed away from.

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. It discloses the full workflow: taking a screenshot, sending it with a prompt, and waiting for an approve/reject reply. It also surfaces authentication and recipient requirements. It stops short of describing timeout/failure behavior or the exact return value, which keeps this 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?

Three tight sentences with no filler. The core action is front-loaded, followed by the distinguishing usage guidance and prerequisites. Every sentence contributes necessary 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?

The description covers the main flow and prerequisites well, but there is no output schema and no mention of what the tool returns (e.g., approve vs. reject, timeout signal). It also does not describe failure behavior when no reply arrives. For a blocking tool with six parameters and no annotations, this is a meaningful gap.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by connecting the parameters to the workflow: the screenshot of the current state goes with the prompt to the WhatsApp number, and both api_key and phone are required. This helps an agent understand how the parameters interact beyond their individual schema descriptions.

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 resource: 'Send an approval request to WhatsApp and wait for the response.' It then details the mechanism (screenshot, send prompt, wait for approve/reject), which clearly separates it from the many sibling tools. There is no ambiguity about what this tool does.

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 explicitly says to use this 'instead of pausing for keyboard approval — the user approves from their phone.' It also states the prerequisites (API key and recipient phone number). It gives clear context but does not formally list when-not-to-use conditions or alternative tools beyond the keyboard-pause pattern.

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 of behavioral disclosure. It does disclose that the tool runs multiple audits, returns a combined report, and replaces five separate calls. However, it does not state whether these audits are read-only, whether they can trigger network requests or page changes, how partial failures are handled, or what the combined report structure looks like. This is adequate but leaves meaningful 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?

Two sentences, no filler, with the primary purpose front-loaded and the audit list immediately following. The second sentence succinctly communicates relationship to sibling tools. Every phrase 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 composite tool with no output schema and no annotations, the description is strong: it names all five audit categories, states the combined-report output, and identifies the sibling alternatives it replaces. It could be more complete by clarifying whether the tool is read-only, how the combined report is structured, and when an agent should instead use a single specialized audit tool, but the core invocation context is well covered.

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 baseline is 3. The description adds value by mapping the short audit option strings from the schema to their full meanings: 'a11y' → accessibility (WCAG), 'security' → security scan, 'performance' → performance snapshot, 'seo' → SEO audit, and 'errors' → console errors. It also clarifies that all audits run together by default, reinforcing the schema's 'default: all' note.

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 resource: 'Run all quality audits on a page in one call.' It enumerates exactly which audits are included—accessibility (WCAG), security scan, performance snapshot, SEO audit, and console errors—and states that it returns a combined report. This clearly differentiates it from the individual sibling audit tools by framing it as their aggregate replacement.

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 explicitly tells the agent when to choose this tool: when all quality audits are needed in one call. It names the alternatives directly with 'Replaces 5 separate tool calls (a11y_audit + security_scan + perf_snapshot + seo_audit + get_errors),' making the routing decision unambiguous against the relevant 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 are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'checks' validity but does not describe whether it makes a network call, whether it refreshes credentials, what happens when credentials are invalid, or what the return value looks like. This is minimal behavioral information.

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 clear sentence that immediately states the purpose and qualifies the credential types. There is no redundant wording, no repetition of schema details, and no unnecessary background. It is efficiently front-loaded.

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 tool, the description is mostly sufficient, but the absence of any usage guidance, behavioral detail, or expected result format leaves an agent uncertain about edge cases like unsupported platforms or expired sessions. It is adequate but not rich enough to be considered complete on its own.

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%: the platform parameter is fully documented with an enum and a short description. The description adds the context that credentials involve cookies, headers, and tokens, but does not add further parameter-level meaning beyond the schema. 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 uses a specific verb ('check') and a clear resource ('credentials for a social platform'), and clarifies what counts as credentials (cookies, headers, tokens). This clearly differentiates it from sibling tools like neuron_get_cookies or neuron_session_diagnostics, which have different purposes.

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 no guidance about when to use this tool instead of alternatives, nor does it mention any prerequisites such as having an active session or logged-in profile. An agent must infer when 'check_auth' is the right choice among the many 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?

With no annotations provided, the description carries the full behavioral disclosure burden. It does clearly communicate a destructive action against mock rules, but it omits side-effect details such as reversibility, session scope, or impact on currently active mocks.

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, direct sentence with no filler. The action and object are front-loaded, making it easy to parse and remember.

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 parameterless mutation tool, the core action is fully specified. The main gaps are usage guidance and side-effect context, but these do not prevent an agent from understanding what the tool does.

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?

This tool has zero parameters and the schema is empty, so there is no parameter documentation burden. The baseline for parameterless tools is appropriate here.

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 ('Remove') and resource ('all network mock rules'), making the tool's purpose immediately clear. The 'all' qualifier also differentiates it from related sibling tools like neuron_set_mock and neuron_get_mocks.

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 no explicit guidance about when to use this tool versus alternatives such as neuron_set_mock, neuron_rules_set, or neuron_clear_storage. It does not mention prerequisites, typical use cases, or when not to use it.

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 burden and does disclose the destructive nature ('Clear all') and that the operation is broad in scope. However, it misses a subtle behavioral trap: localStorage is per-origin, so clearing it for the current page also wipes storage for every other tab on that origin — the 'current page' framing is misleading. It also discloses no post-condition (page reload, confirmation, or empty return).

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 13-word sentence that front-loads the verb and resource, and uses 'all' to signal the destructive scope. There is zero wasted text, and every word contributes to meaning.

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

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

For a simple two-parameter tool with one enum, the coverage is mostly adequate, but two gaps remain: the origin-wide side effect of localStorage clearing is not addressed, and the description never links to sibling neuron_get_storage for verification before/after clearing. No output schema exists, so a brief note on what the tool returns (or that it returns nothing) would round it out.

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%, with the schema already documenting both parameters including the default ('default: localStorage') and the enum values. The description adds little beyond reinforcing that type selects between the two storage kinds; per the rubric, baseline 3 applies since the schema carries the load and the description doesn't contradict or extend it.

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 uses a specific verb ('Clear') with a specific resource ('localStorage or sessionStorage entries') and a scoping qualifier ('for the current page'). This clearly distinguishes it from siblings like neuron_get_storage (read) and neuron_clear_mocks (a different resource entirely), so an agent can tell it apart 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?

Usage is implied by the phrasing: the emphasized 'all' suggests this tool is for a full storage reset rather than targeted removal. However, the description offers no explicit when-to-use or when-not-to-use guidance, no pointer to the read counterpart (neuron_get_storage), and no warning that partial clearing would require a different approach. The context is inferable but never 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 provided, the description carries the full burden of behavioral disclosure. It states the action but does not disclose what happens on multiple or zero matches, whether it waits for the element, whether it scrolls into view, or what it returns after the click. For a mutating action, this is a notable gap.

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

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

The description is a single, front-loaded sentence with no filler. Every word contributes: the verb, the target element, and the two matching strategies. It is appropriately sized for a simple click action.

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

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

For a 3-parameter tool with full schema coverage, the description covers what the tool does and how to invoke it, which is sufficient for basic selection. However, with no output schema and no annotations, it lacks return-value and edge-case behavior, leaving the agent to guess what happens after the click.

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 the schema already documents tabId, texts, and selectors. The description's phrase 'by CSS selector or visible text' mirrors the schema field descriptions and adds no additional meaning about parameter precedence, formatting, or interaction.

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 uses a specific verb 'click' with a clear resource ('an element') and defines the two addressing modes: CSS selector or visible text. This distinguishes it from DOM-querying siblings like neuron_query_dom and neuron_find_elements, which inspect rather than act, and from neuron_type, which inputs text.

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 implies when to use the tool—whenever a click on an element is needed—but gives no explicit guidance on when not to use it or which alternative to prefer in ambiguous cases. Sibling tools such as neuron_vision_act may also perform clicking, but no contrast is provided.

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 burden. It discloses that the operation deletes, but does not state what happens if the cookie does not exist, whether deletion applies to all paths or a single path, whether it is immediate or reversible, or what the return value is. The 'URL context' wording is vague about how strictly the URL must match.

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 nine-word sentence that is front-loaded with the action verb and contains zero filler. It earns its place entirely.

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 is simple (two string parameters, no output schema), and parameter semantics are fully covered by the schema. However, because this is a destructive operation with no annotations, the description should ideally clarify failure behavior and the precise scope of deletion (URL matching, path), which are currently absent.

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 both 'url' and 'name' are already documented in the schema. The description's 'by name and URL' phrase merely mirrors the schema rather than adding deeper meaning about URL matching semantics or cookie scope.

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 ('Delete') and a precise resource ('a specific cookie by name and URL'), making the core action unambiguous. It is clear but does not explicitly differentiate from nearby siblings like neuron_set_cookie, neuron_get_cookies, or neuron_clear_storage.

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 alternatives, no exclusions, and no mention of sibling tools such as neuron_clear_storage for bulk deletion or neuron_set_cookie for modification. Usage context is left entirely to inference 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 of behavioral disclosure. It says 'check', implying a read-only inspection, but does not state whether it executes JavaScript, modifies navigation, or has side effects. It also doesn't describe what happens when a blocker is found or what output shape to expect (boolean vs. 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?

A single, front-loaded sentence that wastes no words. It packs the verb, resource, and a useful list of blocker types into a compact form.

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

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

For a simple one-parameter tool, the description covers the core action well. However, there is no output schema and the description does not explain what the tool returns, so an agent must infer the result semantics. It also lacks any mention of when to use it among the large sibling set, leaving some 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 input schema already documents tabId as 'Chrome tab ID to inspect' with 100% coverage. The description adds no additional parameter-level meaning, so the baseline of 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 ('check'), a resource ('a tab'), and explicitly enumerates the conditions detected (rate limit wall, login prompt, captcha, interstitial). This clearly distinguishes it from related siblings such as neuron_check_auth or neuron_query_dom. No ambiguity remains about what the tool does.

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 is provided on when to use this tool versus alternatives like neuron_check_auth or neuron_diagnose. There are no exclusions or explicit conditions. The verb 'check' hints at suspicious-blocker scenarios, but this is implied rather than stated.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It lists the diagnostic areas, but it does not state whether the tool is read-only, what the response format looks like, or whether it requires a live extension session. For a diagnostic tool this is a notable gap.

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

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

The description is a single compact line, front-loaded with 'Connection health' and followed by concrete diagnostic questions. Every word earns its place and there is no filler.

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

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

For a zero-parameter tool, naming the three diagnostic areas is reasonably complete. However, there is no output schema and no return-shape description, and the relationship to overlapping sibling diagnostics is not clarified, leaving some ambiguity about what exactly the agent will receive.

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 zero parameters, so there is no parameter ambiguity to clarify. The empty schema fully covers the parameter surface, and the baseline of 4 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?

The description names the resource and scope: connection health, dev mode, and open tabs. It is clearly a diagnostic status tool, and the question format signals what it reports. It does not use a formal verb+resource construction, but the intent 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 description implies using it when you need connection/dev-mode/tab status, but it gives no explicit guidance on when to choose this over closely related siblings like neuron_check_auth, neuron_list_tabs, or neuron_session_diagnostics. There is no mention of exclusions or alternatives.

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 behavioral disclosure burden. It explains what the tool returns and implies it is a read-only comparison, but it does not explicitly state side effects, prerequisites such as snapshot existence, or failure behavior when labels are missing. The 'Compare' wording implies non-mutating behavior, but more explicit disclosure would be stronger.

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 with no redundant filler. The core action is front-loaded, followed immediately by a precise summary of the return values and a representative use case. Every sentence contributes 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 low-complexity tool with no output schema and no annotations, the description adequately explains the tool's purpose, inputs' origin, outputs, and typical use case. It could additionally name the companion neuron_snapshot_state more explicitly as a prerequisite and note that snapshots must exist under the given labels, but overall it is sufficiently complete for correct invocation.

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

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

Schema description coverage is 100%, with both 'before' and 'after' labeled as snapshot labels. The description adds that these are snapshots from neuron_snapshot_state, which slightly reinforces parameter meaning, but it does not describe format, ordering semantics, or what happens if labels are swapped or invalid. This meets the baseline for fully schema-documented params.

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

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

The description names a specific verb ('Compare') and a concrete resource ('two page snapshots created with neuron_snapshot_state'), and clearly states the output shape: added, removed, and changed elements plus URL/title changes. This distinguishes it from related DOM-inspection tools like neuron_query_dom and neuron_find_elements.

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

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

It gives clear context for when to use the tool: detecting what changed on a page after actions like clicks, form submissions, or navigation. It does not explicitly name alternatives or exclusions, but the use-case framing is specific enough to guide selection among the many 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?

With no annotations, the description carries the full transparency burden. It discloses the grouping behavior, URL normalization, and the full set of computed metrics (call counts, statuses, content types, auth presence, avg duration, sample response shapes). It does not discuss side effects or limitations, but the analysis-focused tone strongly implies a non-destructive read 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 sentences deliver a clear opening statement and then enumerate the output contents without wasted words. The structure is front-loaded with the core purpose and followed by high-value 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?

For a parameterless analysis tool, the description covers the input source, the transformation, and the output fields. It could be more complete by noting whether live or stored traffic is used or whether there are any prerequisites, but nothing essential for invoking it correctly 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 has zero parameters, so the description need not explain parameter semantics. The schema provides no enum or nested-object constraints, and the description appropriately focuses on behavior and output rather than 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 description clearly states a specific action (analyze captured network traffic) and a concrete deliverable (structured API map with normalized URLs and metrics). It is distinct from many siblings, though it does not explicitly call out how it differs from similar traffic-analysis tools like neuron_search_traffic or neuron_export_har.

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 implies the tool is used after network traffic has been captured, but it does not explicitly state when to choose this over alternatives, nor does it mention prerequisites such as an active recording or a prior capture. Context is implied rather than stated.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention potential side effects of running JavaScript, how returned values are serialized, how errors are handled, whether promises are awaited, or any security implications. These are significant unknowns for a page-context JS execution tool.

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

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

The description is a single, clear sentence with no filler. It front-loads the action and outcome and is appropriately sized for a relatively simple 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?

With only two self-describing parameters and no output schema, the description is minimally viable. However, it omits important behavioral context for JavaScript execution: result serialization behavior, error propagation, async handling, and side-effect warnings. These gaps matter for an agent invoking arbitrary page code.

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 both parameters already have descriptions. The tool description adds little beyond the schema, only reinforcing that the expression is JavaScript running in page context. Baseline 3 is appropriate because the schema already handles parameter documentation.

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 ('Run JavaScript'), the context ('in page context'), and the expected outcome ('return the result'). This clearly distinguishes it from sibling tools like neuron_query_dom and neuron_find_elements, though it does not explicitly name them.

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

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

The description gives no explicit guidance on when to use this tool versus alternatives. It implies usage for executing arbitrary JavaScript, but does not mention exclusions, preferred scenarios, or why it should be chosen over the many DOM/traffic/session 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 burden of behavioral disclosure. It only states the output format and does not reveal how the export is delivered, whether it has size limits, whether it consumes or clears captured data, or what side effects it may have.

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, tight sentence with no filler. The key facts — action, resource, and output format — are front-loaded and every word 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?

Given the simplicity of the tool and full schema coverage, the description is minimally viable. However, with no output schema and no annotations, it leaves ambiguity about how the result is returned, whether recording is required, and how it relates to capture lifecycle tools. More context would improve invocation confidence.

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 the baseline is 3. The description itself adds no parameter-level detail, but all four parameters already have clear, self-sufficient descriptions in the schema.

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

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

The description states a clear verb ('Export'), a specific object ('captured network traffic'), and a precise output format ('HAR 1.2 JSON'). This makes the tool's core function understandable and largely distinct from related traffic tools, though it does not explicitly name siblings or contrast itself with them.

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

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

The description gives no guidance about when to use this tool instead of alternatives like neuron_get_requests or neuron_search_traffic, and it does not mention prerequisites such as a preceding capture session. Usage context must be inferred entirely from the tool name and sibling list.

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?

There are no annotations, so the description carries the behavioral disclosure burden. It discloses key behaviors: selector-based extraction, auto-detection, the types of data extracted (text, links, images, data attributes), and the 200-item limit. It does not explicitly state side-effect-free behavior, but 'extract' strongly implies a read-only 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?

The description is three sentences with no wasted words. It front-loads the core purpose, explains the selector behavior, and ends with the output limit. Each sentence contributes meaningful guidance for invocation.

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 provides enough about return content by listing text, links, images, data attributes, and the 200-item cap. It could be more complete by describing the exact return shape or field names, but for an extraction tool with two parameters, this is a solid level of 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 input schema has 100% description coverage for both parameters, so the description needs to add limited parameter-specific value. It does clarify that selector is optional and controls whether extraction targets specific elements or auto-detects patterns, which slightly enriches the schema. However, it does not add major detail beyond the schema's own descriptions.

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 clearly states what the tool does: extracts structured data from repeating page patterns, with explicit examples like product listings and search results. It distinguishes its auto-detection behavior from selector-based extraction, but does not explicitly differentiate itself from sibling tools such as neuron_find_elements or neuron_extract_to_json.

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 provides clear usage context, indicating the tool is for repeating page patterns and explaining the conditional behavior when a CSS selector is provided versus when auto-detection is used. It does not explicitly mention when to prefer an alternative tool, but the context is sufficient for an agent to recognize the intended use case.

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 should carry behavioral weight. It explains the tool navigates to a URL and returns normalized rows, and mentions pipe-ready outputs. It does not disclose side effects such as navigation changing the current tab, whether the browser context is altered, or rate-limit/pagination behavior. It is not misleading, but it leaves room for more behavioral detail.

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

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

The description is compact — three sentences covering purpose, behavior, and use cases. The main action is front-loaded, and the use-case clause directly supports agent decision-making. Slight redundancy ('scrape a page and push the data...') means it could be tighter, but it remains efficient.

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

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

For a 7-parameter tool with nested schema objects and no output schema, the description provides enough context to understand the tool's niche but not complete guidance. It explains the data-pipeline workflow and output flexibility, but doesn't cover pagination behavior, what happens when no selector/schema is provided, auth requirements, or return-value details. The schema carries much of the load, but the description is adequate for basic use.

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

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

Schema description coverage is 100%, meaning the schema already documents all seven parameters. The description adds the concept of normalized rows and pipeline-ready output but doesn't materially deepen parameter understanding beyond the schema. Baseline 3 is appropriate because the description doesn't contradict or duplicate the schema, but it also doesn't compensate with extra parameter nuance.

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 specifies a concrete verb (extract), resource (structured data from a page), and output format (clean JSON normalized rows), which clearly distinguishes it from siblings like neuron_query_dom, neuron_find_elements, or neuron_evaluate_js. It doesn't explicitly name a sibling, but the data-pipeline focus makes its role 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?

The description states the intended use case: building data pipelines, pushing to a webhook, saving as CSV, appending to a collection. It doesn't give explicit when-not-to-use guidance or name alternatives, but the context is sufficient for an agent to infer when to select this tool over DOM-inspection or JavaScript-evaluation alternatives.

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 behavioral disclosure burden. It explains that it fills fields, optionally screenshots, conditionally submits, and returns a before/after state diff for verification. It could also mention defaults or failure behavior, but the core behavioral contract is clear.

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 concise and front-loaded with the primary purpose, followed by the key behaviors and return value. All sentences earn their place, though the final sentence is more of a rhetorical comparison than strictly necessary.

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 covers the essential behavior: filling, optional screenshot, optional submit, and the state-diff return value—useful since there is no output schema. It does not address error handling or default timing, but those are secondary for a tool of this complexity.

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

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

The input schema already provides 100% coverage with descriptions for all parameters. The tool description adds context about the overall flow but does not materially deepen understanding of individual parameters 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 and resource: fill a form and optionally submit it in one call. It also distinguishes itself from the multi-step find → type → screenshot → click workflow, making it easy for an agent to understand what this tool does at a glance.

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 clearly frames when to use this tool—when you need to fill multiple fields and potentially submit in a single operation, replacing the typical manual chain. It also notes that submission is optional, but it does not explicitly name alternatives like neuron_type or neuron_click for simpler single-field cases.

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 of behavioral disclosure, and it only states the search mechanisms. It does not reveal what the tool returns (element references? count? text?), what happens when nothing matches, whether matching is exact or partial, or whether results are scoped to visible elements only. This is a significant gap for a tool with no output schema.

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 9-word sentence with zero fluff, and the core search mechanisms are front-loaded. However, it is so terse that it borders on under-specification; the conciseness is efficient but earned at the expense of the usage and behavioral context that other dimensions penalize.

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 no annotations, no output schema, 4 parameters, and a large sibling set containing several overlapping DOM tools, a one-sentence description is inadequate. It fails to explain return format, how results can be consumed by interaction tools like neuron_click or neuron_type, or how it differs from neuron_query_dom. An agent cannot confidently invoke this tool correctly in context.

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 the baseline is 3. The description adds minimal value beyond the schema: 'CSS selectors' and 'visible text' loosely map to the selectors and texts parameters, but the schema already describes them nearly identically. The description does not clarify relationship between the parameters, matching semantics, or the limit behavior.

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?

'Find elements by CSS selectors or visible text' states a specific verb (find), resource (elements), and the two matching mechanisms (CSS selectors, visible text). It is clear and self-contained, but it does not explicitly differentiate itself from the closely related sibling neuron_query_dom, so an agent could not tell them apart without opening both schemas.

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 no guidance on when to use this tool versus alternatives such as neuron_query_dom, neuron_evaluate_js, or neuron_watch_element. No context, exclusions, or alternative routing is provided, leaving the agent to guess which of the many DOM-related siblings is appropriate.

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

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

With no annotations provided, the description itself conveys that this is a read-only 'Get' operation, which is a key behavioral trait. It lists the cookie attributes returned, giving the agent a clear idea of the response content. It stops short of stating whether any session or tab state is required, but for a simple read operation the verb and fields suffice.

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 that front-loads the core action and object ('Get all cookies for a URL') and then packs the relevant returned fields into a compact list. Every word adds value; there is no filler or redundancy.

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

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

The tool is simple with one fully documented parameter. Since there is no output schema, the description compensates by listing the returned cookie attributes. It could be slightly more complete by noting that cookies are returned from the current browser session or by clarifying behavior on URLs without cookies, but the current level is sufficient for correct invocation.

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

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

Schema description coverage is 100%, so the schema already fully documents the 'url' parameter. The description only matches it with 'for a URL' and adds no extra semantics about format, encoding, or edge cases, so the baseline of 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 clearly names the operation ('Get'), the resource ('cookies'), and the scope ('for a URL'). It also enumerates the exact cookie attributes returned (values, domain, expiry, secure, httpOnly, sameSite), which distinguishes it from sibling tools like neuron_get_storage or neuron_set_cookie.

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 'for a URL' implies the tool should be used when cookie information for a specific URL is needed, but it does not explicitly state when to prefer this over alternatives like neuron_get_storage, neuron_set_cookie, or neuron_delete_cookie. No exclusions or conditions 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?

No annotations exist, so the description carries the full burden of behavioral disclosure. 'Get' implies a read operation, but the description does not state whether errors are cleared, how 'recent' is defined, whether results are scoped to a tab/platform, or what the response structure looks like. This leaves meaningful behavioral traits undisclosed.

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 conveys the core purpose without wasted words. It is appropriately sized for the tool's apparent simplicity.

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 no annotations and no output schema, so the description is the agent's only source of behavioral and return-value context. It omits parameter semantics (tabId, platform), scoping rules, and any indication of output shape, making it incomplete for reliable invocation. A few added sentences could close these gaps.

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

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

Schema description coverage is only 33% (only 'limit' has a description). The description itself adds no parameter meaning; 'tabId' and 'platform' remain unexplained in both the description and schema. The description's mention of 'HTTP requests' and 'console errors' does not map these parameters to behavior.

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 ('Get') and resource ('recent failed HTTP requests (4xx/5xx) and console errors'), which clearly distinguishes it from siblings like neuron_get_requests (all requests) and neuron_get_logs (logs). It is unambiguous about what the tool returns.

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 explicit when-to-use guidance or alternative tool references are provided. The description implies it is for error inspection but does not state when to prefer it over neuron_get_requests, neuron_get_logs, or neuron_session_diagnostics. The agent must infer usage from the resource 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 provided, the description carries the full burden. The verb 'Get' plus 'recent' implies a non-destructive, time-bounded read, which is the key behavioral trait. However, it doesn't disclose the return shape, the default time window behind 'recent', or whether retrieving logs drains/clears the buffer — gaps that matter more because no annotations or output schema exist.

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

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

A single sentence that front-loads the verb and resource, states the scope ('recent'), and enumerates the filter dimensions. Every word earns its place with no filler or redundant restatement of the tool name.

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 tool with five well-documented optional parameters, the definition is minimally viable. But with no output schema and no annotations, the response format, default result limit behavior, and the relationship to siblings like neuron_get_errors remain undisclosed. An agent could call it, but would be guessing about output shape and when it's the right diagnostic 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 100%, so every parameter (limit, tabId, levels, search, sinceMs) already has a description in the schema. The tool description only paraphrases the filters at a high level and adds no detail beyond what the schema supplies, matching the baseline for 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 names a specific verb ('Get'), a distinct resource ('console logs'), and the filter dimensions ('tab, level, and time'), so an agent can grasp the core purpose immediately. It doesn't explicitly differentiate from sibling get_* tools, but the resource is unique enough within the family (vs. errors, requests, ws_frames, cookies) that the basic scope 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?

There is no guidance on when to use this tool versus alternatives. Given many siblings that also retrieve diagnostics (neuron_get_errors, neuron_get_requests, neuron_search_traffic, neuron_get_ws_frames), the description should at least hint at when console logs are the right source, but it offers nothing.

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. 'List all active network mock rules' conveys a read-only operation and explicitly scopes results to active rules, which is useful. It could be more explicit about having no side effects, but the verb 'list' makes the non-mutating behavior reasonably clear.

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. It states the action, the object, and the scope ('all active') 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 zero-parameter, read-only list tool with no output schema, this description is nearly complete. It identifies what the tool returns (active network mock rules) and does not omit any required inputs. It could mention the return format, but the simplicity of the tool makes that a minor gap.

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

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

The tool has zero parameters, so there is nothing for the description to explain about inputs. The baseline of 4 applies here, and the description correctly focuses entirely on the operation and result scope.

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 uses a specific verb ('List') and resource ('active network mock rules'), clearly distinguishing it from mutation siblings like neuron_set_mock and neuron_clear_mocks. The 'active' qualifier adds scope precision, so an agent immediately knows what this tool returns.

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 no explicit guidance on when to use this tool versus alternatives. It does not mention that this is the read counterpart to set_mock or clear_mocks, nor does it state any situation where this tool should be preferred. Usage is only weakly implied by the verb 'List'.

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 burden of disclosing behavior. It communicates that the tool reads from ephemeral ring buffers and supports filtering, implying a non-destructive query. However, it does not mention return format, pagination, rate limits, or any side effects, leaving behavioral transparency incomplete.

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 redundant words. It places the core action and resource first, followed by the filter dimensions in a compact list.

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

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

For a tool with 7 optional parameters, no output schema, and no annotations, this description is too thin. It omits the return shape, default limit behavior, filter combination semantics, and any relationship to similar traffic-related tools. An agent would need to inspect schemas or experiment 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 description coverage is only 29%, with meaning absent for tabId, method, platform, statusMin, and statusMax. The description merely lists these filter categories without explaining value formats, ranges, or how filters combine. It adds minimal semantic value beyond the schema property names.

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 uses a specific verb + resource ('Query recent HTTP requests') and names the data source ('the extension's ring buffers') plus available filter dimensions. This clearly distinguishes it from sibling logging tools like get_logs, get_errors, and get_ws_frames, which target different resources.

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 implies when to use the tool: whenever an agent needs recent HTTP request data filtered by tab, platform, status, method, or URL. However, it provides no explicit guidance about alternatives such as neuron_search_traffic or neuron_export_har, and it does not state when not to use this tool.

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

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

The description discloses a valuable behavioral detail: values are truncated at 500 chars. It also labels the operation as 'Read', implying non-destructive behavior. With no annotations provided, it carries the behavioral burden reasonably but does not mention what happens with missing storage, the response shape, or whether both storage types are returned together.

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 that states the verb, resource, scope, and a key truncation limit without wasted words. Every part contributes to the agent's understanding.

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 tool with two parameters and no output schema, the description plus schema is nearly sufficient. It could be slightly improved by clarifying the response format and emphasizing that tabId identifies the page being read, 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?

The schema already describes both parameters completely, with 100% schema description coverage. The description reinforces the 'localStorage or sessionStorage' choice but does not add meaning beyond the schema, so the baseline score of 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 uses a specific verb ('Read') and resource ('localStorage or sessionStorage entries'), with an explicit scope ('for the current page'). An agent can clearly distinguish this from sibling tools like neuron_clear_storage or neuron_get_cookies, since the resource and operation 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?

The intended use is implied by the description: when an agent needs to inspect browser storage for a page, this is the tool. However, it does not explicitly state when not to use it or point to alternatives, so the guidance relies on inference rather than explicit routing.

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

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

With no annotations provided, the description carries the burden of conveying behavior. It clearly signals a read operation ('Get') and adds meaningful context with 'active' and 'accumulated changes', implying no destructive side effects and that the tool returns state gathered over time. It does not explicitly say it avoids clearing watches, but nothing suggests 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?

A single, front-loaded sentence with no filler. Every word contributes: 'Get' sets the action, 'active element watches' defines scope, and 'accumulated changes' describes the returned content.

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 getter, the description explains what the tool returns and the scope of that return. Without an output schema, the exact shape of 'accumulated changes' is unspecified, but the essential call intent is clear and complete enough for an agent to use it correctly.

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

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

The tool has zero parameters and schema description coverage is 100%, so the schema is fully complete. The description adds meaning about the operation's focus on active watches and accumulated changes, which aligns with the empty input contract. Baseline for zero-parameter tools 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 uses a specific verb ('Get') and resource ('active element watches'), and explicitly mentions the payload ('accumulated changes'). This clearly differentiates it from sibling tools like neuron_watch_element (creates watches) and neuron_stop_watch (removes them).

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

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

The description implies this is the retrieval counterpart to watch operations, but it does not explicitly state when to use it versus neuron_watch_element, neuron_stop_watch, or other inspection tools. An agent can infer it is for reading current watch state, but no direct guidance or exclusions 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?

No annotations are provided, so the description carries the full disclosure burden. The verb 'Query' weakly implies a read-only operation, but nothing is disclosed about what is returned, whether frames are live-captured or persisted, how unfiltered queries behave, session requirements, or pagination. A single verb is insufficient behavioral context for a data-retrieval tool with zero annotation coverage.

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 sentence with zero wasted words, and the resource plus primary filter are front-loaded. It is efficient, though it arguably trades too much instructive content for brevity given the tool's four optional filter dimensions.

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 query tool with no output schema, no annotations, and a sibling list of ~90 tools including several overlapping traffic/network queries, a single clause is incomplete. Missing: return shape, interaction between the three enum filters, default behavior when filters are omitted, and how it differs from neuron_search_traffic or neuron_get_requests.

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

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

Schema description coverage is only 25% (just the limit parameter is documented), so the description must compensate. It partially does by clarifying that platform is the key filter ('by platform'), but the semantics of direction (send/recv) and transport (ws/sse) are left entirely to enum inference, and limit is already covered by the schema. Three of four parameters receive no added meaning from the description.

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

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

The description names a specific verb (Query), a specific resource (WebSocket frame history), and the primary filter dimension (platform). The 'WebSocket frame' qualifier distinguishes it from sibling network tools like neuron_get_requests and neuron_get_logs, though it never explicitly names its closest sibling alternatives (neuron_search_traffic, neuron_export_har), leaving full differentiation to inference.

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 zero guidance on when to use this tool versus the dense field of traffic-related siblings (neuron_search_traffic, neuron_get_requests, neuron_export_har, neuron_waterfall). No conditions, exclusions, or alternatives are stated, so an agent trying to locate WebSocket frame data has no explicit routing help.

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 takes on the transparency burden and succeeds: it discloses the multi-step side-effecting workflow (navigating, playing media, capturing network traffic, initiating a browser download). It also states the return information. It stops short of warning about DRM/auth/blocked sites, but the core behavior is transparent.

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?

All sentences contribute: purpose, method, supported scope, and return value. The platform/format list is long but functional, and the main purpose is front-loaded.

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

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

For a no-output-schema tool with a multi-step workflow, the description explains enough to invoke it: what happens, how it finds media, and what is returned. It is slightly vague about the shape and meaning of 'download status' and silent on failure cases, but no critical selection or invocation detail 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 100%, so the schema already documents all five parameters, including defaults and optionality. The description adds no parameter-specific detail 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 uses an action verb ('Extract and download') and a concrete resource ('video/audio from any page'), then lists target platforms and media formats. It is easily distinguished from the surrounding navigation/inspection tools, though it never explicitly differentiates itself from neuron_grab_media_batch.

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

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

It implies use on pages containing embedded video and enumerates supported platforms, which gives the agent a strong context signal. It does not state when to prefer an alternative (notably neuron_grab_media_batch for multiple URLs) or call out exclusions and limitations.

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

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

With no annotations, the description carries the burden, and it does disclose the main workflow: opens tabs, extracts streams, downloads, and returns per-URL status/failures. However, it omits side effects like filesystem writes, auth needs, and potential page navigation impacts.

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 with no filler. The core action, batch behavior, limit, and return outcome are all front-loaded, and usage context is given at the end.

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

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

For a batch download tool with simple, fully documented parameters and no output schema, the description covers the essential workflow and result format. Minor missing details around authentication and filesystem side effects keep it from a 5.

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 schema already documents all three parameters. The description adds the batch framing and the 5-URL cap, but does not clarify delayMs or outputDir behavior beyond the schema.

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

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

States a specific verb and resource ('Download videos from multiple URLs') and clearly indicates batch behavior. The name and description make it distinguishable from the singular neuron_grab_media sibling, though it never names the alternative 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?

Provides clear use cases: 'Use for batch downloading from feeds, trending pages, or saved lists.' It does not state when to prefer the singular variant or when not to use the tool, so it stops just short of full 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?

No annotations are provided, so the description carries the burden of behavioral disclosure. It does add context by mentioning 'platform detection and capture counts', but it does not clarify whether the operation is read-only, what exactly 'capture counts' means, or any side effects. The word 'List' implies safety but not explicitly.

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 sentence that front-loads the action and resource, making it efficient and scannable. The trailing 'with platform detection and capture counts' is concise but slightly vague, which cost it a perfect score.

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

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

For a 0-parameter tool, the description is mostly sufficient, but without an output schema, the agent is left guessing what 'capture counts' refers to and whether there are any side effects. A clearer statement of the return value or the meaning of 'platform detection' would complete the picture.

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 zero parameters, so there is nothing for the description to explain. The baseline for a 0-parameter tool is 4, and the description does not need to add anything.

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 clearly states the verb 'List' and the resource 'open Chrome tabs', making the core function unambiguous. It is distinct from sibling tools like neuron_open_tab, and the additional qualifier about platform detection and capture counts adds scope, though it is somewhat ambiguous.

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 usage context is implied by the phrase 'List open Chrome tabs' — an agent needing to see open tabs would recognize this tool. However, there is no explicit guidance about when to use this tool versus alternatives, or any 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 provided, the description carries the full burden of behavioral disclosure. It implies a read-only operation through the word 'List', but it does not disclose output format, ordering, filtering behavior, 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 sentence with no filler or redundant phrasing. Every word contributes to the meaning, and the core action and target resource are front-loaded.

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, read-only listing tool, the description is largely complete. It clearly states what will be listed, and the absence of an output schema is mitigated by the straightforward nature of the operation, though no return-format details are given.

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 zero parameters and 100% schema description coverage, so there is no parameter information for the description to add. The baseline of 4 applies because the description is not required to explain parameters that do not exist.

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 uses a specific verb ('List') and resource ('all saved workflow recordings'), making the core purpose clear. It distinguishes itself from related recording and replay tools by focusing on listing saved recordings, though it does not explicitly name any sibling alternative.

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 is provided about when to use this tool versus related tools such as neuron_workflow_status, neuron_start_recording, or neuron_recipe_list. The description states what the tool does but gives no context for choosing it over alternatives.

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 discloses the snapshot-before/action/diff-after workflow and the wait-then-diff behavior, which is useful. However, it does not describe the output shape, potential side effects of the underlying action, or any permission/auth considerations.

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

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

The description is two tight sentences with no filler. The mechanism is front-loaded and the value proposition and usage context follow immediately, making it easy for an agent to absorb quickly.

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, nested action objects, and no output schema, the description covers the core workflow, the action types, and the main use case. The schema handles parameter details, and 'diff to see what changed' signals the result type, though explicit return formatting is not described.

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 the schema already documents all parameters and nested action fields. The description adds little beyond restating the action types, which aligns with the schema but does not provide new semantic value.

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 clearly states a composite operation: snapshot page state, perform an action, then diff to see what changed. It names the specific action types (click/type/navigate) and explicitly distinguishes itself from the primitive snapshot→click→wait→snapshot→diff chain, so an agent can separate it from sibling tools like neuron_click or neuron_diff_states.

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 a concrete use case: verifying that a button click, form submit, or navigation did what was expected. It also explains that one call replaces a multi-step chain, implying when to choose this tool over composing individual sibling calls, though it does not explicitly list when-not-to-use scenarios.

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 burden of behavioral disclosure. It clearly indicates a read-style retrieval operation with no destructive intent, but it does not disclose ordering, time windows, retention, or whether returned alerts are consolidated or raw. For a simple getter this is adequate but not rich.

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 concise sentence with the key action ('Get recent alerts') front-loaded and the clarifying parenthetical ('triggered conditions') directly after. No filler or redundant content.

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 one-parameter retrieval tool with no output schema, and the description adequately states what the agent will receive: recent alerts/triggered conditions from monitors. It could have included what fields each alert contains, but the existing description is sufficient for correct invocation at a basic 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?

The only parameter, 'limit', is already fully documented in the input schema with a description and default value. Thus schema description coverage is 100%, and the description does not need to repeat parameter details. It adds no additional parameter-level meaning.

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 uses a specific verb ('Get') and resource ('alerts from monitors'), and clarifies that alerts mean triggered conditions. This clearly differentiates it from sibling monitor tools such as monitor_list, monitor_check, or monitor_create, which serve different purposes.

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 implies usage as the way to retrieve recent monitor alerts, but it does not explicitly discuss when to use it instead of alternatives like neuron_monitor_check or neuron_monitor_action. It provides no exclusion criteria or when-not-to-use 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, the description carries the full behavioral transparency burden. It reveals that the operation forces an immediate check and can target all monitors, which is useful. However, it does not disclose side effects, return behavior, or whether monitors must be enabled; the schema partially adds the 'enabled' qualifier.

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. It conveys the action, target, and the optional behavior 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 trigger tool, the description plus schema is largely sufficient. It covers what the tool does and the all-monitors fallback. Minor gaps include lack of return/outcome details and prerequisite conditions, but these are not critical for basic invocation.

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

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

Schema description coverage is 100%, so the monitor_id parameter is already documented. The description adds little beyond the schema—it restates the omitted-ID behavior rather than introducing new semantic detail. 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 the exact action—'Force an immediate check'—on a specific resource ('a monitor' or 'all monitors' if no ID is provided). It clearly differentiates this from sibling monitor tools like create, list, remove, alerts, and action by describing a distinct trigger/check behavior.

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 implies when to use the tool: when an immediate monitor check is needed, and it explains the optional monitor_id behavior. It does not explicitly name alternatives or say when not to use it, so it stops short of full 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?

There are no annotations, so the description carries the transparency burden. It does disclose key behavioral traits: monitors are persistent, run in the background, and alert when conditions are met. It stops short of explaining how alerts are delivered or whether resource consumption should be expected, but it does not hide the side-effecting nature of creation.

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

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

The description is two sentences with no filler. The first sentence front-loads the action, resource, and purpose; the second adds the background-interval behavior. Every sentence contributes useful 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 selecting and invoking the tool, the description plus the fully-described schema are sufficient: required parameters are unambiguous, defaults are documented, and the condition options are enumerated. The main missing detail is the return value or alert-delivery mechanism, but since no output schema exists and this is a create operation, the invocation path is still clear.

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 five parameters already have meaningful descriptions, including the nested condition object and defaults. The tool description adds high-level examples but no parameter-specific semantics beyond what the schema provides. 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 identifies a specific action and resource: 'Create a persistent page monitor' that watches a URL and alerts on condition changes. The word 'persistent' and the background-execution detail differentiate it from one-off inspection tools, though it does not explicitly contrast it with sibling monitor/watch tools. Overall, an agent can tell what this tool does.

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 concrete use cases: price drops, new job postings, content changes. It clearly conveys that this is for ongoing background monitoring rather than immediate DOM queries. It does not explicitly state when not to use it or name alternatives, but the context is clear enough.

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 burden of behavioral disclosure. It clearly indicates a read-oriented listing operation and the data returned, but it does not explicitly state that no check is triggered or that this is a non-mutating operation. Given the existence of neuron_monitor_check, this missing clarification is a small but real gap.

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

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

The description is a single, focused sentence with no filler. It front-loads the action ('List') and the resource ('all monitors'), then gives the relevant output fields.

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

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

For a zero-parameter list tool with no output schema, the description covers the essential return fields and the scope ('all monitors'). It could clarify the scope (e.g., current workspace vs session) or explicitly note that no live checks are performed, but overall it is sufficient for a low-complexity 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?

The tool has zero parameters, so there is no schema burden on the description. The baseline of 4 applies here; nothing is missing because there is nothing to document.

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 uses a specific verb ('List') with a clear resource ('all monitors') and specifies the returned fields (status, last check time, alert count). This makes the tool's purpose immediately clear and distinguishes it from sibling tools like neuron_monitor_check, neuron_monitor_alerts, and neuron_monitor_create.

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 makes the usage context clear: use this tool to get an overview of all monitors and their statuses. It does not explicitly mention alternatives like neuron_monitor_check or neuron_monitor_alerts, but the 'list' framing is unambiguous enough that an agent can select it correctly without much 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?

No annotations are present, so the description carries the full burden of behavioral disclosure. 'Remove' signals a destructive operation, but the description does not state whether the removal is permanent, whether it has side effects on alerts or watches, whether it is idempotent, or how errors such as a missing monitor ID are handled.

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

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

This is a single, focused sentence with no filler. It is appropriately terse for a one-parameter tool and front-loads the core action and target resource.

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 is simple and its one parameter is fully documented, so the description is minimally viable. However, with no annotations and no output schema, an agent is left without information about return behavior, failure modes, or side effects, which would be useful for a destructive operation.

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 the single parameter monitor_id is already fully documented in the schema. The description's 'by ID' phrasing merely restates the parameter without adding semantic detail such as format, source, or validation requirements.

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 ('Remove') and resource ('monitor') with an explicit identifier ('by ID'), making the tool's function immediately clear and distinct from sibling monitor tools like create, list, check, or alerts.

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 intended use is implied: call this when you have a monitor ID and want to delete that monitor. However, there is no explicit guidance about when not to use it, what happens to related resources, or how it differs from other monitor lifecycle 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 are provided, so the description carries the full burden of behavioral disclosure. It reveals only the URL scheme restriction, but says nothing about whether navigation waits for page load, how failures/timeouts are reported, whether the current page state is discarded, or what side effects (script execution, network requests) may follow. For a navigation action that can hang or mutate page state, this is a significant gap.

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

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

A single ten-word sentence with zero waste; the core action, target, and constraint are all present. The parenthetical constraint is efficiently placed without disrupting the main clause. Under-specification is a separate concern handled in other dimensions; as pure conciseness, this is exemplary.

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

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

For a simple two-parameter, fully-documented tool, the core 'what' is adequately covered. However, with no annotations and no output schema, the description should compensate by noting return behavior, failure semantics, or how it differs from same-family navigation tools. It is minimally viable but leaves behavioral and routing gaps an agent must guess at.

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

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

Schema description coverage is 100% (both url and tabId have descriptions), so the baseline is 3. The description adds one piece of meaning beyond the schema—the http/https scheme restriction—which is genuinely useful, but it does not elaborate on URL format expectations or what tabId references. The schema carries the heavy lifting.

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 ('Navigate'), a precise resource ('a tab'), and a target ('to a URL'), which clearly identifies the operation. The '(http/https only)' constraint adds useful scope. It is clear but does not explicitly differentiate from siblings like neuron_open_tab (new tab) or neuron_reload (refresh), so the distinction is implied rather than stated.

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

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

There is no guidance on when to use this tool versus alternatives. With siblings like neuron_open_tab, neuron_reload, and neuron_list_tabs in the same family, an agent receives no hint about which tool fits which scenario. The only constraint ('http/https only') is an input restriction, not usage guidance, so the agent is left to infer 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?

No annotations are provided, so the description must carry the behavioral burden. It clearly discloses the primary side effect of opening a new tab, and the optional URL qualifier adds meaning. However, it does not mention whether the new tab becomes active, whether a blank tab opens when no URL is supplied, or what the return value is.

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 sentence, front-loaded with the action, and contains no filler or redundant information. Every word 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?

The tool is simple, with one optional parameter and no output schema, so extensive documentation may not be required. Still, the description omits details that would help an agent invoke it confidently, such as what happens when URL is omitted, whether the tab is focused, and what result is returned.

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 already describes the single parameter as 'URL to open (optional)' with 100% coverage. The description's phrase 'optionally to a URL' adds no additional semantic detail such as URL format, default behavior, or validation rules, so the baseline schema coverage determines the score.

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 ('Open') and resource ('a new tab'), and clarifies the optional URL behavior. It does not explicitly name sibling alternatives like neuron_navigate, but 'new tab' makes the distinction reasonably 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?

There is no guidance on when to use this tool versus alternatives such as neuron_navigate, neuron_reload, or neuron_list_tabs. The description gives no context about switching tabs or invoking the current tab versus opening a fresh one.

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 disclosure burden. It does disclose the scope of captured data in detail, which is genuine behavioral transparency about the output. However, it omits side effects (e.g., whether it injects JS into the page), measurement semantics (e.g., whether LCP/CLS measurement requires a navigation or reload), and whether the operation is read-only — material gaps for a profiling 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 the action verb front-loaded, followed by a dash and a compact enumeration of the captured metrics. Every clause carries information and there is zero filler or repetition of schema content.

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 thoroughly answers 'what will I get back' by enumerating the snapshot contents, which is the core question given no output schema. It falls short on side-effect disclosure, prerequisites (e.g., a loaded/settled page), and usage boundaries versus performance-adjacent siblings — real gaps for a tool with no annotations to back it up.

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% — tabId is documented as 'Chrome tab ID to profile' — so the schema owns parameter documentation. The tool description adds no parameter-specific detail beyond contextualizing what 'profile' means via the metric list, which matches the baseline of 3 for high schema 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 pairs a specific verb ('Capture') with a specific resource ('performance snapshot') and enumerates eight distinct metric categories (LCP, CLS, TTFB, FCP, resource breakdown, slow resources, blocking scripts, memory, long tasks). This inventory functionally separates it from close siblings like neuron_waterfall and neuron_session_diagnostics, which are not all-in-one performance captures.

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 metric list strongly implies the tool is the go-to for holistic performance profiling, so usage context is inferable. However, the description never states when not to use it or names an alternative such as neuron_waterfall for request-level timing or neuron_get_requests for traffic data, leaving the boundary to the agent's judgment.

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 burden. It transparently states this is a read operation on a specific file and what the profile is used for. It does not cover error behavior if the profile is missing, but for a simple no-parameter getter this is sufficient.

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 concise, information-dense sentences. The core action and file path are front-loaded, and the explanation of profile variables adds value without redundancy.

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

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

Given the tool's simplicity, the description adequately explains what the tool does and what the profile contains. It could mention the return format or missing-file behavior, but these are minor gaps for a no-parameter read operation without an output 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?

The tool has zero parameters and the input schema is empty, so there is nothing to document. The description correctly focuses on resource and behavior rather than parameter details.

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 ('Read') and a specific resource (the user's profile at ~/.neuron/profile.yaml), and explains the purpose (auto-filling recipe variables). It is clearly distinguishable from the sibling neuron_profile_save, which is the write counterpart.

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 clearly implies when to use this tool: when you need the user's profile values such as name, email, location, tone, or timezone for recipe variables. It does not explicitly mention exclusions, but the read/write distinction from neuron_profile_save is implicit and 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?

No annotations are provided, so the description carries the full behavioral burden. It does disclose the persistent target path and a meaningful side effect (recipe variables auto-fill from saved data), which goes beyond a bare 'save' statement. However, it omits whether updates merge with or completely replace the existing profile, and says nothing about return behavior or required permissions.

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

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

Three sentences with zero filler, front-loaded with the verb+resource in the first sentence. The common-fields list and the recipe auto-fill side effect each earn their place by adding 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 simple one-parameter tool with full schema coverage and no output schema, the description covers what the tool does, where it writes, which fields are expected, and a downstream behavioral consequence. The main gap is merge-vs-overwrite semantics for partial updates, which is a meaningful operational detail for a save/update tool, but the description is otherwise sufficiently 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?

The data parameter is already fully documented in the schema (100% coverage) with a concrete example, so the baseline is 3. The description adds genuine value by enumerating the recognized common fields (name, email, location, timezone, tone, linkedin, github) that the open additionalProperties schema does not constrain or list. This helps an agent choose meaningful keys when constructing the data object.

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 ('Save or update') and a concrete resource ('the user's profile (~/.neuron/profile.yaml)'). The explicit file path anchors the tool's scope and distinguishes it from write-siblings like neuron_session_save and read-siblings like neuron_profile_get. An agent can tell exactly what resource this acts on without inspecting 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?

The recipe auto-fill sentence ('Recipe variables with matching keys are auto-filled from this profile') hints at when this tool's output matters, but the description never names the obvious alternative neuron_profile_get or states when not to use this tool. Usage context is implied through the recipe relationship rather than explicitly stated.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It implies a read-only snapshot but does not state what the returned snapshot looks like, whether it waits for the page to settle, or any side-effect/performance caveats.

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 an active verb, a clear resource, and scope. There is no filler or redundant content.

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 relatively simple tool with fully documented parameters, the description is mostly sufficient to invoke it. However, since there is no output schema and no annotations, the description does not explain the shape of the returned DOM snapshot, which an agent would need to reliably consume the result.

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?

All three parameters are fully described in the schema with defaults, so the description adds little beyond the schema. 'Active page or targeted subtree' loosely maps to the body default and selector parameter, but provides no new semantic detail.

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

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

The description names a specific action ('Capture') and resource ('DOM snapshot'), and scopes it to the active page or a targeted subtree. It is clear, though it does not explicitly differentiate from closely related siblings like neuron_find_elements or neuron_evaluate_js.

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 implies the tool is for capturing DOM snapshots, and the selector/depth parameters clarify the scoping. However, it provides no explicit guidance about when to prefer a sibling tool or when not to use this one.

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 explains the tool checks connection status, lists recipes, checks profile existence, and suggests an action. This discloses the behavioral scope without obscuring side effects, though it does not describe the response shape or what happens if the connection fails.

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

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

The description is two sentences with no filler. It front-loads the core concept ('First-run onboarding') and then gives concrete behavioral detail and a usage trigger, making every sentence valuable.

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 onboarding tool, the description is complete enough: it explains what the tool does and when to invoke it. It does not describe return values or edge-case behavior, but no output schema exists and the tool's simplicity reduces the need for deeper detail.

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 input schema has zero parameters, so parameter guidance is unnecessary. Per the rubric, zero-parameter tools receive a baseline of 4, and the description adds no conflicting or confusing parameter information.

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 a specific purpose: first-run onboarding for neuron-inspector. It names the concrete actions performed—checking extension connection status, showing available recipes, checking for a user profile, and suggesting a first action—which clearly distinguishes it from the many 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 description gives an explicit trigger condition: 'Call this when you first connect to neuron-inspector and aren't sure where to start.' It does not name alternatives or explicitly say when not to use it, but the context is clear enough for a zero-parameter quickstart tool.

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 disclosure burden and does reveal substantive behaviors: calling the tool automatically logs the outcome to recipe memory (a side effect), and the evolve-phase update is gated on memory-entry count. It does not disclose error states (e.g., no active run to complete) or whether completion is final/irreversible, which would round out the behavioral picture.

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

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

Four short sentences with the core purpose front-loaded in the first sentence. Each subsequent sentence earns its place: auto-logging behavior, outcome structure guidance, and the conditional learnings rule. There is no filler, no repetition of schema content, and no ambiguity in ordering.

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 invocation contract is well covered: when to call, how to shape the outcome, and when to include learnings. Because there is no output schema, a brief note on return values would be useful, and error conditions (such as completing a run that has no active state) are undocumented — but these are minor gaps for a conceptually simple finalization tool whose prerequisites are clearly tied to neuron_recipe_run.

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 baseline is 3, but the description adds meaning beyond the schema: it ties outcome structure to the recipe's Reflect section ('Provide the outcome data matching the recipe's Reflect section') and adds the conditional trigger for updated_learnings (5+ memory entries) that the schema's generic persistence note lacks. This gives an agent decision rules the schema alone does not.

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 uses a specific verb ('End') with a clear resource ('a recipe run started with neuron_recipe_run'), immediately positioning itself in the run lifecycle and distinguishing it from neuron_recipe_run (starts) and neuron_recipe_log (manual logging). The phrase 'Logs the outcome to the recipe's memory automatically' further differentiates it from the overlapping sibling neuron_recipe_log.

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 establishes clear usage context: it is the terminal partner to neuron_recipe_run ('End a recipe run started with neuron_recipe_run'), and it provides a conditional rule ('If the recipe has 5+ memory entries, also return the learnings'). However, it does not explicitly contrast with the overlapping alternative neuron_recipe_log or state when NOT to use this tool, so exclusion guidance is implicit 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 of disclosing side effects. It clearly states that a new recipe is saved to ~/.neuron/recipes/<slug>/ and describes the required file contents. However, it does not mention duplicate-slug behavior, overwrite semantics, validation, or what the tool returns.

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

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

The description is three sentences with no filler. It front-loads the purpose, then efficiently packs required input fields, file roles, and the destination path into tight parentheticals.

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 create operation with 5 required params and no output schema, the description gives enough to invoke correctly: inputs, file structure, and save location. It is incomplete on edge behavior like what happens if the slug already exists and what the expected response/confirmation is.

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 the baseline is 3. The description adds useful file context by mapping agent_md to 'agent.md content' and recipe_yaml to 'recipe.yaml content', but the schema already documents the required sections, so the added value is limited.

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 'Create a new recipe from scratch', which is a specific verb and resource. It also defines what the recipe consists of (agent.md and recipe.yaml) and where it is stored, distinguishing it from sibling tools like recipe_update and recipe_import.

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 'from scratch' provides clear context that this is for creating a brand-new recipe rather than updating or importing an existing one. It does not explicitly name alternatives or list when-not conditions, 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?

With no annotations provided, the description carries the full behavioral disclosure burden. It transparently discloses that the operation removes not just the recipe but also all associated memory/learnings, which is a meaningful side effect beyond the obvious 'delete'. It could mention irreversibility or behavior on bundled recipes, but the core destructive scope is clearly stated.

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 main object, followed by a concise limitation. Every word carries information, and there is no redundancy or 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 single-parameter deletion tool with no output schema, the description captures the essential behavior, target resource, side effects, and a key limitation. It does not explain error behavior for non-existent slugs or running recipes, but these are relatively minor omissions for such a simple 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 100%, so the baseline is 3. The tool description adds meaning to the slug parameter by clarifying it must refer to a user-installed recipe and not a bundled one, which is not stated in the schema's generic 'Recipe slug to delete' description.

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

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

The description uses a specific verb ('Delete'), names the exact resource ('user-installed recipe'), and adds scope ('and all its memory/learnings'), which clearly sets it apart from sibling recipe tools like recipe_update, recipe_get, or recipe_run. It also notes the bundled-recipe limitation, further clarifying what this tool is 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?

The description states when to use it: to delete a user-installed recipe, and explicitly says bundled recipes cannot be deleted, giving a clear when-not condition. It does not name alternative tools, but no alternative deletion tool exists among siblings, so the omission is minor.

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 a key boundary (memory/run history is never exported) and the optional learnings behavior, but it does not say what the export actually returns, where it goes, 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?

Two tight sentences: the first states the deliverable and options, the second names the counterpart and the key exclusion. No filler or repeated schema content.

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

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

For a simple two-parameter tool with no output schema, the description covers what is exported, what is optional, and what is never included, which is enough for correct selection and invocation. The only notable gap is the unstated output form/location.

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 baseline is 3. The description adds some meaning by mapping include_learnings to 'optionally learnings' and identifying the exported files, but it does not materially deepen parameter semantics beyond the schema.

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

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

Description names the exact verb and resource: exporting a recipe's shareable contents with a specific file list (agent.md, recipe.yaml, optionally learnings). It also names the reciprocal sibling (neuron_recipe_import), distinguishing this from the many other recipe and export 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 description frames this as the sharing/transfer mechanism and explicitly connects it to neuron_recipe_import, giving clear context for when it is the right tool. It does not enumerate exclusions or alternative conditions, but the purpose is specific enough that an agent can route 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 are provided, so the description carries the full burden. It implicitly conveys read-only behavior via 'Get' and 'before running it', and it lists what the call returns. However, it does not explicitly mention lack of side effects, error behavior, or auth requirements, leaving minor 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?

The description is exactly two sentences with no filler. The primary action and key contents are front-loaded, and the usage sentence earns its place by adding practical 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?

For a simple tool with one required parameter and no output schema, the description is largely complete: it explains what is returned and when to use it. It omits response format and error details, but those are less critical at 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?

The input schema already provides 100% coverage for the single 'slug' parameter, including an example. The description adds no additional parameter-level meaning, so the baseline score of 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 opens with 'Get a recipe's full contents', clearly stating the action and resource. It enumerates the specific components returned (agent.md, recipe.yaml, accumulated learnings, variable definitions), which distinguishes it from siblings like neuron_recipe_run and neuron_recipe_list.

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

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

The second sentence gives an explicit use case: 'Use this to understand what a recipe does before running it.' This is a clear context for when to use the tool, but it does not name alternative tools or state explicit when-not-to-use conditions, so it doesn't reach the 5-level of 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 present, the description carries the behavioral disclosure burden. It reveals side effects and behavior: imported recipes are saved to ~/.neuron/recipes/, GitHub imports pull all recipes from recipes/, and memory is stripped on import. The 'local-only' parenthetical is slightly ambiguous, but the description still discloses meaningful behavioral traits beyond the schema.

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: it states the purpose first, explains the two source variants, then gives the save location and a caveat. Every sentence earns its place without unnecessary 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 single-parameter import tool with no output schema or annotations, the description covers the source format, destination, and a notable side effect. It is slightly incomplete around overwrite behavior, return value, and the exact meaning of 'local-only', but it is otherwise sufficient for correct 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%, so the baseline is 3, but the description adds extra meaning to the single 'source' parameter by explaining the exact GitHub syntax, the recipes/ subdir rule, and the local path requirement for recipe.yaml. This goes beyond the schema's short parameter description.

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

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

The description clearly identifies the verb 'import' and the resource 'recipe', and distinguishes this tool from siblings like neuron_recipe_create and neuron_recipe_export. It also specifies two distinct source modes (GitHub and local path), leaving no ambiguity about what the tool does.

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 concrete context for when to use the GitHub form versus the local path form, including expected source formats and the recipes/ subdir convention. It does not explicitly name alternatives or say when not to use this tool, but the usage context is clear and actionable.

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 disclosure burden. It goes beyond a bare 'list recipes' by specifying exactly what the output shows: name, description, accumulated learnings, and run count. This gives the agent a good sense of the tool's return value, though it does not explicitly state side-effect-free behavior.

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 with no filler. The primary action and scope are front-loaded, and the second sentence efficiently enumerates the output fields. Every word earns its place.

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

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

For a zero-parameter list tool with no output schema, the description is fully adequate. It identifies what the tool does and what information will be returned, which is sufficient for an agent to select and invoke it correctly.

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

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

The tool has zero parameters, so there are no parameter semantics to document. The baseline for a no-parameter tool is 4, and the description correctly focuses on the tool's output rather than nonexistent 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 description states a specific verb ('List'), a clear resource ('all available recipes'), and the scope ('bundled + user-installed'). This differentiates it from sibling tools like neuron_recipe_get, neuron_recipe_run, and neuron_recipe_create without needing to inspect their schemas.

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 makes it clear this is the enumeration/discovery tool for recipes, which gives clear context for when to use it. It does not explicitly state when-not-to-use alternatives such as neuron_recipe_get, but the 'list all' phrasing sufficiently implies the selection for a listing task.

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 behavioral disclosure burden. It explains the side effect (writing an entry to recipe memory), the kind of data captured, and how the data is later used, which gives the agent a good model of the tool's behavior beyond the name.

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 with no filler. The core action is front-loaded, and each sentence adds useful information: what is logged, what the entry contains, and why it matters.

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

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

For a simple two-parameter logging tool with no output schema, the description covers the essential context: what the tool does, what data goes in, and where to find further structural guidance. It could mention result/return behavior or validation of the slug, but those are minor gaps for this operation.

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 already documents both parameters, and the description adds concrete example fields such as success/failure, sources found, dead ends, and quality score for the free-form entry object. It also points to the Reflect section in agent.md for recipe-specific structure, which is valuable since the entry schema is intentionally open-ended.

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: log a run outcome to a recipe's memory. It clearly identifies the operation's purpose and distinguishes it from the broader recipe management tools in the sibling list, though it does not explicitly contrast it with the closely named neuron_recipe_memory.

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 implies when to use the tool — after a recipe run, when there is an outcome to record — and notes that the evolve phase consumes these logs. It does not explicitly state when not to use it or how it relates to alternatives such as neuron_recipe_complete or neuron_recipe_memory.

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 burden of behavioral disclosure. It conveys that the operation is a read ('Read') and that results are ordered by recency ('Returns the most recent entries'), which is useful. However, it does not disclose return format, pagination behavior, handling of empty history, or any failure conditions.

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

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

The description is two sentences with no redundancy. It front-loads the core action ('Read a recipe's run history'), states the source, describes the return behavior, and gives usage context — all without wasted words.

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 tool with two parameters and no output schema, the description covers the main points: what is read, where the data comes from, what is returned, and when to use it. The absence of return-value details is a minor gap, but the description is sufficiently complete for an agent to select and invoke the tool correctly.

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

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

Schema description coverage is 100%, so the parameters are already fully documented in the schema. The description adds no additional parameter-level meaning beyond the schema. The mention of 'most recent entries' loosely relates to the limit parameter, but the schema already explains that. 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 uses a specific verb ('Read') and resource ('a recipe's run history'), and clarifies the data source (neuron_recipe_log). It clearly states the tool returns the most recent entries. However, it does not explicitly distinguish itself from the sibling tool neuron_recipe_log, 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?

The description provides clear usage context: 'Use during the evolve phase to analyze what's working and what's not.' This tells an agent when to use the tool. It does not mention when not to use it or name alternative tools, so it lacks full 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?

With no annotations, the description carries the burden of explaining side effects. It discloses that rules are injected as 'non-negotiable constraints that override recipe strategy' and that variables are auto-filled from profile, which reveals precedence and stateful behavior. It doesn't mention the return value or broader side effects, but the key behavioral traits are covered.

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

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

Three sentences with no redundancy: the first states the action, the second enumerates what gets loaded, and the third explains rule precedence and the follow-up call. Every sentence earns its place and the core behavior is front-loaded.

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 informative about inputs and execution behavior, but there is no output schema and the description fails to state what the tool returns (e.g., a run ID or status). Since the agent is told to call neuron_recipe_complete afterward, knowing what identifying information is returned is essential for correct invocation. This missing detail is a clear gap.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining that variables are interpolated into agent.md, auto-filled from profile, and that rules override recipe strategy. This enriches the schema's dry 'merged on top' phrasing with execution context.

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 resource, 'Start a recipe run', immediately identifying the tool's function. It then details what the run loads (agent.md, learnings, resolved variables, active rules), clearly distinguishing it from sibling recipe tools like neuron_recipe_list or neuron_recipe_complete.

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 provides clear context for when to use this tool: to initiate a recipe run, and it explicitly instructs to call neuron_recipe_complete when done. However, it does not explicitly state when not to use it or name alternatives for other operations (e.g., inspecting recipes), leaving the differentiation mostly implicit.

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

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

With no annotations provided, the description carries full disclosure burden and does substantial work: it reveals the non-obvious side effect that bundled recipes are forked to ~/.neuron/recipes/ before modification, meaning the operation is not an in-place edit for bundled recipes. It also signals persistence/mutation intent. It doesn't cover error behavior or existence preconditions, but the forking disclosure is genuinely valuable beyond what annotations would typically say.

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

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

Three sentences, each with a distinct job: what the tool does, the critical side effect, and when to use it. Purpose is front-loaded and there is zero filler or repetition of schema content.

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

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

For a mutation tool with 4 parameters, no annotations, and no output schema, the description covers the essentials: operation scope, a significant side effect, and lifecycle timing. Minor gaps remain — it doesn't state that slug must reference an existing recipe or describe the success/error return shape — but these are small against the strong forking disclosure.

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 the baseline is 3. The description adds only a light semantic gloss by mapping 'agent instructions,' 'learnings,' and 'configuration' to the agent_md, learnings, and recipe_yaml parameters. It does not clarify partial-update semantics, though the schema already implies it by requiring only slug.

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: 'Update a recipe's agent instructions, learnings, or configuration,' which maps cleanly to the three content parameters. The lifecycle phrase 'after the evolve phase to persist improved strategy' further separates it from recipe creation and execution siblings. However, it never explicitly names a sibling alternative (e.g., neuron_recipe_create), so it stops short of full differentiation.

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

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

The final sentence gives explicit usage timing: 'Use this after the evolve phase to persist improved strategy,' which tells an agent precisely when this tool applies in the recipe lifecycle. The forking clause also implicitly scopes it to bundled-recipe updates. It does not state when not to use it or name alternative tools, so it misses the top score.

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 burden of behavioral disclosure. 'Reload a tab' discloses only the literal action, omitting side effects (losing unsaved page state), wait/finish semantics, behavior on an invalid tabId, and return value. The action implies mutation of page state, but the description gives no context about its consequences.

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 three words with zero filler and the action verb is front-loaded. For a single-parameter tool, this is appropriately sized, though it borders on under-specification in other dimensions. It earns its place but doesn't go beyond it.

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's low complexity (one fully documented parameter, no output schema, no nested objects) lowers the bar for completeness. However, with no annotations and no output schema, the description should at least note what happens after the reload (e.g., whether it waits for load, preserves the URL, or errors on a bad tab ID). Adequate for a trivial tool but with a clear gap.

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

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

Schema description coverage is 100%, and the only parameter (tabId) is already documented as 'Chrome tab ID'. The description's 'Reload a tab' adds no new meaning to the parameter beyond what the schema provides. A baseline of 3 is appropriate since the schema does the heavy lifting.

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 'Reload a tab' states a specific verb and resource, making the core action unambiguous. It is semantically distinct from siblings like neuron_navigate, neuron_open_tab, and neuron_list_tabs, though it never explicitly names what it is not. A 5 would require explicit differentiation, but the meaning is clear enough for an agent to 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?

The description provides no guidance on when to use this tool versus alternatives such as neuron_navigate (if the page is stuck) or neuron_open_tab (if the tab doesn't exist). There is no mention of preconditions, like the tab needing to exist, or exclusions. This is a total absence of usage direction, but not misleading, so it doesn't warrant a 1.

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 burden. It usefully discloses that the request runs in the service worker context, inherits browser cookies/session, and that response bodies are truncated at 50KB. However, it does not mention the potentially mutating/side-effecting nature of re-firing requests (e.g., POST/DELETE can change server state), which is a meaningful transparency gap.

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

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

The description is short, front-loaded with the core action, and each sentence earns its place: the mechanism, the modification capability, the Postman analogy, and the response truncation limit. No fluff.

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 covers the key context an agent needs for invocation, including the session behavior and truncation limit, and the schema covers parameter definitions. However, there is no output schema and the description does not specify the response format beyond truncation, leaving the agent uncertain about what the tool returns (status, headers, body shape, etc.).

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 input schema already covers all four parameters with descriptions, so baseline is 3. The description adds that method, headers, and body can be modified before sending, but this is still just a partial restatement of schema capabilities and does not add deeper semantics like accepted header formats or body encoding.

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 clearly identifies the action ('Re-fire an HTTP request'), the resource (an HTTP request), and the execution context (service worker with browser cookies/session). It also distinguishes itself from sibling tools by emphasizing live-session replay with modification capability.

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 clear context: use this when you need to resend a request using the live browser session, like Postman but with session cookies. It does not explicitly name sibling alternatives or state when not to use it, but the tool's purpose is well-scoped enough for an agent to infer appropriate 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 provided, the description carries the full burden and does a solid job, disclosing that the tool navigates, waits for load, scrolls, extracts structured data, captures console errors, and takes a screenshot. It does not mention side effects like switching tabs, opening new tabs, or mutating page state, but the core behavioral profile is clearly communicated.

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: the high-level purpose comes first, followed by a concise behavioral breakdown and a clear replacement directive. Every sentence earns its place with no filler.

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

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

The description covers the tool's main phases and explains why it is useful. Since there is no output schema, a bit more specificity about the returned structured data could help, but the phrase 'Returns everything the AI needs to understand the page' sufficiently covers the intent for a research-oriented 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 100%, so the schema already documents all five parameters well. The description adds contextual color around scrolling and screenshotting but does not provide parameter-level detail beyond that. 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 opens with a specific verb and resource: 'Deep-read a single URL in one call.' It clearly distinguishes this composite tool from the individual step tools by naming the chain it replaces: navigate → scroll → extract → screenshot. The purpose 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 description gives explicit usage guidance: use this tool instead of separate navigate, scroll, extract, and screenshot calls. It conveys the key win (avoiding multiple round-trips) but does not state when the user should prefer the lower-level tools instead, such as when granular control over individual steps is needed.

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 disclosure burden, and it does well: it reveals that tabs are opened, scrolling happens to load lazy content, structured extraction occurs, and results are returned in one response. It does not specify the exact output shape or all browser side effects, but the operational behavior is clearly 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?

Three tightly packed sentences: what it does, its key constraint and benefit, and when to use it. Every sentence earns its place, and the most important functional detail is front-loaded.

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 covers the operation, the batching model, the URL limit, lazy-load handling, and common use cases. Because there is no output schema, a slightly more specific statement about the shape of the returned structured data would make it fully complete.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description adds only the 8-URL cap, which is also present in the schema, so it provides no meaningful semantic lift beyond what structured data already offers.

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