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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that secrets are write-only and never returned, but it omits important mutation behavior such as permissions, atomicity, partial-failure handling, and rate limits.

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

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

Three short sentences, front-loaded with the core operation, followed by the required input detail and the key secret-handling caveat. 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?

The schema is fully documented and the description covers the essential input requirement, but with no annotations and no output schema it should say more about batch results or failure behavior. It is minimally adequate rather than complete for a batch mutation 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 nested fields including platformUrl, username, password, key2fa, teamId, and platformName are already documented. The description adds little beyond repeating that each item needs platformUrl and that secrets are write-only.

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: 'Create multiple platform accounts'. The word 'multiple' distinguishes it from the single-account sibling nex_account_create, and the input shape is named directly as an items array.

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 batch nature implies when to use it, but the description does not explicitly compare it to nex_account_create, state prerequisites, or explain when not to use batch creation. Usage is inferable but not fully guided.

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 does add useful behavior beyond the schema — credentials are optional and write-only, and the tool records a catalog entry rather than performing a login. It omits what happens on duplicate platformUrl, required permissions, and whether an identifier is returned, which matters for a mutation 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?

Three front-loaded sentences: what it creates, what to pass, then the negative disambiguation. No filler, and the required parameter is named before the optional ones.

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

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

There is no output schema and no annotations, and the description covers the creation target, the batch shape, the required field, credential write-only semantics, and one behavioral exclusion. The remaining gap — what identifier comes back — is minor given the schema already documents every field.

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 75%, so the schema already documents platformUrl (with example), username, password and key2fa. The description reinforces the required/optional split and the write-only nature of secrets, but says nothing about teamId, remark, platformName, or how the flat parameters relate to the items array — leaving the parameter surface as documented by the schema alone.

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: create a platform account in the workspace catalog, with singleton-or-array semantics spelled out. It does not, however, differentiate itself from the closely named sibling nex_account_batch_create, which appears to do the same 'several at once' job — an agent has no textual basis for choosing between 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?

"This does not fill a login form" is a real when-not hint that steers away from nex_browser_fill_account / nex_browser_fill_credentials, but neither alternative is named. There is no guidance on when to use this versus nex_account_batch_create, nor any prerequisite (existing team, workspace, permissions).

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 destructiveHint annotation already signals that this is a destructive operation. The description adds meaningful scope: deletion affects the workspace catalog but not open windows or existing vault copies, which clarifies blast radius beyond the annotation.

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 the core action front-loaded. The second sentence provides useful scoping information without unnecessary 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 destructive delete tool, the description covers the main action, scope, and key side-effect exclusions. It does not mention irreversibility, permissions, or result behavior, but the destructive annotation and complete schema cover much of that ground.

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 input schema already documents the accountId, accountIds, id, and items parameters, including aliases. The description only restates that one or more accounts can be deleted, adding little 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?

The description uses a specific verb and resource: "Delete one or more platform accounts from the workspace catalog." It also clarifies scope by distinguishing this from closing windows or removing stored vault copies, which helps separate it from browser/window-related siblings.

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

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

The description gives clear context for when to use the tool and includes an important exclusion: it does not close windows or remove vault copies. It does not name alternative sibling tools such as nex_account_modify or nex_browser_close, so it falls short of fully explicit alternative 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?

Beyond the readOnlyHint annotation, the description adds a behavioral guarantee that 'Secrets are never returned.' It also clarifies the catalog vs. open-window vault distinction, which is a behavioral scoping. There is no contradiction with the annotation.

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 serving a distinct purpose: stating the primary action, routing away from a sibling, and reassuring about secrets. There is no fluff, and the key disambiguation is placed early.

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 sufficient for basic usage (calling with no parameters) and offers strong usage context, but it omits any explanation of how the parameters affect the result. Since there is no output schema, an agent cannot infer the return format beyond 'list of accounts with IDs.' This is a moderate gap for a tool with pagination and filtering options.

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 description contains zero information about any of the four parameters (page, size, teamId, keyword). Since schema coverage is 0%, the description must compensate for the missing parametric guidance, but it does not. An agent cannot know how to filter or paginate from this text.

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 starts with a clear verb and resource: 'List platform accounts in the workspace catalog.' It also states the intended usage ('so an accountId can be selected for window creation or later vault fill') and explicitly disambiguates from the sibling nex_browser_accounts, making its purpose unmistakable.

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 explicit when-to-use guidance by contrasting with nex_browser_accounts: 'This is not the open-window vault; use nex_browser_accounts after a window is running.' This tells the agent exactly when to choose this tool over the alternative.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that password and 2FA secret are write-only and never returned, and that updates are partial, but it does not explain permissions, reversibility, side effects, or overall return behavior for a mutation 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 three short sentences, front-loaded with the core operation and followed by key usage and secret-handling constraints. 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 mutation tool with no annotations and no output schema, the description covers partial updates and write-only secrets but omits important call context such as the required account identifier, return behavior, and permission assumptions. It is adequate but incomplete.

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

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

Schema description coverage is only 44% across 9 parameters. The description clarifies write-only handling for password and 2FA secret but does not explain other parameters such as username, platformUrl, platformName, remark, or teamId, nor does it add much beyond the schema's own accountId/id notes.

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 one platform account in the workspace catalog." It clearly identifies the operation and scope, though it does not explicitly distinguish itself from sibling tools such as nex_account_create, nex_account_delete, or nex_account_batch_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 phrase "Pass only the fields that must change" gives useful partial-update guidance, but there is no explicit when-to-use or when-not-to-use guidance relative to create/delete/list/batch siblings. Usage is implied rather than fully directed.

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

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

Annotations already declare readOnlyHint=true, so the bar is lower, yet the description adds real operational guidance: the amount sign convention, an explicit data-quality warning to branch on `type` rather than the translated `remark`/`typeRemark`, and a caveat that results are not an idempotency guarantee. These are non-obvious traits an agent could not infer from the schema. Pagination behavior and result stability are only hinted at, keeping it from a 5.

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

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

Three tight sentences, front-loaded with the resource and sign semantics before the caveats. The middle sentence references fields (`type`, `typeRemark`) that are never described, which borders on cryptic, but no text is wasted.

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

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

This is a read-only list tool with no output schema, so the description should sketch the return shape; it explains the sign of `amount` but never mentions that records carry `type`/`remark` fields or how many pages to expect. Adequate to call correctly, but an agent still guesses at the response structure and pagination limits.

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?

Both parameters (page, size) have 0% schema description coverage, and the description says nothing about pagination, defaults, or the maximum size of 1000. With low coverage the description is expected to compensate, and it does not; the only semantic content (sign of amount) is about the response, not the 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?

States a specific verb and resource — listing the current user's payments and refunds — and adds the sign convention (positive = credit, negative = debit), which tells an agent what the values mean. It is clearly distinct from the browser/proxy/SMS siblings, though it does not explicitly position itself against the other record-list tools (nex_ip_order_list, nex_mail_record_list, nex_sms_record_list) that an agent might confuse it with.

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

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

"Use it to reconcile unclear purchases" gives one concrete scenario, and "it is not an idempotency guarantee" implies a caution, but neither states when NOT to use it nor names an alternative tool. The intended usage is implied rather than delimited.

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 readOnlyHint annotation declares this is a safe read operation. The description adds meaningful behavioral context beyond that: it discloses that usernames are masked, secrets are never returned, and that the result provides accountId values intended for nex_browser_fill_account. This directly informs the agent about data safety and downstream usage, exceeding the annotation's 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?

Two sentences with zero filler. The first sentence front-loads the verb and resource; the second provides security constraints and a pointer to the next step. Every clause adds value, and the structure is easy to scan.

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

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

No output schema exists, so the description must convey what the tool returns. It does this adequately: it indicates the result includes bound platform accounts and user-saved passwords, masks usernames, omits secrets, and exposes accountId for use with nex_browser_fill_account. It lacks explicit pagination/return-format details, but for a simple list operation with two optional params, this is sufficient.

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

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

The input schema describes both parameters (windowId and windowIds alias) with 100% coverage, but the descriptions are minimal ('One window ID or a list' / 'Alias of windowId'). The tool description adds no parameter-level meaning. With complete schema coverage, baseline 3 applies; the schema already handles parameter clarity adequately.

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, specific operation: listing autofill-capable credentials from the vault plugin. It identifies the resource scope ('vault plugin', 'bound platform accounts', 'user-saved passwords') and explicitly notes what is not returned (secrets). This distinguishes it from sibling tools like nex_account_list without needing to 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 provides clear context: it lists credentials for use with nex_browser_fill_account. It implies the tool is a prerequisite for filling an account and warns that secrets are never returned, setting expectations. However, it does not explicitly state when NOT to use this tool or name alternative listing tools, so it lacks an explicit exclusion.

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 destructiveHint annotation already flags mutation risk, and the description adds concrete behavior: existing window binding is replaced, accountIds=[] removes the binding, and running windows are rejected. It does not describe auth or response behavior, but it gives useful operational constraints beyond the annotation.

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: binding, replacement, removal, rejection condition, and follow-up tool are all stated without wasted prose.

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

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

