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 disclose one important behavioral trait: the tool requires a GSXT session when using the L1 recipe. Beyond that prerequisite, it does not state whether the operation is read-only, what permissions it needs, how it handles errors, or what side effects may occur.

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

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

The description is two short sentences with no wasted words, and the purpose is front-loaded. The second sentence is cryptic ('L1:', '+'), but it does convey a concrete configuration recipe and prerequisite, so it earns its place despite being terse.

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 an output schema, so return values need not be explained. However, with 7 parameters, 0% schema description coverage, no annotations, and multiple sibling tools, the description is far from complete. It omits parameter explanations, sibling disambiguation, and most operational context an agent would need 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 description coverage is 0% across 7 parameters. The description names two parameters with specific recommended values ('prefer_tier=l1' and 'platform=gsxt'), but adds no meaning for keyword, dims, depth, fields, or persona_id. This leaves most parameters undocumented in both schema and description.

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

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

The description states a specific verb ('Collect') and resource ('enterprise info'), so the basic purpose is clear. However, 'enterprise info' is broad, and the definition does not distinguish this tool from siblings like enterprise_search or enterprise_collect_batch. The second sentence provides configuration hints rather than clarifying scope.

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 L1 line implies a specific usage recipe (prefer_tier=l1 with platform=gsxt) and notes a prerequisite (needs GSXT session). But there is no explicit guidance on when to use this tool versus enterprise_search, enterprise_collect_batch, or other siblings, and no exclusion criteria are given.

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

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

No annotations are provided, so the description must carry the full behavioral burden, but it discloses none: no side effects, duration, rate limits, auth requirements, or meaning for parameters like checkpoint_path and stop_on_blocked. It only describes the input separator format.

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 wastes no words, but it is too sparse for a 7-parameter tool and omits information an agent needs in order to invoke it correctly.

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

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

For a complex 7-parameter batch collection tool with no annotations and 0% schema description coverage, the description is far too incomplete. The output schema helps with return values, but the description still omits routing, behavior, and six of seven input parameters.

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% across 7 parameters. The description explains only the required keywords parameter's separator format, leaving depth, fields, platform, persona_id, checkpoint_path, and stop_on_blocked completely undocumented.

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

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

The description states a specific verb and resource: 'Collect multiple company keywords.' The word 'batch' in the tool name and 'multiple' in the description clearly indicate multi-keyword scope, but it does not explicitly distinguish this from the sibling enterprise_collect 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?

There is no guidance on when to use this tool versus enterprise_collect, enterprise_search, or other siblings. The only implied usage is bulk keyword input, with no prerequisites, exclusions, or routing context.

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

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

No annotations are provided, so the description carries the full burden. It hints at a 'lightweight' mode but does not state read vs write semantics, rate limits, auth requirements, or what the depth=0 constraint actually changes about returned data.

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 fragment, but it is under-specified rather than concise. The dash structure front-loads a vague descriptor and then references an undefined sibling concept (depth=0) with no context.

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

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

With three undocumented parameters at 0% schema coverage, no annotations, and no explanation of the keyword/platform/fields inputs, the description is insufficient for an agent to call the tool correctly, even though an output schema exists.

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

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

Schema coverage is 0% — all three parameters (keyword, platform, fields) lack descriptions. The description only mentions depth, which is not even a declared parameter, so it fails to compensate for undocumented fields like platform (default 'aiqicha') or fields.

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

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

The description says it is a 'search' and ties it to depth=0 collection, but it does not clearly state what it searches (enterprise data) nor how it differs in purpose from the sibling enterprise_collect tool that it references. An agent cannot confidently distinguish the two verbs.

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 when to use it — lightweight collection with depth=0 and the same default equity fields — which gives a soft routing hint against the heavier enterprise_collect. However, it never explicitly says to prefer enterprise_collect for depth>0, so the boundary is only implied.

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

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

With no annotations, the description carries the full burden; it does disclose that probing is optional and "live," implying a real network check versus a cheap cached report. However it says nothing about side effects, auth requirements, latency, or failure behavior, which for a diagnostic tool is only partially sufficient.

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

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

