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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint false, so the safety profile is covered. The description adds the 'current' qualifier and specifies the kind of data returned (tier, capabilities, quota), but gives no additional behavioral detail such as authentication requirements or response characteristics; the output schema likely covers return structure.

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 states the purpose with no filler. Every word contributes meaningful information about the tool's output scope.

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

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

This is a simple, parameterless, read-only account-information tool. The annotations cover safety, the output schema covers return shape, and the description covers the tool's purpose and content domain. Nothing essential is missing.

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

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

The input schema has zero parameters and 100% schema description coverage, so there is no parameter documentation gap for the description to fill. A baseline of 4 is appropriate for a parameterless 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 uses a specific verb ('Return') and names a well-scoped resource: the current FOFA account tier, API capabilities, and quota information. This clearly distinguishes it from the sibling search, export, and scheduling tools, as it is the only one focused purely on account status.

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 by stating exactly what the tool returns, so an agent can infer when to call it: whenever current account tier, capabilities, or quota details are needed. It does not explicitly name alternatives or exclusions, but the zero-parameter scope and unique purpose make the usage context sufficiently 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 already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is largely covered. The description adds genuine async context ('returns immediately', how to poll/cancel), but it omits cost, runtime bounds (max_duration default 600s), and what a job produces; starting a new job per call also sits in tension with idempotentHint=true, which the description does not address.

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; the async-then-poll-then-cancel flow is easy to scan. The clipped fragment 'Never scans' is terse to the point of ambiguity about what it negates.

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-shape explanation is fairly excused, but for a background-job launcher with nine undocumented parameters the definition leaves too much unspecified: what the required intent looks like, how size/sample/max_pages/max_records interact, and what happens at max_duration timeout are all unstated.

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

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

Schema description coverage is 0% across 9 parameters, so the description carries the full burden, yet it explains only report_language behavior and a use_fofamap_model value. Critical parameters such as intent (the sole required one), size, sample, max_pages, web_search, max_records and max_duration receive no semantic explanation anywhere.

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 an Agent background job') and adds the key async trait ('returns immediately'). It is distinguishable from siblings like fofa_search because it names the polling and cancel companions, though the odd phrase 'with use_fofamap_model=true' conflicts with the schema's default of false and muddies what the tool actually does by default.

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 tells the agent what to do after invocation ('Poll fofa_job_status or cancel with fofa_job_cancel') and rules out a use case with 'Never scans', implicitly pushing direct queries to fofa_search/fofa_validate_query. It does not explicitly say 'use this instead of fofa_search when you want a long-running report', so the alternative routing is inferential 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?

The description surfaces key behavioral traits beyond annotations: the operation starts a job rather than returning data directly, and results arrive via MCP resources with status retrieval. It could further disclose cost/quota effects or how exactly to locate the artifact, but the core async artifact model is clear.

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

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

One short sentence with no filler; the essential job-start and resource-retrieval behavior is front-loaded. Every word contributes.

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

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

For a tool with a large nested request schema, async job semantics, and numerous related siblings, a single sentence is not enough. It lacks guidance on when to choose export, how to monitor the job, and what the artifact/resources contain, despite the output schema existing.

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 clarify any request fields. The only semantic hint is 'bounded,' which loosely maps to max_pages/max_records/cost_budget, but the description does not explain the nested SearchRequest or the format/filename options.

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

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

The description uses a specific verb-resource pair: 'Start a bounded export job,' and it adds that status/artifact retrieval happens through MCP resources. It is reasonably distinct from sibling search tools, though it never explicitly names what data is exported or contrasts with fofa_search/fofa_search_next.

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

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

No when-to-use or when-not-to-use guidance is provided. The description implies an async export flow, but it does not point to fofa_search for direct queries or fofa_job_status for polling, leaving the agent to infer selection criteria from the name and schema.

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, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds one genuinely useful trait, that the scan portion is simulated rather than live, but says nothing about cost, data freshness, or how the three result sections relate.

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

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

Two short sentences with no padding, which is good, but the content is thin for the tool's complexity and the mid-sentence language switch to 抽样 makes the rule harder to parse. Output enumeration is also wasted effort given an output schema exists.

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 seven parameters at 0% schema coverage and no usage routing among seven-plus FOFA siblings, the definition is far too sparse. The output schema means return values need not be described, yet the description spends its first clause on exactly that while leaving inputs 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 0% across seven parameters, so the description must compensate and largely does not. It only clarifies the sample flag (use it when the user asked for 抽样) and leaves product, country, city, size, after and max_records completely undefined in both schema and prose.

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

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