For a three-parameter mutation tool with no output schema, the description covers the key prerequisites, replacement semantics, and removal behavior. A remaining ambiguity is how multiple accountIds map to multiple windowIds, but the essential calling information is present.

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 windowId/windowIds aliases and the accountIds removal behavior. The description reinforces that accountIds=[] removes the binding and that window IDs must reference closed windows, but adds little format or mapping detail 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?

The description uses a specific verb and resource: bind catalog platform accounts to closed NexBrowser windows. It clearly scopes the operation to closed windows and distinguishes it from the sibling nex_browser_accounts, which is used afterward to fill.

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 explicit prerequisites (windows must be closed; running windows are rejected) and routes the agent to nex_browser_accounts for the follow-up fill step. It does not explain when to use account binding versus other binding operations, but the relevant constraints and next step are clear.

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

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

Annotations only declare destructiveHint=true; the description goes substantially beyond that by explaining that binding overwrites an existing proxy binding, that running windows are rejected, and that no extra confirmation is needed when replacing a confirmed failed proxy. The explicit preservation advice (save task URL and form state before closing, reopen and verify the exit) is exactly the kind of irreversibility context annotations cannot express.

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, front-loaded with the core action and the removal sentinel, then preconditions, then the risky-workflow note. Every sentence carries information, though the final clause ('reopen and verify the exit') is compressed enough to be slightly ambiguous.

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 mutation tool with no output schema and only a destructiveHint annotation, the description covers preconditions, overwrite semantics, removal, and recovery workflow. It leaves partial-failure behavior and the shape of the bind result unstated, which is a minor gap rather than a blocking one.

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

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

Schema description coverage is 100%, so all three parameters are already documented, including proxyId=0 removal and the windowId/windowIds alias relationship. The description adds only marginal semantics — the one-to-many cardinality of windows and the overwrite behavior of proxyId — so the baseline 3 applies.

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

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

States a specific verb and resource — bind one proxy to one or more closed NexBrowser windows — and immediately covers the inverse operation (proxyId=0 removes the binding). The scope (closed windows only) is stated in the same breath, so an agent can distinguish it from nex_browser_bind_account or nex_browser_connect without opening a schema.

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

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

Gives a hard precondition ('Running windows are rejected, so close them first') and a removal path (proxyId=0), plus workflow guidance for the failed-proxy replacement case. It does not name adjacent tools (e.g., nex_browser_close) that an agent would need to satisfy the closed-window requirement, so it stops short of full when/when-not/alternatives 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?

The annotations say only readOnlyHint=false and idempotentHint=false. The description adds substantial context beyond that: it discloses clicks with real consequences, that repeat calls only inspect progress and never click again, that a changed Grid returns a nextPrepareId without charging, and that an unclear charge blocks new charges. The billing and retry semantics are genuinely useful, though phrases like 'Website acceptance needs page evidence' remain opaque.

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 text is dense but not bloated, and most sentences cover required workflow ground. The problem is ordering: it begins mid-flow with an instruction instead of leading with what the tool does, and the long compound sentences make failure, billing, and page-evidence rules hard to scan.

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 multi-round, stateful workflow with no output schema, the description covers a fair amount: task states (SUCCEEDED/FAILED/EXPIRED), the nextPrepareId handoff, the attempt cap, and charge-blocking behavior. It leaves out what the tool actually returns to the caller, the source of prepareId, and what 'page evidence' and 'final sign-up/login button' mean operationally.

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

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

There is one required parameter, prepareId, at 0% schema description coverage, so the description carries the burden of explaining it. It never defines prepareId directly; only the phrase 'A changed Grid returns nextPrepareId... submit it as the next round' hints at the value's origin and that it can be replaced between rounds. That is a thin, indirect substitute for documenting the parameter.

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 procedural step ('Query the task once; on SUCCEEDED apply the answer...') rather than a plain statement of what the tool is: the step that finalizes a captcha challenge inside the browser. The verb and resource are inferable from the workflow narration, but with siblings named nex_browser_captcha_prepare and nex_browser_captcha_submit, the definition never explicitly differentiates this completion step from those two.

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 solid procedural guidance for a run already in progress (poll pending tasks every 3-5 seconds, treat a changed Grid as a new round, stop after 3 attempts on FAILED/EXPIRED). What it never states is when an agent should choose this tool rather than nex_browser_captcha_submit or nex_captcha_query, nor the precondition that a prepare call must already exist.

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: free/no purchase, which widget families are supported, that missing params or an uncaptured callback are hard blockers, and the 'never silently reload a filled form' safety rule. It stops short of describing what the capture returns or how long it waits, so not 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?

Front-loads the capture action and packs the routing rules into a small number of dense sentences with no filler. The opening 'Free, no purchase' framing is somewhat incidental to the action and every clause is compressed rather than structured, which costs a point.

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?

Adequate for a nested-object, zero-required-param tool with no output schema: it covers supported widget types, the grid escape hatch, blocking failure modes, and the next step. The main gap is that the return payload (availability/schema data) and the grid sub-field semantics are 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 coverage is only 40%, and the description compensates only partially: it explains when to pass challengeId and that grid selectors plus mode are needed for non-reCAPTCHA grids. It never mentions pageId, sessionId, challengeUrl, or the required nested grid fields (root, tiles, instruction, verify, success), which are undocumented in both places.

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

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

States a concrete verb+resource ('capture the page CAPTCHA') and adds secondary outputs (product availability, online schema), which distinguishes it from siblings nex_browser_captcha_submit/complete/buy. The phrase 'check product availability and the online schema' is slightly ambiguous about what is actually returned, keeping it short of a 5.

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

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

Explicitly names the alternatives and the conditions for choosing them: explicit reCAPTCHA v2/Turnstile, image grids, and the instruction not to fall back to GRID or nex_captcha_buy on missing params/403/timeout. It also gives an exclusion (canvas/custom widgets need a site adapter) and a hand-off rule ('When ready, call nex_browser_captcha_submit').

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?

Goes well past the annotations (idempotentHint=false, destructiveHint=true) by disclosing the actual cost model ("Charges the balance at the current server price"), the non-idempotency rationale (each Grid round has its own prepareId), server-side revalidation of product/team/page/Grid image, retry caps, and an uncertainty-handling procedure. This is exactly the extra context destructive/expensive tools need.

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

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

Front-loaded with the primary action and follow-up tool, then layered with guards (no resubmit after timeout, attempt cap, no final button click, billing). Dense and nearly waste-free, though the billing/reconciliation clauses are slightly compressed and could be ordered more logically relative to each other.

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

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

Covers everything an agent needs for a costly, destructive, non-idempotent 1-parameter call: precondition (prepareId from a prepare step), what gets charged, what is not done (final button), retry limits, and what to do when the result is ambiguous. No output schema exists, and the description acknowledges that ambiguity explicitly rather than pretending the result is deterministic.

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

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

With only one parameter at 0% schema coverage, the description carries the burden and does add real meaning: prepareId comes from a prepare step, must be reused when calling complete, and is per-Grid-round. It stops short of stating where to obtain it or any format/lifetime rules, so it is strong but not complete.

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 ("Submit a prepared page CAPTCHA once") and immediately pairs it with the follow-up sibling action (nex_browser_captcha_complete with the same prepareId), drawing a clean boundary against both nex_browser_captcha_prepare and nex_browser_captcha_complete. It also carves out scope it explicitly does not cover ("Does not click the final sign-up/login button").

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

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

Gives explicit when-to-use ("call it directly when the user's task needs it"), an explicit counter-case ("a price inquiry is not a purchase request"), and hard negatives ("Never resubmit after a timeout", "At most 3 attempts per resource flow", reconcile before any retry). The agent has a complete routing and retry policy without needing to inspect 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 disclosure burden, and it says nothing about behavior: no error semantics if the element is already checked, no note on whether change events fire, no indication that the target must come from a prior nex_browser_snapshot. Eight words cannot cover a mutation on page state.

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 zero filler. It is efficient, though the brevity borders on under-specification rather than tight precision.

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, has only three fully documented parameters and no output schema, so little is strictly required. Still, for a state-mutating browser action the description omits the snapshot-ref prerequisite and failure behavior, leaving the agent to infer the workflow from siblings.

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% (pageId, target, sessionId all documented, including "Snapshot ref (e12) or unique CSS selector"), so the schema does the heavy lifting. The description adds no additional parameter meaning, which matches the baseline 3 for fully described schemas.

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?

"Check a checkbox or radio control" states a specific verb (check) and resource (checkbox/radio), and is distinguishable from the sibling nex_browser_uncheck by polarity. It does not explicitly name that sibling, but the operation is unambiguous.

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

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