One sentence, front-loaded with the primary action, with the optional parameter noted last. It is efficient, though the heavy acronym load makes it terse to the point of near-opacity.

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

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

An output schema exists, so return values need not be explained, and no parameters are required. Still, the description never clarifies what a "persona" check or ENScan_GO/Handaas availability actually means in practice, leaving the agent without enough context to interpret the result.

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

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

Schema coverage is 0% for the single boolean, so the description must compensate. It does add meaning by framing probe_sidecars as a "live" probe (i.e. default false = passive report, true = active contact), which is real value beyond the bare boolean type and default.

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?

"Report availability of ..." names a specific verb and resource, so the diagnostic intent is legible. But the resources (ENScan_GO, Handaas, personas) are opaque internal names, and the sibling scout_sidecars is not differentiated or referenced, so an agent cannot confidently route 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?

The phrase "optional live sidecar probe" hints that probe_sidecars toggles a heavier mode, but there is no explicit when-to-use guidance, no prerequisites, and no statement of when to prefer this over scout_sidecars or scout_sessions.

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

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

With no annotations, the description carries the full behavioral burden. It discloses re-running and archiving on success, but omits permissions, idempotency, rate limits, failure handling, and whether archiving is destructive.

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 is appropriately concise, though its brevity contributes to missing context for a tool with three undocumented parameters.

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 output schema covers return values, but the input parameters are undocumented and no annotations exist. For a mutation/retry tool, the description should explain dry_run, limit, include_partial, and safety implications to be complete.

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

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

Schema description coverage is 0%, and the description does not mention any of the three parameters: limit, dry_run, or include_partial. An agent cannot infer their meaning or effects from either source.

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 ('Re-run') and resource ('captcha/failed jobs from raw/retry_queue'), plus the success effect ('archive on success'). The purpose is clear, but it does not explicitly distinguish itself from sibling tools such as scout_doctor or scout_sessions.

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 when captcha or failed jobs exist in raw/retry_queue, giving some operational context. However, it does not state when not to use it or name alternative tools for handling retry queues.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses only that dry_run counts rows, but says nothing about whether the import overwrites, merges, or appends, whether it is idempotent, what permissions are required, or what happens to existing graph data — large gaps 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?

A single front-loaded sentence with the core action first and the parameter caveat second; there is no filler. It is efficient, though its brevity is partly the result of what it omits rather than pure economy.

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

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

An output schema exists so return values need not be described, but for a mutating import with zero annotations the description should at least characterize persistence semantics and safety. An agent cannot tell from this definition what a real import does to the target graph.

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

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

Schema description coverage is 0% and the single parameter has only a title and default. The description compensates by explaining what dry_run actually does ('counts rows only'), which is real value beyond the schema, but it never states the default is true or what the non-dry-run mode changes about side effects.

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 and resource: importing warehouse parquet data into Neo4j. That is far more specific than the bare name and clearly distinguishes it from siblings like enterprise_collect or scout_doctor, though it never explicitly contrasts itself with any of 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?

There is no stated when-to-use or when-not-to-use guidance, no prerequisites, and no mention of alternatives. The dry_run parenthetical hints that a preview mode exists, but nothing says when an agent should choose this tool or what conditions must hold beforehand.

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

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

With no annotations at all, the description carries the full disclosure burden. "List" strongly implies a read-only, non-destructive operation, which is the key behavioral signal, but nothing is said about permissions, token/session freshness, or side effects. It is minimally viable rather than informative.

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 wasted framing; the verb and resource lead. The parenthetical source list is compact, though the L1/L2 notation is cryptic without an external glossary.

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

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

An output schema exists, so return-value shape needn't be described, and there are no parameters to document. What is missing is the usage context (when to call this versus the sync_* siblings) and any hint of what the registry status means to the agent. Adequate but with clear gaps.

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

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