The description says the tool returns 'the full update-time result, port stats and a simulated scan', which hints at an aggregate exposure review, but the verb 'Return' is weak and it never states the resource being scoped (a product's exposed assets). Nothing distinguishes it from siblings like fofa_search or fofa_stats, so an agent must infer its role from the name 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?

The only guidance is a parameter-level rule ('Set sample only when the user asked for 抽样'); there is no statement of when this review tool is preferable to fofa_search, fofa_stats or fofa_host_profile, and no prerequisites or exclusions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds one genuinely new behavioral fact not present in structured fields: the call consumes no quota. It stops there, saying nothing about how 'tier' or 'section' affect results or whether the catalogue is cached.

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

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

A single front-loaded sentence with no filler; the no-quota benefit is placed at the end where it reads naturally. It is efficient, though the term 'membership capability catalogue' is jargon that could be plainer.

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 explanation is not required, and the tool is a simple read-only lookup. However, the two filter parameters are undocumented in both schema and description, which leaves an agent unable to choose sensible values for 'tier' or 'section'.

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

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

Schema description coverage is 0% for two parameters, and the description never mentions either 'tier' or 'section'. The only hint is the schema default 'summary' for section, which the agent must interpret unaided. With zero structured parameter documentation, the description needed to compensate and does not.

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

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

The description names a specific verb and resource: return the versioned FOFA field catalogue plus membership capability data. That is distinguishable from siblings like fofa_search or fofa_export, though it does not explicitly separate itself from the arguably related fofa_syntax or fofa_account tools, leaving a small ambiguity about which catalogue lookup 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?

There is no explicit when-to-use statement and no named alternative. The phrase 'without using quota' implies this is the cheap way to inspect capabilities before spending query budget, but the agent must infer that rather than being told. No prerequisites or exclusions are stated.

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

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

Annotations already declare this a safe, idempotent, read-only open-world call, so the bar is lower. The description still contributes two concrete operational traits not present in the annotations: a one-request-per-second throttle and an access restriction for registered (non-paid) users. The phrasing of the access restriction is terse enough to be ambiguous, which keeps it from a 5.

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

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

Three short, front-loaded sentences with no filler; the core purpose comes first and the constraints follow. The telegraphic phrasing of the last two sentences ("Registered users have no Host API") trades a bit of clarity for brevity.

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 for a two-parameter tool with zero schema coverage, the description omits the meaning and effect of "detail" and does not state what kind of aggregation is returned, leaving real gaps an agent would hit when invoking 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?

Schema description coverage is 0%, so the description must carry full parameter meaning. It clarifies "host" as an IP or DNS name but says nothing about "detail" (boolean, default true), leaving half the 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?

States a specific verb and resource ("Get FOFA Host aggregation") and constrains scope to "one IP or DNS name," which distinguishes it from the broader search siblings like fofa_search. It does not explicitly name an alternative, so it falls short of full sibling differentiation.

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

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

Adds an eligibility condition ("Registered users have no Host API") that implicitly tells the agent to verify account tier before calling, and a rate constraint. However, there is no explicit statement of when to prefer this over fofa_search or fofa_exposure_review, leaving the routing decision 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?

Annotations already declare readOnly, idempotent, non-destructive and open-world, so safety profile is covered. The description adds the three-step pipeline (fetch, hash, search) which is real context, but 'safely' is unquantified and it says nothing about failure modes when a favicon is missing, redirects, timeouts, or how results are paged.

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 walks through the operation in execution order with no filler sentences. Minor deduction for the unquantified adverb 'safely', which conveys tone rather than 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?

An output schema exists so return values need not be explained, and the core URL-to-assets workflow is clear. However, for a 4-parameter tool with zero schema coverage, three optional parameters remain unexplained, leaving the agent guessing how to control result size or shape.

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

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

Schema description coverage is 0%, so the description must carry the burden and it does not. Only 'url' is inferable from 'Fetch a public website favicon'; 'full', 'size' and 'fields' are entirely opaque with no hint of what they control (result volume, field projection, full vs. truncated search).

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 three specific operations: fetch a website's favicon, compute its FOFA MurmurHash3 value, and search matching assets. That is a concrete verb+resource chain an agent can distinguish from generic fofa_search. It stops short of naming the sibling it replaces for icon-based pivoting, so not 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?

Usage is only implied: the agent infers it should call this when it has a URL and wants icon-hash pivoting rather than a query string. There is no explicit when-to-use/when-not, no mention of the alternative (fofa_search with an icon hash query), and no stated preconditions such as the site needing to be publicly reachable.

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=false, idempotentHint=false and destructiveHint=false, so the safety profile is largely covered. The description adds genuinely new context beyond them: the worker is reclaimed and incurred charges are not refunded, which is a material cost consequence an agent must weigh before calling. It stops short of saying whether partial results are preserved or how quickly cancellation takes 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?

Two sentences with no waste, and the core action plus the most important caveat (no refund) are front-loaded. Nothing is repeated from annotations or schema.

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

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

An output schema exists, so return values need not be explained, and the cost warning covers the main behavioral risk. The gaps are around the input's provenance and edge cases such as cancelling an already-finished job, which matter for a single-purpose mutation tool with one required 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?

Schema description coverage is 0% for the single job_id parameter, so the description must carry the meaning and does not. It never says where a job_id comes from (presumably the job-start or status tools) or what form it takes, leaving the only input underspecified in both schema and prose.

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

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

States a specific verb and resource: cancel an active Agent, Nuclei scan or export job, plus the side effect of reclaiming its worker. The enumeration of job types and the 'active' qualifier make it distinguishable from fofa_job_status and fofa_schedule_stop, though neither sibling is named 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 word 'active' implies the tool applies only to jobs still running, which is useful scoping. However, there is no explicit when-to-use vs when-not guidance, no mention of what to do for finished jobs (fofa_job_status), and no pointer to the schedule-stop sibling for scheduled jobs.

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, idempotentHint, and destructiveHint as safe, so the description does not need to restate those. It does add value by defining the scope of the read (local export, agent, or scan jobs), but it does not disclose any further behavior such as polling semantics, error cases, or what state fields are 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?

The description is a single, front-loaded sentence that gets to the point with no filler. It is concise and easy to read, though the compound object 'local export, agent or scan job state' could have been phrased slightly more cleanly.

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 an output schema present and annotations covering safety, the description is reasonably sufficient for a simple status tool. However, it omits guidance on where the job_id comes from (e.g., returned by fofa_export or fofa_agent_run) and does not clarify what 'local' means, leaving some gaps for an agent trying 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%, so the description must compensate by explaining the job_id parameter. It does not. 'Read local export, agent or scan job state' implies job_id identifies one of these job types, but the format, source, or how to obtain a valid job_id is left ambiguous.

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

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

The description clearly states a read operation on a specific resource: 'local export, agent or scan job state.' It is distinguishable from siblings like fofa_export and fofa_agent_run, which are likely job-creating operations, by its 'Read' verb. However, the phrase is a bit packed and does not explicitly demarcate itself from other status-like tools, so it falls short of a 5.

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

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

There is no guidance on when to use this tool versus alternatives. One could infer it is for checking the status of jobs started by fofa_export or fofa_agent_run, but the description never states this explicitly or names any exclusions or alternatives.

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

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

The description adds useful behavior beyond the annotations: it does not call FofaMap's model, and an omitted report_language falls back to the saved interface language. However, with readOnlyHint=false and openWorldHint=true, it does not explain what side effect or external interaction occurs, nor what gets persisted or 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?

The description is two short, front-loaded sentences with no filler. It is efficiently written, though its extreme brevity leaves little structural guidance for such a large parameter surface.

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 17-parameter tool with nested HostQuery objects, the description is far too thin. The output schema covers return values and annotations cover some safety signals, but the description does not give enough information for an agent to understand the inputs or invocation context 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 17 parameters, and the description only clarifies the optional report_language fallback. Required fields such as intent and summary, and major inputs such as assets, queries, fields, host_model, and scan_selection, are left completely 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?

The description states a specific verb and resource: render host-agent text. It also distinguishes this path from model-driven execution by saying it works without calling FofaMap's model, which helps separate it from siblings such as fofa_agent_run.

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

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

There is no explicit when-to-use or when-not-to-use guidance. An agent can infer that this is the non-model rendering path, but the description does not say when to prefer it over fofa_agent_run, fofa_export, or other report-related 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered and the description needn't repeat it. The description does add one real trait — the result set is "bounded" (a preview rather than exhaustive results) — plus the notion of per-rule "verification" data, but neither is explained (bound size, what verification means).

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

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

It is a single front-loaded sentence with no padding, which is good, but the density comes at the cost of clarity — phrases like "bounded rule preview" and "per-rule verification" are compressed to the point of obscurity.

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 three-parameter search tool with no enums and zero schema coverage, the definition leaves too much open: what a rule is, what the bounded preview contains, and how it relates to fofa_search and fofa_validate_query.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning, and it only loosely gestures at "category/keyword". The limit parameter (default 50) is never mentioned, no formats, value ranges, or default behavior are explained, and it is unclear whether category and keyword combine or are alternatives.

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 verb is "search" but the resource, "bounded rule preview", is ambiguous — nothing in the definition says what a "rule" is or where the preview comes from. The phrase "before product searches" does hint it is a precursor to fofa_search, which gives partial sibling differentiation, but an agent still cannot confidently say what this returns.

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

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

Usage is only implied: "inspect per-rule verification before product searches" suggests a pre-flight step ahead of fofa_search, but it never names that sibling or states when not to use this tool. There is no guidance on whether this is mandatory before searching or optional exploration.

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=false, idempotentHint=false and openWorldHint=true, so the write/non-idempotent/network profile is covered. The description adds genuinely new behavior: that timezone, next_run, queries and liveness are surfaced back, and that check_alive=null inherits a global default with task wording taking precedence. It does not say what permissions are needed or what happens on duplicate schedule names.

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, roughly a hundred characters, so nothing is bloated and the purpose is front-loaded. However, the compactness comes at the cost of clarity: "mapping schedule" and "task wording has priority" are unexplained, so the brevity reads as cryptic rather than 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?

An output schema exists, so return-value explanation is not required, and the annotations cover the safety profile. What remains missing is guidance on the many unstructured request fields and on the relationship to sibling schedule tools; that gap is real but narrowed by the check_alive and precedence notes.

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

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

Schema description coverage is 0%, so the description carries the full explanatory burden for a request object with a dozen nested fields (task, when, fields, queries, analyze, max_pages, max_records, timing.*). It explains only check_alive's null semantics and mentions timezone/queries in passing, leaving the meaning of "task", "when", "fields" and the timing sub-fields entirely to infer from titles.

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?

"Save a ... schedule" gives a specific verb and resource and enumerates the supported recurrences (one-time/interval/hourly/daily/weekly/monthly), which makes the create intent clear. The phrasing "passive ... mapping schedule" is opaque jargon and nothing distinguishes it from sibling fofa_schedule_update beyond the tool name itself.

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 create a schedule versus updating an existing one via fofa_schedule_update, nor any prerequisites or exclusions. The only guidance-like sentence, "check_alive=null follows the current global default; task wording has priority", addresses field defaulting rather than tool selection.

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

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

Annotations already flag destructiveHint=true and idempotentHint=true, so safety is covered. The description adds valuable context beyond that: the run is cancelled, history/reports are retained in the archive, and the task cannot be resumed or edited. It does not mention permissions or auth requirements, but for a low-complexity delete that is a minor gap.

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

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

Two short sentences, front-loaded with the action and its effect, followed by the call condition. 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?

An output schema exists, so return values need no explanation, and the behavior around deletion, retention, and irreversibility is well covered. The remaining gap is the undocumented schedule_id, which matters for correct invocation but is the sole omission.

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 (schedule_id) is never mentioned in the description. The agent gets no guidance on where to obtain the id or what format it takes, so the description fails to compensate for the undocumented 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 ('Delete a schedule') plus scope ('from active management') and a distinguishing behavioral note (history/reports retained in the archive). It does not name a sibling to contrast with, but an agent can infer the difference from a mere stop/cancel.

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 says 'Only call when the user explicitly requests deletion,' which is a clear when-to-use guard. It does not mention alternatives such as fofa_schedule_stop or fofa_schedule_set_enabled for non-destructive lifecycle changes, so it falls short of full 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds value by disclosing that the result includes counts, snapshot deltas, and generated MD/HTML/JSON artifact paths, but says nothing about pagination behavior or how snapshots are compared.

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

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

One front-loaded sentence with the verb first and zero filler or redundancy. It is arguably over-compressed rather than bloated, but nothing in it is wasted.

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

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

An output schema exists, so the description needn't detail return values and reasonably summarizes what comes back. Still, for a tool with a required identifier and a paging limit, the absence of any pointer to schedule_id or limit leaves an agent dependent on the bare schema names.

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 none of the three parameters are documented in the schema, so the description carries the full burden. It only loosely gestures at 'snapshot changes', which hints at include_snapshots, while schedule_id (the required key that scopes everything) and limit (with its default of 30) go entirely 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 concrete verb (Read) and enumerates the resources it surfaces (execution history, counts, snapshot changes, report paths), which is more than a restatement of the name. However, it never distinguishes this from siblings like fofa_schedule_list or fofa_job_status, and 'counts' is ambiguous without knowing whether it refers to run counts, result counts, or something else.

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 at all - no statement of prerequisites, no named alternatives, and no exclusion of the adjacent schedule/job tools. An agent must infer from the name alone that this applies to a previously created schedule rather than an ad-hoc job.

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 already establish a read-only, idempotent, non-destructive operation, and the description adds the important guarantee that merely listing schedules will not run due tasks. 'Durable schedules' also clarifies that the listing concerns persistent schedule definitions rather than transient jobs.

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

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

Two short sentences front-load the returned resources and then state the key behavioral limitation. There is no redundant or speculative wording.

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

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

For a parameterless read-only listing tool with an output schema and comprehensive safety annotations, the description supplies the essential scope and non-execution behavior needed for correct selection. The absence of return-format details is not a gap because the output schema handles that responsibility.

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

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

The tool has no parameters, so there is no argument syntax or semantics for the description to explain. Its parameterless invocation is consistent with an unfiltered listing of schedules plus heartbeat information.

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

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

The description specifies both the action and resources: listing durable schedules and reporting the scheduler heartbeat. Its non-execution clause further distinguishes this inspection operation from schedule mutations and task-running behavior.

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

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

It clearly supports inspecting schedule definitions and scheduler health, while 'Does not run due tasks' warns agents not to select it to trigger execution. It would be stronger with an explicit pointer to fofa_schedule_history for execution history or another relevant 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?

Annotations already declare it is a non-read-only, non-destructive, non-idempotent, open-world operation, so the safety profile is covered. The description adds a genuinely non-obvious side effect: resuming recomputes a future due time, which explains the non-idempotent hint and matters for scheduling decisions. It does not say whether pause retains history or takes effect immediately.

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 the core action front-loaded and the behavioral caveat attached; 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 two-parameter toggle with an output schema, the essential behavior is covered, and return values need not be explained. Minor gaps remain around permissions and the effect of pausing on in-flight or historical runs.

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

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

Schema description coverage is 0%, so the description must carry the semantic load. It usefully explains that the `enabled` boolean means pause versus resume, but adds nothing about `schedule_id` (format, source, or where to obtain it), leaving half the parameters 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?

States a specific action pair (pause/resume) on a specific resource (a schedule), which an agent can tell apart from schedule_delete or schedule_history. It does not explicitly contrast with the closest sibling, fofa_schedule_stop, so the pause-vs-stop boundary is left to inference.

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

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

The pause/resume framing implies when to use it (temporarily disable rather than delete), but there is no explicit when-to-use or when-not-to-use guidance. Nothing tells the agent to prefer this over fofa_schedule_stop or fofa_schedule_update.

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?

Adds real context beyond the annotations: the cancellation is asynchronous because a worker polls every second, and existing history/reports survive the stop. This clarifies the effective latency and the data impact of a non-readOnly, non-idempotent operation, which annotations alone would not convey. It does not say what happens if there is no active run to cancel.

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, front-loaded sentences with the primary action first and a parenthetical qualifier on timing. No filler or redundant restatement of the tool name.

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

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

Given an output schema exists and annotations declare the safety profile, the description covers the essentials: what is stopped, that cancellation is asynchronous, and that history survives. The only gap is undefined behavior when nothing is running, which is minor for a single-parameter control tool.

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

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

Schema description coverage is 0%, so the single schedule_id parameter is documented nowhere. The name is nearly self-explanatory given the tool's purpose, but the description does not compensate at all — no statement of what the id identifies or where to obtain 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+resource: stopping future runs of a schedule and requesting cancellation of the currently active run. The added "Preserve history/reports" clause implicitly separates it from fofa_schedule_delete and fofa_job_cancel, though neither sibling is named 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?

Usage is implied rather than stated: "Stop future runs" tells the agent this halts a schedule without removing it, and "Preserve history/reports" hints at the contrast with fofa_schedule_delete. There is no explicit when-to-use statement and no named alternative, so the differentiation 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?

Annotations already establish that this is a non-readOnly, non-destructive, non-idempotent operation. The description adds meaningful behavioral context beyond that: replacement is done 'while retaining history' and running tasks cannot be edited, clarifying the mutation's boundaries and the fact that prior data 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?

The description is a single front-loaded sentence that moves from action and scope to behavioral constraints. Every clause carries useful information, with no redundant or filler wording.

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 adequately conveys the tool's purpose and key behavioral constraints, and an output schema exists so return values need not be described. However, given the complex nested request schema with no field descriptions, the definition leaves significant parameter guidance gaps for an agent constructing the update payload.

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

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

The schema has 0% description coverage and a nested request object with many fields. The description mentions time, task, and query specification, which maps to some request fields, but it does not explain schedule_id or cover the many other request properties such as name, fields, analyze, language, timezone, max_pages, check_alive, and max_records.

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 ('Replace') and scope ('saved schedule's time, task and query specification'), which clearly distinguishes an update of an existing schedule from sibling operations like create, list, stop, or delete. It does not explicitly name an alternative tool, but the 'saved schedule' framing makes the intended target clear.

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

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

The description implies when to use it by saying it replaces an existing schedule's specification, and it adds one exclusion ('running tasks cannot be edited'). However, it does not explicitly compare against fofa_schedule_create or other schedule-management siblings, nor does it state prerequisites beyond the running-task constraint.

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 read-only, idempotent, open-world, non-destructive behavior, so the safety profile is covered. The description adds a genuinely useful behavioral fact: with no max_pages/max_records you get a single page of `size`, and `total` reports the full population. It omits cost/quota implications (relevant given the observe_cost parameter) and any note on rate limits or result 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?

Two short sentences with no filler and the default-behavior fact front-loaded, which is good. But the brevity crosses into under-specification rather than economy — the second clause is compressed to the point of ambiguity ("both caps", "size", "total").

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 needn't be explained, and annotations cover safety. Still, for a 7-parameter, open-world, quota-consuming search tool with zero schema descriptions, the definition leaves too much — query syntax, field selection, cost observation, pagination strategy — for the agent to guess.

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, so the description must carry the load and largely does not. It only obliquely explains that max_pages and max_records are "caps" and that omitting both yields one page; `query`, `full`, `fields`, `size`, and `observe_cost` get no meaning at all, leaving the most consequential parameters 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?

"Fetch one exact query" gestures at executing a query, but never names the resource (FOFA asset/host search) or what "exact" means. Nothing distinguishes it from siblings like fofa_search_next, fofa_icon_search, or fofa_export, so an agent cannot confidently pick it from the name-plus-description 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?

The only guidance is the implicit default behavior when caps are omitted (one page of `size`). There is no statement of when to use this versus fofa_search_next for pagination, fofa_icon_search for icon lookups, or fofa_validate_query 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?

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so safety is covered. The description adds genuinely useful error semantics for code 40870 and the "immediately" hint that cursors are short-lived, but it omits that the cursor must be replayed with the same query/fields and does not explain cursor 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?

Two short sentences, front-loaded with the primary action, with no filler. The error-handling note is compact and immediately 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?

An output schema exists, so return values need not be described. However, for a five-parameter pagination tool with zero schema coverage, the definition leaves out the critical constraint that query/fields must match the original search and says nothing about how long a cursor remains valid.

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 five parameters, so the description carries the full burden. It only clarifies that the cursor is opaque and must be passed through verbatim; query, fields, size, and full are given no meaning at all, including whether they must match the originating search.

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?

"Continue with the opaque cursor" clearly identifies this as a pagination/continuation operation rather than a fresh search, and the closing "start a new search" implies the alternative path. It never names fofa_search directly, so the sibling differentiation is inferred rather than stated.

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

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

The description tells the agent when to invoke it (holding a cursor from a prior search) and what to do on failure (expired cursor is an error, restart with a new search). It stops short of naming the sibling tool to call for the restart or explaining when a fresh search is preferable to paging.

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 readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description genuinely adds behavior the annotations do not: a 5-second inter-call throttle, a top-5 publication cap, and a field exclusion (product). However, it never says whether the aggregation is over the whole index or the query result set, which is the behavior an agent most needs.

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

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

It is short and front-loads the verb, which is good, but the brevity comes from ellipsis rather than economy: "official dimensions" and "the published contract" are unexplained shorthand that force guesswork. Four clipped fragments do not form a coherent instruction.

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 with 0% parameter coverage and a cryptic one-line description the agent has no way to construct a correct query or know which fields are legal. For a tool with two required parameters this is under-specified.

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 three parameters, so the description must carry the burden and largely does not. "The published contract is the top 5" is a partial hint about size (whose schema default is 5), and "product cannot be aggregated" hints at an invalid fields value, but query and the rest of fields 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?

"Aggregate official dimensions" names an operation (aggregation) but leaves "official dimensions" undefined, so an agent cannot tell whether this aggregates hosts, products, or arbitrary FOFA fields. It is distinguishable from fofa_search only by the word "aggregate", not by any stated scope or output.

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

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

There is no statement of when to use this versus fofa_search, fofa_fields, or fofa_exposure_review, all of which sit adjacent in the sibling list. The only guidance is a negative constraint (product cannot be aggregated) and a throttle, not a routing rule.

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 already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is largely covered. The description adds that content is official and comes from the API appendix, implying a static, cached reference response. It says nothing about how results are scoped or paginated when keyword/section are supplied, so it adds only modest context beyond the annotations.

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 tight sentence with the core purpose front-loaded and no redundant wording. It is efficient, though the brevity comes at the cost of the parameter and usage detail noted elsewhere.

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

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

An output schema exists, so return values need not be described, and the read-only nature is annotation-covered. However, for a two-parameter reference tool with zero schema coverage, the definition should at minimum explain what keyword and section select, and how this differs from fofa_fields.

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

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

Schema description coverage is 0%, so the description carries the full burden for the two parameters, yet it never mentions 'keyword' or 'section' and never explains the default 'overview' section. The parameters' titles are bare ('Keyword', 'Section') with no enum or description, leaving the agent guessing what values are valid.

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

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

The description gives a specific verb and resource: returning FOFA query operators and syntax fields, sourced from the official API appendix. This is clearly a reference/lookup tool, but it never distinguishes itself from the nearby sibling fofa_fields, which plausibly covers overlapping field metadata, so an agent must still infer which one to call.

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, when not to, or which sibling to prefer (fofa_validate_query, fofa_fields, fofa_search). The phrase 'from the API appendix' hints at a static reference lookup, but that is inference rather than 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is known. The description adds the behavioral fact that checks are performed locally and do not consume quota, which is beyond the annotations. This gives the agent confidence that invoking it has no side effects and no cost, though it does not describe what happens on success/failure or the result 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 description is a single sentence that is directly informative and front-loaded with the core purpose. It avoids filler and every word earns its place. It is optimally concise.

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

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

The tool is simple with one parameter, and an output schema exists (not shown but present) which might clarify return values. The description does not state what the output looks like (e.g., a boolean, error list), but for a validation tool with strong annotations and a clear purpose, this is a minor gap. It is adequate but not complete.

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

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

The schema has a single 'query' parameter with 0% description coverage, so the description carries the full burden of explaining its semantics. The description only says 'local syntax checks,' which implies the query is a FOFA query string, but it does not specify the expected format, examples, or what constitutes a valid query. Given zero coverage, the description is inadequate to guide parameter usage.

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

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

The description states a clear verb ('Perform') and resource ('local syntax checks'), and adds a key differentiator: 'without spending FOFA quota.' This distinguishes it from search tools like fofa_search that execute and consume quota, but it does not explicitly contrast with fofa_syntax, which likely provides syntax rules. So it is clear but not fully differentiated from all 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 phrase 'without spending FOFA quota' implies when to use it (when you want a free syntax validation), but it does not explicitly state when not to use it or name alternatives. It neither lists conditions for selection nor excludes scenarios like actually running a search. The 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered structurally. The description adds the meaningful clarification that it only inspects and performs no scanning, but gives no detail on cost, latency, or what 'inspect' entails locally.

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

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

Two short sentences, front-loaded with the action and scope, with the exclusion clause placed immediately after. No filler or redundancy.

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

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

An output schema exists, so return values need not be described, and there are no parameters to document. For a simple read-only inspection tool the definition covers what is needed, though a hint about when to invoke it relative to nuclei_plan or nuclei_execute would make it fully self-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 tool takes zero parameters, so the baseline is 4; there are no arguments whose semantics need explaining. The description's mention of the three inspection dimensions is a slight bonus framing of what the parameterless call yields.

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?

Uses a specific verb ('Inspect') plus concrete resources: the local Nuclei executable, supported template types, and non-Web target formats. It is clearly distinct from the scanning sibling nuclei_execute thanks to the explicit 'Does not scan' clause, though it doesn't differentiate itself from nearby siblings like nuclei_templates or nuclei_guide.

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?

'Does not scan' implicitly tells the agent this is a discovery/precheck call rather than an execution call, which is a useful negative signal. However, it never states when to reach for it (e.g., before building a scan plan) nor names any alternative sibling to use instead for actual scanning.

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, idempotentHint=true, destructiveHint=false, so the safety profile is covered and the description's 'does not execute' clause is consistent with it. It adds only a modest amount beyond that: it clarifies this is a plan-editing step that neither runs scans nor approves them, but not whether base_plan is mutated or a new plan is returned, nor what happens on invalid flags.

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 examples that carry most of the information, and no filler. It is slightly too compressed — the opening sentence lacks a subject/verb, which reads as a fragment rather than a stated purpose.

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. Still, for a tool that takes a nested base_plan plus a flag string, the description omits how the two interact (override vs. merge), which nested fields are reachable via flags, and whether invalid flags fail or are ignored — meaningful gaps for correct invocation.

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

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

Schema coverage is 0%, so the description must carry parameter meaning, and it does for the key 'parameters' string: the examples map flags (-rl, -c, -pt, -id, -severity, -timeout, -retries) onto schema fields like rate_limit, concurrency, protocols, template_ids, severities, request_timeout and retries, plus the crucial constraint 'Key=value is not supported'. The 'base_plan' parameter is left entirely unexplained, and the flag list is illustrative rather than exhaustive, keeping it short of a 5.

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 conveys the input format ('Accept CLI flags') and gives concrete examples, which lets an agent infer that it rewrites/mods a scan plan using nuclei-style flags. However, it never states a clear verb+resource (e.g. 'modify a scan plan'), so the action is inferred rather than declared and the distinction from nuclei_plan is only implicit.

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?

Negative exclusions ('Does not execute shell text or approve the plan') usefully rule out nuclei_execute and any approval step, which is real routing guidance. There is no positive when-to-use statement, no mention of when to prefer nuclei_plan or nuclei_recommend instead, and no note on what happens if flags conflict with base_plan.

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 destructive, openWorld and non-idempotent, so the safety profile is covered structurally. The description adds genuinely new context beyond that: install_if_missing=true triggers official component downloads requiring separate user consent, the operation is asynchronous and must be polled, and the MCP server must stay alive. It still does not say what the scan mutates or how broad the network footprint is, which keeps it below 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 short sentences, front-loaded with the action and followed by the operational constraints. No filler, though the sentence fragments ("Poll fofa_job_status until completed or failed. Keep the MCP server running.") read as terse notes rather than a cohesive instruction block.

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, and the async polling model plus server-lifetime requirement are adequately conveyed. What is missing is the prerequisite chain (approved plan → token) and the scan's target/scope semantics, which matter for a destructive, open-world execution tool.

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

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

Schema description coverage is 0%, so the description carries the full burden for three parameters. It explains only install_if_missing (consent gate for downloads) and passes over plan_id and approval_token entirely, leaving the agent to guess where those values come from and what format they take.

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?

"Start an approved exact scan" gives a verb (start) and a resource (scan), and the word "approved" hints that it consumes a prior plan and approval token. However, "exact scan" is opaque — the description never says what is scanned (Nuclei templates against selected targets) or that this is the execution stage of the plan workflow, so the agent must infer the tool's role from the name 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?

The description sketches a workflow: start the scan, then poll fofa_job_status until completed or failed, and keep the server running. That tells the agent what to do after invoking, but there is no explicit statement of prerequisites (a plan from nuclei_plan and a valid approval token) or when to prefer this over nuclei_plan / nuclei_select_targets.

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 the safe-read, idempotent, non-destructive profile, so the description is not obligated to restate safety. It does add genuinely new behavior: the guide is cached and that cache is invalidated by executable changes, which explains why a stale result is possible and how to fix it. What it omits is the shape of the cached content, though an output schema covers 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 with no filler, and the exclusions and refresh condition are front-loaded. The phrasing is dense to the point of being cryptic ("Executable changes invalidate it"), but nothing is wasted.

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

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

Return values are covered by the output schema and the safety profile by annotations, so the remaining burden is small. Still, for a two-parameter tool with zero schema documentation, the undefined "section" parameter is a real gap that leaves the description short of 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% for both parameters, so the description must carry the burden and largely does not. It implies the meaning of "refresh" through "refresh after updates", but the "section" parameter — which defaults to "overview" — is never mentioned, and no valid section names are enumerated, so an agent cannot construct a non-default call correctly.

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/cache the installed Nuclei command guide" names a specific verb (read/cache) and a specific resource (the installed command guide), and "Does not scan" explicitly separates it from nuclei_execute. It stops short of differentiating it from the other nuclei_* siblings such as nuclei_capabilities or nuclei_templates, so it is clear but not fully disambiguated.

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 concrete usage condition — refresh after the executable changes — and one exclusion (not for scanning). But it never states when an agent should reach for this guide versus nuclei_capabilities, nuclei_plan, or nuclei_templates, leaving sibling selection to inference.

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

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

Annotations already establish non-read-only, non-idempotent, open-world behavior, so the description's credit is for adding that the plan expires and that the token is one-time — both material facts an agent cannot get from the annotations. It stops short of saying whether creating a plan also launches scanning or requires a separate execute call, which is the key remaining ambiguity.

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 trailing "Scanning must be enabled" is a terse fragment whose referent (a server config flag? a prerequisite role?) is unclear, and "exact" is never defined.

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 17-field mutation that emits an approval token, the description leaves the end-to-end workflow unexplained: what the token is used for, whether the plan runs the scan, and how it relates to nuclei_execute. An output schema exists so return values needn't be described, but the planning/approval contract an agent must follow is not conveyed.

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 `request` parameter expands to 17 nested fields (targets, templates, template_ids, all_templates, severities, rate_limit, ttl_seconds, enable_headless, etc.) with 0% schema description coverage. The description explains none of them — notably the mutually exclusive-sounding template selection flags or what ttl_seconds governs — so an agent must guess semantics from field names and bounds 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?

"Create an exact, expiring Nuclei plan and one-time approval token" gives a specific verb (create) and a specific artifact (plan + approval token), which is clearly distinct from siblings like nuclei_execute or nuclei_select_targets. It never names the sibling it complements, so an agent must infer the plan-then-execute relationship from the name 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?

"Scanning must be enabled" is a real precondition, which usefully implies the tool fails otherwise. However, there is no explicit when-to-use vs. nuclei_execute guidance, no statement of what to do with the returned approval token, and no exclusions for cases where a plan is unnecessary.

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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds two useful behavioral facts: output is capped at three candidates and nothing is approved or executed. It says nothing about determinism, latency, or what 'asset-aware' reasoning costs, so it only mildly exceeds 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?

Two compact sentences with the capability first and the non-execution guarantee second; no filler or repetition. The terseness shades into under-specification, but the structure itself is sound and front-loaded.

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

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

An output schema exists, so return values need no explanation, and annotations cover safety. But for a three-parameter tool with zero schema coverage, the description leaves the required 'intent' field, the meaning of 'typed plan', and the relationship to nuclei_plan/nuclei_execute entirely unaddressed. An agent would have to guess how to form a valid 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 description coverage is 0%, so the description carries the full burden, yet it explains none of the three parameters. 'Asset-aware' faintly gestures at the assets array, but intent (the only required field) and targets get no meaning, format, or example. The most load-bearing input to the tool is left completely undefined.

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 verb 'Prepare' and objects 'commands and typed plans' describe a recommendation-generation tool, and 'asset-aware' hints at the input shape. However, 'reasoned' and 'typed plans' are unexplained jargon, and the description never says these are Nuclei scan commands, so an agent must infer the domain from the tool name alone. It only indirectly distinguishes itself from nuclei_plan and nuclei_execute.

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 sentence 'No plan is approved or executed' draws a boundary but gives no when-to-use guidance, no prerequisites, and no named alternatives among the many siblings (nuclei_plan, nuclei_customize, nuclei_select_targets, nuclei_execute). An agent cannot tell from this text whether to call nuclei_recommend before nuclei_plan or instead of it.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, and the description is consistent with them while adding genuine behavior: missing decisions keep candidates by default, and shared IP/title must not merge virtual hosts or cross protocol/port boundaries. Those default and merge rules are exactly the kind of detail annotations cannot express. Return format is not described, but an output schema 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?

It is short, but written in telegraphic fragments ('First omit decisions to read numbered candidates') whose meaning is hard to parse on first read, and the exclusion sentence is front-loaded as a run-on. The information is there but the structure is choppy rather than cleanly sequenced.

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-phase workflow tool with an output schema, the decision loop and merge constraints are covered, so an agent can roughly drive it. The gap is input-side: with 0% schema coverage and no explanation of intent/targets/assets, the agent cannot confidently construct the first call, which is a material omission for a required-parameter tool.

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

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

Schema description coverage is 0%, so the description carries the full burden. It does document the decisions element shape ({id,action,reason,duplicate_of}) and the keep/exclude/duplicate action vocabulary, which is valuable. However, the required 'intent' and 'targets' parameters and the optional 'assets' parameter are never explained – what format targets take or what intent governs is left to guesswork.

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 'Prepare or validate host-AI target selection', a specific verb pair, but 'host-AI target selection' is undefined jargon and the two-phase nature (propose candidates, then submit decisions) only becomes clear from the later sentences. The negative clause ('No model/API calls, probing, approval or execution') does help separate it from execution siblings like nuclei_execute, but no sibling is named directly.

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 ordered workflow: first call without decisions to read numbered candidates, return decisions, present the audit, then approve an exact plan. That is real when-and-how guidance. What is missing is routing against the closest siblings (nuclei_plan, nuclei_recommend, nuclei_execute) – the agent must infer that this tool never executes.

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 readOnly, idempotent and non-destructive, so the safety bar is low. The description still adds real value by clarifying that no scan traffic is generated and that exact template IDs/paths are gated behind an approved plan, which is the kind of policy 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?

Two short sentences with the non-scanning guarantee front-loaded and the plan-gating caveat following. Nothing is wasted, though the second sentence is compressed to the point of being slightly cryptic.

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 needn't be spelled out, yet the description helpfully previews the returned fields and the safety posture. For a read-only three-parameter listing tool it is nearly complete, with only the keyword and limit semantics 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 0%, so the description carries the full burden for the three parameters. It only gestures at protocol filtering, and never explains what "keyword" matches or how "limit" is applied, leaving two of three parameters undocumented in both schema and prose.

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

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

The description gives a specific verb and resource ("List installed template IDs, protocol, severity and network ports") and immediately contrasts with scanning, which separates it from nuclei_execute and nuclei_plan. It stops short of naming those siblings outright, so differentiation is implied rather than 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?

"without scanning" plus "Exact IDs/paths still need an approved plan" tells the agent when this is the cheap discovery step and when to escalate to the planning tool. It stops short of naming nuclei_plan or nuclei_recommend directly, leaving the handoff to inference.

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