Usage is only implied by the verb; there is no statement about when to use this instead of nex_browser_uncheck, nex_browser_click, or nex_browser_select_option. An agent can infer intent from the name, but nothing in the text routes it among the many sibling interaction 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 and falls short: it doesn't say whether the click auto-waits, scrolls into view, what happens with a stale snapshot ref, or whether a fresh snapshot is returned. Only the negative CAPTCHA constraint is disclosed.

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

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

Two sentences, front-loaded with the core action, and the CAPTCHA warning is compact. The CAPTCHA sentences consume roughly half the text for a side concern, but they are actionable rather than filler.

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

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

With no annotations, no output schema, and five parameters, the description should say more about failure modes (missing element, expired ref) and post-click behavior. It does add valuable cross-tool CAPTCHA workflow context, which partly compensates.

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

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

Schema coverage is 60% and the description only implicitly maps to 'doubleClick' via 'Click or double-click'. The 'button' parameter (left/right/middle) is an undescribed enum in both schema and description, and pageId/sessionId defaults are covered only by 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 pair ('Click or double-click') and resource ('an element'), plus the two accepted target forms: snapshot ref or CSS selector. It distinguishes itself implicitly from nex_browser_mouse_click_xy by targeting elements rather than coordinates, but never names that sibling explicitly.

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

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

The CAPTCHA guidance is genuinely useful routing ('start with nex_browser_captcha_prepare', plus an explicit do-not list of workarounds). However, it says nothing about when to prefer this over nex_browser_mouse_click_xy, hover, or check/uncheck, and gives no prerequisite that the element must come from a fresh snapshot.

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

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

Annotations already flag destructiveHint=true, but the description adds nothing on top: it doesn't say whether closing is reversible, what happens to open tabs/cookies/sessions, or whether omitting ids closes everything (a real risk with 0 required params). For a destructive tool this is thin.

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 sentence, front-loaded, with no filler — but the brevity is under-specification rather than economy, leaving the agent with nothing actionable beyond the 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?

A destructive, zero-required-parameter batch close with no output schema needs at least a statement of default scope and consequences. The description covers neither, so an agent cannot safely predict the effect of calling it with an empty argument.

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 description mentions no parameters at all. The schema documents ids/windowId as aliases of each other (67% coverage), but teamId is undocumented in both places, and the description never clarifies the alias duplication or the default behavior when no ID is supplied.

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

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

The description states a specific verb ('Close') and resource ('NexBrowser environments'), and 'one or more' signals batch semantics. It implicitly distinguishes itself from nex_browser_tab_close by scoping to environments, but never names a sibling explicitly to lock that distinction in.

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 versus nex_browser_disconnect, nex_browser_tab_close, or nex_browser_group_delete, all of which sound adjacent. No preconditions (must the browser be connected first?) and no mention of what happens if ids are omitted.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose useful traits: default team selection, isolated session creation, startIfNeeded opening a closed window, and ordering constraints after a batch open. It omits side effects such as what happens if the window is already connected, whether the call is idempotent, and what session state is returned.

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

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

Front-loads the default-routing rule, then the mechanics, then the multi-window pattern, then the CAPTCHA constraint. Every sentence contributes, though the CAPTCHA prohibition is somewhat tangential to a connect tool and lengthens an otherwise tight definition.

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

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

With no annotations and no output schema, the description should cover more about what a successful connect produces and how failures surface (for example, a window that cannot be started). It covers usage comprehensively but leaves the post-connect state and error behavior to inference.

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

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

Schema coverage is 67%, and the one uncovered parameter is the required windowId, whose meaning is only inferable from 'connect each' in the multi-window sentence. The description adds genuine meaning beyond the schema for startIfNeeded (batch-then-connect ordering) and teamId (active team by default), which the schema notes only tersely.

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: 'Connects one window (active team by default) and creates an isolated automation session.' It also implicitly distinguishes itself from nex_browser_open, which is named for the multi-window opening step, so an agent can separate the two. What 'connecting' actually yields (a session handle, a readiness state) is not spelled out, keeping it short of a 5.

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

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

Explicitly declares this the default for nexbrowser-mcp browser tasks, gives the exact multi-window sequence (call nex_browser_open once with all IDs, then connect each with startIfNeeded=false), and routes CAPTCHA work to nex_browser_captcha_prepare. It also states a negative rule: do not solve CAPTCHAs with CDP, Python, image matching or scripted drags.

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

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

Annotations already declare readOnlyHint=true, and the description's 'Inspect' verb is consistent with that. The description adds useful context beyond the annotation by scoping to 'running' environments and clarifying the list-all behavior when windowId is omitted. It does not disclose what fields 'status' contains or behavior for invalid/non-running window IDs, but the annotation lowers the burden.

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 zero waste. The primary purpose is front-loaded in the first sentence, and the second sentence delivers the single most important invocation detail. 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 read-only inspection tool with three optional parameters all documented in the schema, the description is largely sufficient. The main gap is the absence of an output schema combined with no description of what 'status' information is returned, which leaves the agent guessing about the response shape. Still, the tool name and description convey the essential semantics.

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 three parameters (ids, teamId, windowId) are already documented in the schema. The description's 'Omit windowId to list every running window' largely restates the schema's windowId description rather than adding new meaning. Baseline 3 is appropriate since the schema carries the parameter documentation burden.

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 ('Inspect') and resource ('status of running NexBrowser environments'), making the tool's core function clear. It does not explicitly differentiate from close siblings like nex_browser_list or nex_browser_tab_list, but the 'status of running environments' framing is specific enough to convey what it 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 invocation guidance ('Omit windowId to list every running window'), which helps the agent use the tool correctly. However, it provides no when-to-use vs. alternative guidance, no exclusions, and no mention of when a sibling like nex_browser_list would be more appropriate. Usage context is implied rather than explicit.

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

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

With no annotations, the description carries the full behavioral burden. It reveals that messages are buffered (implying accumulation) but says nothing about whether reads consume/clear the buffer, what happens with the clear flag, whether this works after page navigation, or what the messages look like.

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

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

A single front-loaded sentence with no filler. Efficient, though its brevity is achieved partly by omitting needed detail rather than by tight editing.

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

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

With no annotations and no output schema, the description must explain both semantics of the 'clear' flag and the shape of returned messages; it does neither. An agent can call it, but cannot predict the effect of clear or what it 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?

Schema coverage is 67%: pageId and sessionId have defaults documented in the schema, but the 'clear' boolean is undocumented in both schema and description, leaving the potentially destructive buffer-clearing behavior ambiguous. The description adds nothing 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 (read) and resource (console messages) plus a scope qualifier: messages buffered by this automation session. It is distinguishable from the sibling network diagnostic tools (nex_browser_network_requests, nex_browser_network_request) by resource type, though it doesn't explicitly contrast 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?

No statement of when to call this versus nex_browser_network_requests or nex_browser_evaluate, and no prerequisites such as needing an active connection. The only guidance is implicit in the phrase 'buffered by this automation session'.

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 behavioral disclosure burden. It reveals non-obvious behavior: unset fields use desktop defaults, each window gets an auto-generated fingerprint, and only differing fields need to be passed. This goes beyond the schema and helps the agent predict side effects.

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, front-loaded with the verb and resource, and every word adds value. It avoids redundant restatement of the schema and delivers key behavioral information 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?

Given the tool's complexity (11 parameters, nested objects, no output schema), the description covers essential context: where creation happens, fallback behavior, and fingerprint generation. It lacks details about return values or interaction with other sibling tools, but these are partly covered by the schema and tool naming. Overall, adequate for an experienced agent.

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 73%, and the description adds meaningful parameter-level context by stating that unset fields fall back to defaults and specifying which types of fields (fingerprint, preferences, layout, startup page) are affected. This complements the schema and clarifies the semantics of optional parameters.

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 'Create NexBrowser environments' and specifies the active workspace, making the tool's purpose unambiguous. It distinguishes itself from sibling tools like nex_browser_group_create by focusing on environment/window creation.

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 usage guidance: 'pass only the fields that must differ' and explains fallback behavior. While it doesn't explicitly contrast with alternatives, it implies when to use this tool (creating windows) and how to use it effectively.

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 must bear the full transparency burden. It discloses one key behavioral trait (does not close the environment) but omits details such as whether the session can be reconnected, what happens to running automation, or the effect of omitting sessionId. This is adequate but minimal.

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, well-structured sentence that front-loads the action and includes the key qualifier. No wasted words; every phrase adds 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?