The tool takes zero parameters, so per the baseline there is nothing for the description to compensate for. The description does not need to explain any input.

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 clear verb ("List") and resource ("unified session/cookie registry") with the specific sources it covers (GSXT L1, aiqicha L2, ENScan mirror). This distinguishes it from siblings like sync_gsxt_session and sync_enscan_cookies (which mutate sessions) and from the enterprise_* tools. The parenthetical jargon (L1/L2) is slightly opaque but the core purpose is unambiguous.

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

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

No when-to-use guidance, no prerequisites, and no alternatives named. The agent must infer that this is the read-side companion to sync_gsxt_session/sync_enscan_cookies, which is a reasonable inference but not stated. Nothing tells the agent when this tool is preferable to simply running scout_doctor.

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. 'Live-probe' implies active network checks, but it does not state whether this has side effects, requires authentication, affects the sidecars, or what happens on failure. The output schema covers return values, but safety and operational context are absent.

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 no wasted words, front-loading the action and targets. It is appropriately sized for a zero-parameter 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 simple zero-parameter probe with an output schema, the description is minimally adequate. However, given several sibling scout tools, it lacks any context about when this probe is appropriate or what distinguishes it from alternatives like scout_doctor. The agent can invoke it safely but may not know when to prefer it.

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

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

The tool takes zero parameters, so there is nothing for the description to clarify beyond the schema. Baseline for a no-parameter tool is 4. Schema description coverage is 100%, but no parameter semantics are needed.

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 ('Live-probe') and resource ('ENScan_GO and proxy_pool sidecars'). An agent can tell it performs active probing of sidecar services. It does not explicitly differentiate from siblings like scout_doctor, which may also perform diagnostics, but the target is clear.

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

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

No when-to-use guidance is provided. The description says what it does but not when an agent should choose it over scout_doctor, scout_sessions, or other scout tools. There are no prerequisites or exclusions mentioned.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose the mutation target (config.yaml), which is useful, but says nothing about whether it overwrites existing config, where the aiqicha cookie must come from, permissions/authentication needs, or what happens when cookie_file is empty.

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 the action first and zero filler. It is efficient, though its brevity edges toward 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?

An output schema exists so return values need not be explained, but this is a config-mutating tool with no annotations and an undocumented parameter. The description is too thin to let an agent invoke it confidently.

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

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

The single parameter cookie_file has zero schema description coverage, and the description only gestures at 'cookie' without explaining the expected file format, path conventions, or the meaning of the empty-string default. It does not compensate for the schema 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 names a specific verb pair ('Import' + 'sync') and concrete resources ('aiqicha cookie', 'ENScan_GO config.yaml'), so an agent knows exactly what the tool manipulates. It is not differentiated from the similarly named sibling sync_gsxt_session, but the aiqicha-vs-gsxt distinction is implied by the data source.

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 when-to-use guidance, no prerequisites, and no routing to alternatives such as sync_gsxt_session for the other session source. The agent must infer timing and applicability entirely on its own.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses the workflow precondition that a browser login must happen first and names the target site, but says nothing about how cookies are stored, whether an existing session is overwritten, or session lifetime.

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

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

A single front-loaded sentence that states the action and its most important precondition. No filler, though it is arguably terse given the low structured-data coverage.

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

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

An output schema exists, so return values need not be explained. However, with no annotations and an undocumented parameter, the definition leaves notable gaps around file format and session side effects for a stateful sync operation.

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

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

Schema coverage is 0% and the single 'cookie_file' parameter has only a title with no format or path semantics. The description implies cookies are being imported but does not compensate by specifying the expected file format (JSON, Netscape, etc.).

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 ('Import') and resource ('GSXT personal-login cookies'), which is clearly distinguishable from siblings like enterprise_collect or scout_sessions. It does not, however, explicitly differentiate itself from the closer sibling sync_enscan_cookies.

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

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

The description gives a usable precondition ('after browser login at shiming.gsxt.gov.cn'), which implies when the tool is invoked. It stops short of naming alternatives (e.g., sync_enscan_cookies) or stating when not to use it.

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