The tool has one optional parameter, no annotations, and no output schema, so the description is the sole source of guidance. It explains the core action but leaves out essential information about sessionId usage, preconditions, and post-disconnect state, making it incomplete for an agent to invoke 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 0%, yet the description does not mention the sessionId parameter at all. It provides no guidance on what sessionId refers to, whether it is required, or what happens if omitted. The description completely fails to compensate for the schema's lack of 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 uses a specific verb ('Disconnect') and resource ('automation session') and clearly distinguishes the tool from its sibling nex_close_browsers by stating it does not close the NexBrowser environment. This is a precise, non-tautological description.

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 'without closing the NexBrowser environment' provides clear context for when to use this tool relative to closing the environment, implying a distinction from nex_close_browsers. However, it does not explicitly name alternatives or state exclusions, so it falls short of a 5.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses a CAPTCHA-handling rule and a prohibition, but says nothing about drag mechanics, side effects, waiting behavior, permissions, or what happens after the drag.

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 purpose is front-loaded in the first sentence, followed by a concise CAPTCHA directive. Both sentences are relevant and there is no wasted text.

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 core action and an important CAPTCHA warning, while the schema covers parameter details. However, for a browser interaction tool with no annotations and no output schema, it omits return behavior, failure modes, and drag-specific behavioral 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 schema already documents all four parameters, including startTarget and endTarget as snapshot refs or unique CSS selectors. The description adds no parameter meaning beyond what the schema already provides, making 3 the appropriate baseline.

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

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

The description states a specific verb and resource: dragging one snapshot ref or CSS selector to another. This is clear enough to identify the operation, though it does not explicitly distinguish itself from the sibling nex_browser_drop tool.

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

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

It gives a concrete CAPTCHA-related alternative: start with nex_browser_captcha_prepare and do not use scripted drags for CAPTCHAs. It lacks general guidance on when to use drag versus other interaction tools such as drop or click, but the explicit exclusion is valuable.

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 hints at a prerequisite ('approved files') but never explains what approval means, whether files must first be uploaded, what events are fired, or what happens on failure.

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

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

The description is a single front-loaded sentence with no wasted text. Its brevity works structurally, though the ambiguity around 'approved' could have been resolved with a few precise 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 5-parameter browser interaction tool with no annotations, no output schema, and a nested 'data' object, one sentence is insufficient. Key prerequisites, data format expectations, and interaction behavior are unaddressed.

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

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

Schema description coverage is 60%, and the description adds some meaning by indicating that 'data' is MIME-typed text content. However, it does not explain the 'data' object value format, the 'paths' approval requirement, or the target selector semantics beyond what the schema already states.

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

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

The description uses a specific verb ('Drop') and resource ('approved files or MIME-typed text data') and names the recipient ('target'). It does not, however, distinguish this from sibling tools like nex_browser_drag or nex_browser_file_upload, so an agent must infer the boundary.

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

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

Usage is only implied by 'drop onto a target'; there is no explicit when-to-use or when-not-to-use guidance. No alternative sibling tools are mentioned, so routing between drop, drag, and file upload is left to inference.

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

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

With no annotations, the description must carry the full behavioral burden. It usefully discloses the permission gate and the CAPTCHA prohibition, but says nothing about side effects on page state, whether the expression is awaited, how non-serializable results are handled, 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?

Three short sentences, front-loaded with the core action and prerequisite. The CAPTCHA guidance is relevant but occupies two-thirds of a very short description for an unrelated defensive rule.

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

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

No output schema and no annotations, so the description should say more about what comes back and what happens on evaluation errors or permission denial. The permission and CAPTCHA context is present, but the return contract is entirely 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 coverage is 67%; pageId and sessionId are documented in the schema, but the required 'expression' parameter has no schema description. The description's 'Evaluate JavaScript' implies the argument is JS, but does not clarify expression-vs-statement form, async support, or return serialization.

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: 'Evaluate JavaScript' on a browser page. It does not distinguish itself from the sibling nex_browser_run_code, which an agent would plausibly consider interchangeable, so it stops 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?

Gives a real precondition ('when the dedicated evaluate permission is enabled') and an explicit negative rule ('Do not solve CAPTCHAs with CDP, Python, image matching or scripted drags'), routing CAPTCHA work to nex_browser_captcha_prepare. It still lacks guidance on when to prefer this over nex_browser_run_code, snapshot, or get_text for reading page state.

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

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

With no annotations, the description carries the full behavioral burden and falls short: it never says whether the call waits for the upload to complete, what happens on failure or partial upload, or whether a change/input event is fired. The word 'approved' gestures at a security constraint without defining it, so an agent cannot tell which local paths are permitted.

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 padding or redundancy. It is slightly under-specified rather than bloated, so conciseness is good but the sentence does very little work.

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-style tool with no annotations and no output schema, the description omits the behavior an agent most needs: completion semantics, error behavior, and the meaning of file approval. It is not complete enough to call the tool confidently.

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

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

Schema coverage is 75% and the schema already documents pageId, target and sessionId, so the baseline is 3. However the one undescribed parameter, 'files', is the most important one, and the description adds nothing about whether these are absolute paths, what 'approved' means, or any per-file constraints.

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

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

Names a specific verb and resource ('Upload approved local files') plus the mechanism ('through a file input target'), so an agent can see it drives an <input type=file>. It does not distinguish itself from the sibling nex_browser_drop, which is the other file-delivery tool, leaving ambiguity about which to pick.

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

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

The phrase 'through a file input target' implies the situation (a page element accepting file input) but never states when to use this over nex_browser_drop or what prerequisites exist. Usage is inferable rather than stated.

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

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

With no annotations, the description carries the load and does so well: it discloses that the plugin chooses fields, that passwords/2FA stay outside MCP, that the call must be repeated after navigation, and critically that the form is never submitted. Missing are failure behavior, what happens if no matching credential exists for the window, and any hint about the result.

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

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

Four tight sentences, each carrying a distinct fact (what it does, prerequisite, repeat-after-navigation, no submit), with the core action front-loaded. No filler or 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 small three-parameter tool with full schema coverage and no output schema, this covers the essentials an agent needs to call it correctly. The one gap is return/failure information — the agent cannot tell from the definition whether a success indicator or filled-field summary comes back.

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 pageId/sessionId defaults and accountId optionality; baseline would be 3. The description adds real meaning the schema does not: the accountId must be one returned by nex_browser_accounts for this open window, which is a provenance constraint, not a restatement.

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

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

States a specific verb+resource: autofill the current login page with a stored vault credential via the NexBrowser vault plugin. It distinguishes itself from generic input tools by noting the plugin picks the visible fields and that passwords/2FA never pass through MCP. It does not explicitly contrast with the closely named sibling nex_browser_fill_credentials, so an agent still has to infer which to use.

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

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

Gives an explicit prerequisite and sequence: call nex_browser_accounts first and pass only an accountId returned for this open window, and call again after each navigation in multi-step sign-in. That is clear operational guidance. It stops short of naming the alternative tool (e.g. nex_browser_fill_credentials) or stating 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 burden and does so well: it discloses the security trade-off of literal values, the no-storage/no-repeat constraint, and the no-submit behavior. It stops short of describing failure modes (e.g., stale snapshot refs, invisible or missing target fields) that matter for a DOM-mutating tool.

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

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

Three tight sentences: capability first, alternative plus rationale second, safety constraint third. No filler and nothing buried.

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

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

No output schema and no annotations, so the description must stand alone; it covers purpose, alternative routing, and the key safety constraints. It leaves some gaps around error behavior and field-matching when targets are omitted, which an 8-param mutation tool ideally would address.

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 63%, with target-ref semantics documented in the schema itself; the description adds the 'visible fields' constraint but says nothing about the username/password/totpCode pairing or how omitted targets are resolved. Baseline 3 applies since the schema does most of the work.

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

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

States a specific verb and resource — filling literal login credentials into visible fields — and scopes it to values the user explicitly supplied in the current request. It is clearly separable from nex_browser_fill_account and nex_browser_fill_form.

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?

Explicitly routes the agent: prefer nex_browser_fill_account when a stored vault credential exists, and gives the reason (literal values cross the model/MCP request boundary). It also states the terminal condition that the form is never submitted.

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 disclosure burden, and it only hints that fields are applied sequentially. It says nothing about whether a snapshot/ref must exist first, what happens on a missing or ambiguous target (error vs. partial fill), or whether the fill dispatches input/change events.

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 well-formed sentence with no padding, and the ordering detail is front-loaded. It is concise to the point of under-specification for a tool with seven similar siblings.

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

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

No annotations, no output schema, and a crowded sibling namespace mean the description should explain prerequisites, target resolution, and failure behavior. None of that is present, leaving an agent to guess at the most consequential details of a mutating browser action.

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

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

Schema coverage is 67% and the schema already documents 'target' as a snapshot ref or CSS selector plus pageId/sessionId defaults. The description's 'one or more ... in order' adds the batch and ordering semantics that the array schema does not state, which is real added value, but the value type and per-field validation remain unexplained.

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 verb and resource ('Fill ... form controls'), so the basic action is clear, but it offers no differentiation from close siblings like nex_browser_type, nex_browser_fill_account, nex_browser_fill_credentials, nex_browser_select_option, or nex_browser_check. An agent cannot tell from this text alone which one applies to a given field.

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 only guidance is the implicit 'one or more ... in order' batch/sequence detail. There is no statement of when to use this versus nex_browser_type or select_option, no prerequisite about needing a snapshot first, and no 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?

Consistent with readOnlyHint=true, so no contradiction. It adds useful behavioral context (only visible text is returned; CAPTCHAs block this endpooint and must be handled through the dedicated prepare tool, not via CDP/Python/image matching). It does not say what the response looks like, whether hidden or off-screen text is excluded, or whether output is truncated on large pages.

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

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

Front-loaded with the core action, then the CAPTCHA caveat. Every sentence is short and carries a directive, though roughly half the text is CAPTCHA policy rather than text-extraction semantics, which is a slight imbalance for a read tool.

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

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

For a 3-optional-param, read-only extraction tool with full schema coverage and no output schema, the description is adequate but incomplete: it omits the return shape (single text blob?), behavior on pages with no visible text or iframes, and only points at the first step of the CAPTCHA flow (prepare) without the submit/complete follow-through it references elsewhere in the family.

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 pageId, target, and sessionId defaults. The description reinforces the 'one target' concept (snapshot ref e12 or unique CSS selector), but adds no format or edge-case detail beyond the schema; baseline 3 is met and the 'one target' scoping nudges it slightly higher.

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

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

States a specific verb+resource: 'Read visible text from the page or one target.' That is more precise than a generic 'get text' because it scopes the read to rendered/visible content and to an optional single target. It does not explicitly contrast with the nearest ambiguous sibling (nex_browser_snapshot), 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?

Gives explicit routing only for the CAPTCHA case: use nex_browser_captcha_prepare first, and do not hand-roll CAPTCHA solving. The main selection question an agent faces — this tool vs nex_browser_snapshot vs nex_browser_evaluate for extracting content — is left unaddressed.

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 that exactly one history entry is traversed, but it does not explain what happens when there is no previous entry, whether navigation waits for page load, or any other side effect.

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. It communicates the action directly and 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 navigation tool, the description is minimally sufficient alongside the fully described optional parameters. It still omits behavioral edge cases such as history-boundary behavior, which matters because no annotations or output schema provide that 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%, and both parameters are optional with clear schema descriptions. The description adds no parameter-level detail 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 states a specific verb and resource: 'Go back one entry in the page history.' This distinguishes it from sibling navigation tools such as nex_browser_go_forward and nex_browser_navigate without needing clarification.

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 is implied by the action: use it when the browser should return to the previous history entry. However, it does not explicitly state when to use it instead of nex_browser_go_forward, nex_browser_navigate, or nex_browser_reload.

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 does not say what happens when there is no forward history entry (error vs. no-op), whether navigation waits for load, or whether page state is preserved.

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

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

A single sentence with zero waste, front-loading the action and scope. Nothing redundant or padded.

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

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

For a zero-required-parameter history tool with no output schema, the description is minimally adequate but omits the edge case an agent most needs: behavior at the end of forward history. Otherwise nothing critical is missing.

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

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

Schema description coverage is 100% — both pageId and sessionId are documented in the schema with their default-to-active behavior. The description adds nothing beyond that, so the baseline 3 applies.

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

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

States a specific verb and resource ('Go forward one entry in the page history'), which is precise and clearly distinct from the sibling nex_browser_go_back and from nex_browser_navigate. It stops short of naming those siblings, but the direction semantics make the distinction obvious.

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

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

There is no explicit guidance on when to use this versus nex_browser_go_back, nex_browser_navigate, or nex_browser_reload. The intended context (returning to a page the user navigated back from) is only implied by the word 'forward'.

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. It discloses that duplicate group names are rejected, which is a useful behavioral detail. However, it does not mention side effects (e.g., whether creation is idempotent), return values, or any prerequisites beyond 'active workspace'. The uniqueness rejection is the only behavioral trait beyond the schema, so a moderate score is appropriate.

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 the core purpose stated first and the uniqueness constraint and alternatives appended. No wasted words; every sentence earns its place. It is appropriately front-loaded and 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 simple create operation with fully documented parameters and no output schema, the description is sufficiently complete. It covers the core action, the uniqueness constraint, and routes to related operations. The only missing piece is a return value description, but the absence of an output schema suggests it is not critical. The context (active workspace) is stated, so an agent has what it needs to 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 coverage is 100%, so the schema already fully documents both parameters. The description repeats the uniqueness requirement for 'name' that is already in the schema ('must be unique inside the active team'), adding no new semantic detail. The 'seq' parameter is fully described in the schema. Thus, the description adds no value beyond the schema, fitting the baseline 3 for high coverage.

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

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

The description states a specific verb ('Create'), a concrete resource ('one window group'), and the scope ('in the active NexBrowser workspace'). It also clarifies the uniqueness constraint, distinguishing it from group modification and moving operations by naming sibling tools. This is unambiguous and clearly differentiates from related 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 explicitly directs the agent to use nex_browser_group_modify for renaming and nex_browser_move_to_group for placing windows, thereby defining when this tool is appropriate and providing alternatives. Though it doesn't state an explicit 'not for' case, the purpose is clear and the alternatives cover the main adjacent operations.

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?

destructiveHint=true already signals a destructive operation; the description adds the important non-obvious consequence that contained windows survive and become ungrouped, plus the built-in rejection of groupId 0. It omits whether deletion is reversible or what permissions/workspace state is required.

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

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

Three short sentences: action first, side effect second, constraint last. No filler and nothing repeated from the title.

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

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

For a two-parameter destructive tool with no output schema, the description covers the action, the collateral effect on child windows, and the one invalid input. A note on the return value (e.g., confirmation or affected group) and the required-parameter ambiguity would make it complete.

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

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

Schema coverage is 100%, so 'id' (alias of groupId) and 'groupId' are already fully documented, and the description's note that groupId 0 is rejected duplicates the schema text. It adds nothing about the alias relationship or the fact that neither parameter is marked required, leaving an ambiguity the schema does not resolve.

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 ('Delete') and resource ('one custom window group') scoped to the active NexBrowser workspace. It clearly separates this from group creation/listing by naming the custom (non-zero) group as the target. It stops short of explicitly naming the sibling it could be confused with (nex_browser_group_modify).

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 exclusion 'the ungrouped bucket (groupId 0) cannot be deleted' gives a concrete when-not constraint, and 'custom window group' implies only user-created groups are eligible. However, it never says when to prefer nex_browser_group_modify over deletion or what prerequisites exist, so usage is implied rather than spelled out.

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 readOnlyHint annotation already signals non-destructiveness, and the description adds valuable behavioral context—specifically that the first row is always the ungrouped bucket with groupId 0. This goes beyond the annotation by explaining what to expect in the list output.

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 the action and purpose front-loaded in the first sentence. The second sentence adds a critical detail (groupId 0) without any fluff. Every word is purposeful.

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 list tool with no parameters and no output schema, the description covers the core functionality: listing window groups with their counts in the active workspace, and the special ungrouped bucket. It could optionally detail the exact output format, but the phrase 'with the window count of each' conveys the essential return value.

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

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

The tool takes zero parameters, and the schema is trivially complete. The description does not need to explain parameters, and the context signals confirm 100% schema coverage. This meets the baseline for a zero-parameter tool.

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

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

The description clearly states the verb 'List', the target resource 'window groups of the active NexBrowser workspace', and the output detail 'with the window count of each'. It distinguishes this from sibling tools like tab_list or group_delete by specifically focusing on window groups and groupId selection.

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 states the intended use: to select a groupId for window creation, moving, or deletion. It also highlights the special ungrouped bucket with groupId 0, which is important for using group-related tools. However, it does not explicitly mention alternative tools or 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?

With no annotations, the description does add real behavioral constraints: names must stay team-unique and the ungrouped bucket (groupId 0) is rejected. But it does not state what happens on a uniqueness conflict, whether the operation is reversible, or what a successful rename/reorder 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?

Three short sentences, front-loaded with the core action, then constraints. No filler, though the groupId 0 line partially duplicates the schema's groupId description.

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

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

For an unannotated mutation tool with no output schema, the description covers what is changed and the key restrictions but is silent on error behavior, permission requirements, and the result, leaving meaningful gaps.

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

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

Schema coverage is 100%, so baseline is 3. The description loosely maps rename->name and reorder->seq but adds no format or constraint detail beyond what the schema properties already 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?

Specific verb pair (rename/reorder) plus resource (custom window group) and scope (active workspace) let an agent distinguish it from nex_browser_group_create, nex_browser_group_delete, and nex_browser_rename without opening a schema.

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

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

Usage context is implied by 'modify one custom window group', and the groupId 0 exclusion is a useful boundary, but the description never names an alternative or says when to choose this over group_create/group_delete. The routing is left to inference.

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

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

No annotations are provided, so the description carries the full behavioral disclosure burden. It says dialogs can be listed or accepted/dismissed, but does not explain whether dialogs block page execution, what dialog types are involved, how promptText applies, whether accepting is irreversible, or what happens if a dialog is absent or already 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?

The definition is a single short sentence with no filler and is appropriately front-loaded. It is concise, though the terseness contributes to the missing behavioral and parameter detail rather than being complemented elsewhere.

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

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

With no annotations, no output schema, and incomplete parameter documentation, the description is not complete enough for a 6-parameter browser dialog tool. It does not explain what a listing returns, how to identify the target dialog, or the consequences of accept/dismiss decisions.

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

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

There are 6 parameters and only 33% schema description coverage, so the description should compensate but does not. It mentions accept/dismiss conceptually but gives no meaning for id, promptText, or the interaction between accept, dismiss, and id, leaving most parameter semantics to be inferred.

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 resource (dialogs) and two concrete operations: list pending dialogs, or accept/dismiss one dialog. It is clear enough for an agent to understand the tool's purpose, though the dual-mode nature is only briefly framed and no sibling tools cover this exact dialog-handling domain.

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 by naming two modes, but it does not explain when to list versus when to accept/dismiss, what prerequisites are needed (such as a dialog id), or how these operations relate to browser interaction siblings like click or press_key. It provides a minimum viable indication of usage without explicit 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 burden and provides almost none. It does not explain whether hovering triggers page events, whether the state persists, visibility requirements, or any side effects.

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 is appropriately terse for a simple browser action, though the terseness contributes to missing usage and behavioral 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 low-complexity tool with fully described parameters and no output schema, the description is minimally adequate. It lacks guidance on target validity, page/session defaults, and interaction behavior that would help an agent 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?

Schema description coverage is 100%, so the schema already documents pageId, target, and sessionId. The description adds no parameter meaning beyond the schema, but baseline 3 is appropriate when 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 states a specific verb and resource: hover over an element. It is clear what the tool does, but it does not explicitly distinguish itself from sibling interaction tools such as nex_browser_click, nex_browser_mouse_click_xy, or nex_browser_drag.

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 hover versus other browser interaction tools. It implies a basic hover use case but omits alternatives, prerequisites, or exclusions.

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

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

No annotations are provided, so the description carries the burden. It discloses the key behavioral trait — the key remains held until nex_browser_key_up is called — which is useful. But it omits whether the hold state is per-session, what happens if key_up is never called, and whether focus is required.

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 behavior and the release mechanism. No 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 stateful keyboard tool with no annotations and no output schema, the description covers the essential pairing with key_up but leaves out key format, focus requirements, and failure behavior. It is minimally adequate but not complete.

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

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

Schema coverage is 67%: pageId and sessionId are documented in the schema, but the required key parameter has no description. The tool description adds no format guidance (e.g., 'Enter', 'a', modifier keys), leaving a critical gap for the primary parameter.

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 (hold) and resource (keyboard key), and names the paired release tool nex_browser_key_up. It distinguishes itself from a simple press by describing a persistent hold. Sibling differentiation is present but not exhaustive against press_key or type.

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 the usage pattern: call this and then call nex_browser_key_up to release. However, it doesn't say when to choose this over nex_browser_press_key or nex_browser_type, nor does it state prerequisites like page focus.

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 only the pairing with key_down; it says nothing about what happens if the key is not held, whether key events are dispatched, or error behavior for an input-mutation 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 front-loaded sentence with zero filler. Every word contributes to identifying the action and its counterpart.

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

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

For a three-parameter browser input tool with no annotations and no output schema, the description is too thin. It omits key value format, default page/session behavior, and return/error semantics that an agent needs to 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?

Schema coverage is only 67%, and the description adds no meaning for the 'key' parameter (e.g., accepted key names like 'Shift' or 'a') nor for pageId/sessionId defaults. It does not compensate for the undocumented required parameter.

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: 'Release a keyboard key.' It also names the inverse sibling (nex_browser_key_down), so an agent can distinguish this from press_key without opening either 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 reference to nex_browser_key_down implies this should be called after a key-down, but there is no explicit when-to-use guidance, no exclusions, and no comparison to siblings like nex_browser_press_key.

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

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

Annotations already declare readOnlyHint: true, and the description adds meaningful behavioral context by specifying what the tool lists and what it explicitly never reports. This goes beyond the annotation, providing clarity on scope without contradicting the read-only hint.

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, efficiently front-loaded with the tool's preferred status and primary purpose, followed by necessary exclusions. Every sentence adds value with no 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?

Despite having no output schema and a simple parameter set, the description clearly communicates what the tool does and what it excludes, which is sufficient for a list operation. It does not describe return format, but the core purpose and constraints are 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 description coverage is only 20% (only groupId has a description), and the tool description adds no explanation of page, size, teamId, or keyword parameters. The description does not compensate for the schema's limited information, leaving agents to guess parameter semantics.

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

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

The description clearly states the tool 'lists managed NexBrowser environments/profiles' and uses a specific verb 'lists' with a resource. It distinguishes itself from siblings by explicitly excluding other browser types and tabs, and positions itself as the preferred tool for showing/counting windows.

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 context for when to use the tool ('Preferred NexBrowser OpenAPI tool for requests such as...') and outlines explicit exclusions (never reports Chrome, Edge, Codex in-app browser, OS windows, or tabs). It doesn't name alternative tools directly, but the behavioral scope suffices to guide selection.

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

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

With no annotations, the description carries the full burden; it does disclose the coordinate space, the surfaces covered, the out-of-scope native toolbar popups, and prohibited CAPTCHA workarounds. It says nothing about preconditions (active session/page), whether the click waits for stability, or what happens on a failed hit, which matters for a raw-coordinate 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?

Front-loaded with the action, then coordinate derivation, then the CAPTCHA routing — each sentence adds distinct information. The prose is dense and clause-heavy (parentheticals, embedded formulas), which slightly hurts scanability but there is no filler.

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

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

For a 7-parameter click tool with no annotations and no output schema, the definition covers coordinate sourcing and CAPTCHA policy well but leaves the sibling-selection question and half the parameters unaddressed. An agent knows the coordinate math yet still can't tell confidently why it would use this instead of nex_browser_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?

Coverage is 29% — only pageId and sessionId are documented in the schema — but the description supplies the crucial semantic for x/y (CSS pixels in the viewport) and the pixelsPerCssPixel/origin conversion for turning screenshot pixels into them. The remaining parameters delay, button and clickCount get no treatment at all.

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

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

States a specific verb and coordinate system: click at x/y in viewport CSS pixels, and enumerates the surfaces it reaches (canvas, iframes, extension overlays) while excluding native toolbar popups. However, it never names the obvious sibling nex_browser_click (selector-based), so an agent still has to infer which clicking tool to pick.

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

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

It gives one explicit routing rule — for page CAPTCHAs start with nex_browser_captcha_prepare and do not use CDP/Python/image matching/scripted drags — plus the requirement to derive coordinates from a fresh screenshot. It never says when to prefer this tool over nex_browser_click, which is the most consequential usage decision here.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that groups are metadata and windows stay running (non-disruptive, no close/reopen cycle), but says nothing about required permissions, what happens with an unknown groupId or invalid window ID, or how the result is reported.

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

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

Three short sentences, front-loaded with the action and the special case, then the operational reassurance. Nothing is redundant or padded.

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

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

For a 3-param mutation tool with no annotations and no output schema, it covers the main semantics but leaves a real ambiguity: windowId/windowIds are optional in the schema while the description says 'one or more windows', so it is unclear what happens if they are omitted. Return behavior and error cases are also unaddressed.

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

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

Schema coverage is 100%, so both groupId and windowId/windowIds are already documented, including the groupId=0 semantics and the alias relationship. The description largely restates those facts ('pass groupId=0') and adds only the 'one or more windows' framing, 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 first sentence gives a specific verb and resource: moving NexBrowser windows into a window group, with the groupId=0 special case spelled out. It is distinguishable from group_modify/group_delete, but it never explicitly contrasts itself with those siblings, so a 4 rather than a 5.

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

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

It states a concrete usage condition (groupId=0 removes windows from any group) and reassures that running windows need not be closed first, which is the key decision point. It gives no explicit when-not-to-use or pointer to an alternative tool for a different kind of move.

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 add useful context by stating that the return value is a refreshed accessibility snapshot and by disclosing the CAPTCHA workflow and prohibited solving methods, but it does not cover navigation waits, failure modes, session/page requirements, or other side effects.

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

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

The description is two sentences and front-loads the core action and return value. The second sentence is a targeted operational constraint rather than filler, so every part 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?

There is no output schema, but the description explains that the refreshed accessibility snapshot is returned, which covers the main return expectation. It also covers the CAPTCHA caveat, though it leaves some navigation-specific behavioral details and parameter usage implicit.

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 67%: pageId and sessionId already document their default-to-active behavior, while url is undocumented in the schema and the description only indirectly implies navigation target. The description does not add parameter-level meaning beyond the schema, so the moderate schema coverage supports a baseline score of 3.

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 and resource: it navigates the selected page and returns its refreshed accessibility snapshot. It is clear what the tool does, but it does not explicitly distinguish itself from nearby navigation/state siblings such as nex_browser_reload, nex_browser_open, nex_browser_go_back, or nex_browser_go_forward.

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

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

The description gives one clear usage rule: for page CAPTCHAs, start with nex_browser_captcha_prepare and avoid CDP, Python, image matching, or scripted drags. However, it does not say when to use nex_browser_navigate versus related tools like nex_browser_reload or nex_browser_open, so broader tool-selection guidance is left implied.

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

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

Annotations already declare readOnlyHint=true, so safety is covered. The description adds the useful fact that the request is 'buffered' (implying bounded/in-memory storage) but says nothing about buffer lifetime, expiry, or what happens when an index is out of range.

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 zero filler. It is arguably too terse rather than padded, so conciseness itself is a strength.

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

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

There is no output schema, so the description is responsible for telling the agent what a request record contains (URL, method, status, headers/body?) and whether the buffer must be populated first. Neither is covered, leaving the agent unable to predict the result of a call.

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

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

Schema coverage is 67%: pageId and sessionId are documented in the schema, while index carries only 'minimum: 1'. The description's '1-based' confirms the indexing convention that the schema only hints at, but adds nothing about the page/session defaults or valid index ranges.

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 ('read') and resource ('one buffered network request'), plus the indexing convention. It implicitly contrasts with the sibling nex_browser_network_requests (list vs. single), but never names that sibling to make the split explicit.

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

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

Usage is only implied: the 'buffered' and 'by index' phrasing suggests this is the detail-fetch step after listing requests, but the description never says 'use after nex_browser_network_requests' or states prerequisites such as the buffer being populated.

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, yet it discloses nothing about behavior: whether reads are non-destructive, whether the buffer is captured continuously from page load, what a returned request record contains, or that the 'clear' parameter destroys buffered data. An agent cannot tell the safety profile or side effects from this sentence.

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 sentence, front-loaded with the verb and resource, no filler. It is efficient but too thin to be genuinely well-structured for a tool with a destructive-adjacent flag.

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

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

No output schema exists, so the description should explain what a network request entry looks like, whether ordering/pagination applies, and what 'clear' does. None of this is present, leaving the tool under-described for a 3-parameter inspection API.

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

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

Schema coverage is 67%, and the undocumented 'clear' boolean is the most consequential parameter — the description never mentions it or its destructive effect on the buffer. pageId/sessionId defaults are covered by the schema, so the description adds nothing beyond 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?

States a specific verb (Read) and resource (network requests) with scope qualifier 'buffered by this automation session'. It does not differentiate itself from the sibling nex_browser_network_request (singular), which an agent could easily confuse with this tool.

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

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

No indication of when to use this versus nex_browser_network_request, nex_browser_console_messages, or server-side tooling. There are no prerequisites or preconditions given (e.g. must be connected to a session with buffering enabled).

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 must carry behavioral disclosure, and it does reveal two non-obvious traits: it returns per-window status and Desktop tiles windows as part of a batch-start. However, it says nothing about permissions, idempotency for already-running windows, failure modes, or partial-batch outcomes, which matter for a start/mutation 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, zero filler, with the primary action stated first and the multi-window batching instruction second. Every clause carries actionable information.

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

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

For a start/environment-mutation tool with no annotations and no output schema, the description covers what it does and the batching strategy, and it mentions the per-window status return. It omits prerequisites (auth, team scope), behavior when targets are already running, and error semantics, leaving meaningful gaps.

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

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

Schema coverage is 67% and the windowId/ids alias is already documented in the schema; the description reinforces why an array is preferred (batch-start and tiling) rather than restating the format. teamId, required but undescribed in the schema, receives no clarification in the description either, so it does not fully compensate for the coverage gap.

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

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

The description states a specific verb and resource ("Start NexBrowser environments") plus a return behavior ("per-window status"), which an agent can distinguish from lifecycle siblings like nex_browser_create or nex_browser_connect. It stops short of explicitly naming the boundary versus those siblings, so a 4 rather than a 5.

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

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

It gives a concrete usage rule: for multi-window tasks, pass every window ID in one windowId array so Desktop can batch-start and tile them, and it implies this happens before creating automation sessions. That is clear procedural context, but it does not state when NOT to use it (e.g. already-running windows) or name an alternative 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?

readOnlyHint=true already tells the agent this is a safe, non-mutating read, so the description's burden is light. It adds no behavioral context such as whether it waits for load, errors on detached pages, or returns null when no title exists.

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 waste. It is arguably under-specified rather than padded, so it earns credit for tightness but not full marks.

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 trivial read tool with annotations and fully described optional params, the essentials are covered. However, with no output schema the description could state that the title string is returned (and what happens when the page has no title), which it omits.

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 optional parameters already document their defaults ('Defaults to the active page/session'). The description contributes nothing beyond the schema, so the baseline 3 applies.

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

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

'Read the page title' gives a specific verb (read) and resource (page title), so the operation is unambiguous. It does not distinguish itself from nearby siblings such as nex_browser_page_url or nex_browser_snapshot, which retrieve overlapping page state.

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 instead of nex_browser_page_url, nex_browser_snapshot, or nex_browser_get_text. An agent must infer the choice from tool names alone.

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?

readOnlyHint=true already tells the agent this is a safe, non-mutating read, and the description adds only the word 'current', which restates the default-scoping already implied by the schema. It does not say what is returned (a URL string), what happens when no page is open or the session is disconnected, or whether it reflects the top-level frame vs. iframes.

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 zero padding, which is appropriate for a trivial getter. It could have used one additional clause (return type or failure behavior) without becoming verbose, so it is efficient but slightly under-filled.

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-required-parameter getter this is close to sufficient, but with no output schema the description is the only place that could state the return value (URL string) and behavior when the page is missing. Those omissions leave a small but real gap for correct invocation and result handling.

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 both parameters are optional with explicit fallback behavior ('Defaults to the active page/session'), so the schema does the heavy lifting. The description adds no parameter detail beyond that, which matches the baseline 3 for well-documented schemas.

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

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

States a specific verb and resource ('Read the current page URL'), which is unambiguous and immediately actionable. It does not differentiate itself from near-siblings such as nex_browser_page_title or nex_browser_connection_info, leaving the agent to infer the boundary from names alone.

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

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

Usage is implied by the name and purpose – this is the obvious tool when an agent needs the URL of the active page. There is no explicit statement of when to prefer it over nex_browser_evaluate or nex_browser_connection_info, and no mention of preconditions (e.g. a connected session or open page).

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 not disclose whether the keypress dispatches both keydown and keyup, whether it auto-focuses the target, whether it requires an active session/page, or what happens if no element is focused. Only the vague 'or focused element' fallback is conveyed.

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, so it is efficient. The brevity crosses into under-specification rather than excess, but on structure alone it is clean.

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 browser keyboard-interaction tool with no annotations and no output schema, the description omits key syntax, modifier handling, focus/target resolution behavior, and connection prerequisites. It is too thin to let an agent call it confidently without inspecting the schema and inferring behavior.

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 75% (pageId, target, sessionId documented), so the baseline is 3. The description adds a little by implying target-vs-focused-element resolution, but it never explains the required 'key' format (e.g. 'Enter', 'Control+A') which is the single mandatory parameter and undocumented 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?

States a specific verb (press) and resource (a key) applied to a page or focused element, which is clear enough to understand the action. It does not differentiate from the close siblings nex_browser_key_down / nex_browser_key_up (hold vs. full press) or nex_browser_type, leaving the agent to infer the distinction.

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 instead of key_down/key_up for held keys, type for text entry, or fill_form for structured input. The only contextual hint is the phrase 'selected page or focused element', which implies usage but states no conditions or exclusions.

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

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

With no annotations, the description carries the full burden and does disclose a real hazard: reloading can discard a filled form, so user confirmation is required. It also forbids specific workaround approaches (CDP, Python, image matching) for CAPTCHAs, which is meaningful behavioral context. It does not mention what happens to in-flight requests or session state.

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

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

Three short sentences, front-loaded with the core action, with no wasted padding. The CAPTCHA sentence is slightly tangential but still earns its place as a guardrail.

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 trivial two-optional-parameter action with no output schema, this covers what the agent needs: what it does, the data-loss risk, and where to go for CAPTCHAs. Only the exact effect on page state is left implicit.

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 pageId and sessionId defaults are already documented in the schema. The description adds no parameter-level detail beyond that, so baseline 3 applies.

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

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

"Reload the page" is a specific verb+resource that an agent can distinguish from navigate/go_back/go_forward in the sibling list. It doesn't explicitly contrast itself with those siblings, but the operation is unambiguous.

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

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

States a clear conditional guard (ask the user before reloading a filled form) and routes CAPTCHA situations to nex_browser_captcha_prepare. It lacks general when-to-use framing versus nex_browser_navigate, but the practical guidance is 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?

Beyond the idempotentHint annotation, the description discloses that no other window settings change and that renaming works on running windows without closing them. It does not cover permission requirements or failure behavior, but it adds meaningful mutation-scope context.

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

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

Three short sentences, front-loaded with the purpose and invocation constraint. Each sentence adds useful information: scope, parameter restriction, and the live-window behavior.

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 metadata mutation with full schema coverage and no output schema, the description is nearly complete. It omits error cases such as an invalid windowId, but covers the key behavioral facts an agent needs to call 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?

Schema description coverage is 100%, so the parameter meanings are already fully documented. The description reinforces that only windowId and name are accepted, but adds no format or syntax details 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?

The description states a specific verb and resource: 'Rename one NexBrowser window.' It also scopes the operation to window metadata, which distinguishes it from siblings like nex_browser_resize or nex_browser_move_to_group without requiring schema inspection.

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

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

It gives a clear usage condition: running windows can be renamed without closing them first, and only windowId and name should be passed. It does not explicitly name exclusions or alternatives, but no direct rename sibling exists.

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 says nothing about whether the resize persists across navigations, whether it affects screenshots or emulation, or whether the session must already be connected — all relevant for a viewport 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 short sentence with zero filler, front-loading the action. It is efficient, though its brevity borders on under-specification rather than true conciseness.

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

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

With no annotations, no output schema, and four parameters, the description should explain side effects and prerequisites. It leaves the agent without any information on persistence, effect on other browser operations, or failure modes.

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

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

Schema coverage is 50%: pageId and sessionId are documented as defaulting to the active page/session, while width and height have no descriptions but are self-explanatory numeric names with min/max constraints. The description's 'active page' phrasing loosely reinforces the default-target behavior but adds no syntax or unit detail 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 ('Resize the active page viewport'), which is unambiguous and distinguishable from sibling tools like nex_browser_take_screenshot or nex_browser_scroll that also affect rendering. It does not name any alternative, but the action itself is sharply defined.

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 resize versus when to capture, scroll, or open a new page, and no prerequisites (e.g., a connected browser session). The agent must infer all usage context from the tool name alone.

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 full behavioral burden. It usefully discloses the runCode permission gate and an anti-pattern (don't script CAPTCHA solving), which is genuine behavioral context. But it says nothing about execution context, return value, timeouts, or side effects on the page for an arbitrary-code tool.

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

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

Three short, front-loaded sentences with no filler, and the core action plus permission gate come first. The CAPTCHA sentences feel somewhat tangential to running code but are still compact and actionable.

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

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

For a no-annotation, no-output-schema free-code-execution tool, an agent still lacks return-value, execution-context, and failure-mode information. The permission prerequisite and CAPTCHA routing are covered, but the execution semantics are not.

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

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

Schema coverage is 67%, with pageId and sessionId documented as defaulting to the active page/session; the required 'code' parameter is undocumented in both schema and description. The description adds no format, size, or context hints for the parameters, so it does not compensate for the gap.

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

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

States a specific verb+resource: 'Run page JavaScript.' Clear enough that an agent knows the operation. However, it never distinguishes itself from the close sibling nex_browser_evaluate, which appears to do the same thing, so an agent cannot tell them apart without reading 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?

Gives a real prerequisite ('when the separate runCode permission is enabled') and explicit alternatives/exclusions for CAPTCHA work ('start with nex_browser_captcha_prepare', 'Do not solve CAPTCHAs with CDP, Python, image matching or scripted drags'). Strong context, though the CAPTCHA routing is a specialty case rather than general when-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 burden, yet it does not disclose scroll direction semantics, whether scrolling is instant or smooth, wait behavior, failure modes for missing targets, or whether the page must be loaded.

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

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

The single sentence is front-loaded and contains no filler. It is concise, though the brevity borders on under-specification for a five-parameter browser 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?

The tool has five parameters, only 60% schema description coverage, no annotations, and no output schema. The description is too sparse to fully prepare an agent for invocation, especially around deltaX/deltaY semantics and scroll behavior.

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

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

Schema coverage is only 60%, and the description does not explain deltaX or deltaY at all. It adds some meaning for target, but that parameter is already documented in the schema as a snapshot ref or CSS selector.

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

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

The description states a specific action and resource: scrolling the page, with optional target-into-view behavior. It is clear, but it does not distinguish this tool from nearby browser interaction tools such as snapshot, wait_for, or click.

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 that a target can be brought into view first, but gives no explicit guidance on when to use scrolling versus other browser tools, when to omit target, or when target is required for offscreen elements.

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, yet it says nothing about firing change/input events, waiting behavior, multi-select semantics, or failure mode when a value is absent. It only implies a mutation to page state, which is a minimal and obvious inference.

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 or repetition. It is efficient, though slightly too terse for a tool whose behavior needs qualifying.

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

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

With no annotations, no output schema, four parameters, and 25% of property descriptions missing, the definition should explain event firing, waiting, and value-matching rules. It does not, leaving the agent under-informed for a state-mutating browser action.

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

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

Schema description coverage is 75%, and the required `values` array is undocumented in the schema; the description only says 'one or more values', restating minItems:1, and does not clarify whether entries match option labels, option values, or indexes. It adds essentially no meaning 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?

The description names a specific verb ('select') and resource ('select control'), which makes the action clear. It does not differentiate from adjacent siblings such as nex_browser_fill_form, nex_browser_check, or nex_browser_type, leaving the agent to infer that this only applies to <select> 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?

There is no statement of when to use this tool versus alternatives, nor any exclusions such as 'not for checkboxes — use nex_browser_check'. Usage is only implied by the phrase 'select control'.

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?

readOnlyHint already covers the safety profile, yet the description adds two genuinely useful behavioral facts beyond the annotations: the refs are ephemeral ('short-lived') and CAPTCHAs must be handled through the captcha toolchain rather than CDP/Python/image matching. It still omits what happens when a ref goes stale or how large a snapshot can be.

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

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

Two short sentences with the core action front-loaded and no filler. The second sentence is a policy note that is relevant but sits somewhat apart from the purpose statement, keeping it from being maximally tight.

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

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

With no output schema and no annotations beyond readOnlyHint, the description should carry more weight on what a snapshot returns and how the refs are consumed by action tools; 'short-lived actionable refs' gestures at this but leaves the return shape and ref lifecycle unexplained.

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 60% (pageId, sessionId, target documented; boxes and depth undocumented), and the description contributes no parameter meaning at all — no mention of depth limiting, boxes overlay, or that target accepts either an e12-style ref or a CSS selector.

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

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

States a specific verb and resource ('Capture an accessibility/ARIA snapshot') and adds the distinguishing output trait — 'short-lived actionable refs' — which separates it from siblings like nex_browser_get_text or nex_browser_take_screenshot that also read the page but return different artifacts.

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

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

It gives one explicit routing rule ('Page CAPTCHA: start with nex_browser_captcha_prepare') and a prohibition, but never says when to prefer a snapshot over get_text, page_title, or take_screenshot, nor that it is the prerequisite for ref-based click/type/fill. Usage is implied rather than spelled out.

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 destructiveHint annotation already flags this as a destructive operation, but the description adds nothing: it does not say whether closing the last tab ends the session, whether the tab's state is lost, or whether the close is immediate. For a destructive tool, the one-liner leaves the agent with no behavioral context beyond the annotation.

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 and the key identifier named up front. It is efficient, though the terseness borders on under-specification rather than tight conciseness.

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

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

A destructive, session-affecting mutation with only a bare destructiveHint, no output schema, and a half-documented schema. The description says nothing about what is destroyed, what happens to the browsing session, or the result — far short of what an agent needs before firing a close.

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

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

Schema coverage is 50% — pageId is undocumented in the schema, and the description contributes the useful qualifier "stable," hinting it is a durable identifier rather than a positional index. However, it does not say where to obtain a pageId, so the schema gap is only partly compensated.

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

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

States a specific verb and resource ("Close a tab") plus the identifier used ("stable page ID"), which distinguishes it from nex_browser_close (whole browser) by resource scope. It never names that sibling explicitly, so differentiation 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?

No guidance on when to close a tab versus disconnecting or closing the whole browser, and no note that the pageId should come from nex_browser_tab_list. Usage is only inferable from the verb.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds real value by disclosing that the response includes both the tab list and the active/stable page ID — a concept other tools depend on — but says nothing about behavior when the session is absent or about pagination/ordering.

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 well-formed sentence with the return content front-loaded and zero filler. It is efficient, though it is terse enough that a short second clause about session requirements would have earned 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 read-only, single-optional-param tool with no output schema, the description covers the essential contract: it lists tabs and the active stable page ID for a session. What is missing is how the IDs relate to tab_select/navigate and any behavior on an invalid session.

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?

Only one optional parameter with 100% schema description coverage, which already documents "Defaults to the active session." The description's "for an automation session" is consistent with the schema but adds no new semantics beyond it, so baseline 3 applies.

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

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

States a specific verb ("List") and resource ("tabs") plus an extra return element ("active stable page ID"), all scoped to an automation session. This clearly separates it from mutating siblings like nex_browser_tab_new/select/close, though it doesn't name any sibling 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?

There is no statement of when to call this versus alternatives (e.g. nex_browser_connection_info, nex_browser_snapshot), no preconditions, and no note on what to do with the returned page ID. Only the phrase "for an automation session" hints at context.

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