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 cover read-only, idempotent, open-world, and non-destructive behavior. The description adds the important behavioral boundary 'never scan,' which is not fully implied by readOnlyHint, and hints at the bundled data inputs. It doesn't add details like rate limits or external side effects, but those are largely covered by 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?

The description is one compact sentence with no filler. Key action, scope, and the critical 'never scan' boundary are all included immediately and efficiently.

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

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

Annotations and output schema cover safety, idempotency, and return structure, so this is not a bare tool. However, the required 'intent' parameter is left underspecified, and the description does not explain how the bundled data is used or what kind of planning output to expect. It is minimally viable but has clear gaps around invocation.

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

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

Schema description coverage is 0%, so the description carries the burden of explaining parameters. It does not explain what 'intent' should contain or how max_pages and max_records influence planning. The phrase 'planning with bundled...' implies intent is the user objective, but this is not explicit enough to compensate for the complete lack of schema descriptions.

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

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

The description states a specific verb ('Run planning') and a resource scope ('bundled app= fingerprints and evidence-labelled website candidates'). It also explicitly distinguishes itself from scanning tools with 'never scan,' which differentiates it from siblings like nuclei_execute and fofa_search.

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

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

The description clearly signals this tool is for planning rather than scanning, giving an explicit exclusion. However, it does not name alternative tools or specify exact conditions for when to choose this over siblings like nuclei_plan or fofa_search.

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

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

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, and destructiveHint, so the description does not need to repeat the safety profile. It adds useful behavioral context beyond the annotations by disclosing that this operation is quota-free and versioned, which matters for cost-sensitive tool selection.

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 concise sentence with no filler. The key fact (what is returned) is front-loaded, and the quota note is a valuable addition that earns its place.

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

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

Given zero parameters, a rich annotation set, and an output schema, the description fully covers everything an agent needs to decide whether and how to call this tool. No important contextual information is missing.

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

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

The tool has zero parameters and schema coverage is 100%, so there are no parameter semantics for the description to clarify. This is the appropriate baseline 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 names a specific verb ('Return') and resource ('versioned FOFA field and membership capability catalogue'), making the tool's function immediately clear. It also distinguishes this metadata endpoint from search tools by noting it does not consume quota.

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

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

The description gives clear context: this is the appropriate tool when an agent needs the field/capability catalogue without spending quota. It does not explicitly exclude alternatives or name sibling tools, but for a zero-parameter informational endpoint the intended usage is self-evident.

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 mark the operation read-only, idempotent, and non-destructive; the description adds an access caveat (registered users lack the Host API) and input scope. This is meaningful non-obvious context beyond the schema and annotations, though it doesn't discuss rate limits.

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

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

Two short sentences, front-loaded with the action and target, followed by the access caveat. No filler or repetition of schema details.

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

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

For a simple two-parameter read-only tool, the description covers what, target, and access constraints, and an output schema exists so return values don't need restating. The main gap is the unexplained `detail` parameter and lack of a named fallback for non-privileged users.

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

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

The description clarifies that `host` accepts either an IP or DNS name, which is not in the schema. However, the `detail` boolean is never explained, and schema description coverage is 0%, leaving one of two parameters semantically opaque.

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 ('Get'), a precise resource ('FOFA Host aggregation'), and a cardinality constraint ('one IP or DNS name'), which clearly sets it apart from sibling search, icon, and stats tools.

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

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

Gives a clear access exclusion ('Registered users have no Host API') and the target condition ('for one IP or DNS name'). It does not name an explicit alternative such as fofa_search, so it stops short of a 5.

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

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

The annotations already establish read-only, idempotent, open-world, and non-destructive behavior. The description adds useful context beyond those: it performs an outbound fetch of a public website favicon and computes a MurmurHash3 value before searching FOFA, which is behavior not shown in the schema or 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?

The description is a single, front-loaded sentence that lays out the full pipeline without fluff. Every phrase adds meaningful information, and the structure makes the operation sequence immediately understandable.

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?

Although annotations cover safety and an output schema exists, the description leaves three of four parameters completely undefined and offers no guidance on edge cases like unreachable favicons or invalid URLs. For an agent to call this tool correctly, the optional parameters need semantic explanation.

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 only implicitly clarifies the url parameter by mentioning a public website favicon. The parameters full, size, and fields receive no explanation at all, so the agent cannot confidently know what they control or how to set them.

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

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

The description clearly states the tool's workflow: fetch a public favicon, compute FOFA MurmurHash3, and search matching assets. It is specific about the resource and action, but it does not explicitly differentiate itself from sibling tools like fofa_search or fofa_search_next, so it stops short of a top score.

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

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

No explicit guidance is given about when to use this tool versus fofa_search, fofa_search_next, or other siblings. The usage is only implied by the icon+hashing approach; there are no stated conditions, exclusions, or alternative suggestions.

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?

Annotations already signal readOnly, idempotent, and non-destructive behavior. The description adds that the tool returns official queries meant to be used verbatim, which is useful, but it does not describe the output format or any other behavioral details beyond what annotations and the output schema provide.

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 efficient sentence that front-loads the action and resource, then adds a concrete usage directive. Every word earns its place.

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

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

For a simple read-only lookup with one optional parameter and an output schema, the description provides enough context: what it searches, when to call it, and how to use the results. Minor gaps around accepted keyword formats do not undermine the overall completeness.

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

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

Schema description coverage is 0%, so the description carries the burden of explaining the 'keyword' parameter. It does not clarify whether the keyword is an exact match, substring, or how an empty value behaves, leaving the parameter semantics 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 has a specific verb ('Search') and resource ('bundled official app= names'), making the tool's purpose clear. It also distinguishes its role by saying to call it before product searches, though it does not explicitly contrast it with sibling tools.

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

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

The instruction 'call before product searches and use returned queries verbatim' provides clear guidance on when to use this tool. It does not mention alternatives or exclusions explicitly, but the intended sequencing is clear.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is known. The description adds that it runs exactly one search page (not automatic pagination) and that queries from fofa_rules should be pasted verbatim, which is informative but not extensive.

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

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

Two sentences, front-loaded with the core action and followed by the routing rule. No filler or redundant material; 'read-only' is the only duplication of annotation, but it's one word.

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 4 parameters, 0% schema coverage, and many siblings, the description should explain parameter effects and when to prefer fofa_search_next or fofa_icon_search. It only addresses the fofa_rules case and leaves pagination and alternative search modes unspecified. Output schema exists, which covers return values, but input side is incomplete.

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

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

Schema description coverage is 0%, so the description must compensate, but it only hints at the query parameter ('paste its query verbatim'). It doesn't explain full, size, or fields semantics, leaving the agent to guess their meaning. This falls short of the requirement to cover 4 parameters.

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

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

The description specifies the action ('Run') and resource ('FOFA search page'), and explicitly scopes to a single page. The conditional routing to fofa_rules distinguishes it from that sibling, though it doesn't enumerate other search variants (icon/host/stats).

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

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

It gives an explicit when-not: if the user named a product/OA/VPN, call fofa_rules first and paste the query verbatim. This is a clear alternative/pre-route. However, it doesn't mention other related tools like fofa_search_next for pagination or fofa_icon_search for image-based search, so guidance is partial.

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, openWorldHint, idempotentHint, and non-destructive, so the safety profile is covered. The description adds useful context that the cursor is opaque and originates from fofa_search, but it does not mention behavioral constraints like cursor expiry or the need to keep query/fields consistent.

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

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

A single sentence that front-loads the action and then states the prerequisite. Every word earns its place, with no fluff or repetition of schema 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?

With an output schema and safety annotations present, some gaps are acceptable, but the description still omits key continuation-call requirements: it does not state that the same query and fields must be passed, nor does it clarify size/full semantics. For a 5-parameter tool with zero schema descriptions, this is too thin for confident correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It explains only that the cursor is opaque and comes from fofa_search, but it provides no meaning for query, fields, full, or size, and does not clarify that query/fields likely need to match the original 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?

The description uses a specific verb, 'Continue', with a clear resource, 'FOFA search', and names the mechanism, the opaque cursor returned by fofa_search. It distinguishes itself from fofa_search by making clear it is the continuation step, not the initial search.

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 indicates this tool should be used after fofa_search, since the cursor comes from that tool. It does not explicitly list exclusions or say 'use fofa_search for the first page,' but the 'continue' framing makes the intended flow obvious.

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=false. The description adds meaningful behavioral context beyond that: the account-type limitation that may cause the call to fail, and the meaning of size as Top-N with a default of 5. This is useful, non-obvious information that helps an agent anticipate behavior.

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

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

Three short sentences with no filler: the core purpose comes first, followed by an important limitation and a parameter detail. Every sentence earns its place, and the structure is easy to scan.

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

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

The tool has an output schema and safety annotations, so return structure and read-only nature are covered. However, the description does not clarify the semantics of the fields parameter or how the stats are grouped, which is central to using the tool correctly. The account limitation is helpful, but the overall picture is only partially 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%, so the description must compensate for all parameters. It explains size as Top-N with a default, but leaves query and fields entirely semantically ambiguous. An agent cannot tell what query syntax is expected or what fields enumerate (e.g., grouping keys for statistics), which is a substantial gap.

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

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

The description states a clear verb-resource pair ('Get FOFA stats'), so the basic purpose is understandable. However, it does not differentiate this tool from siblings like fofa_search or fofa_icon_search, leaving an agent to infer what kind of 'stats' are returned and how that differs from raw search results.

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 mentions a constraint (personal/education accounts have no stats API) but gives no explicit direction on when to choose fofa_stats over alternatives such as fofa_search. No when-to-use or when-not-to-use guidance versus sibling tools is provided, leaving the selection decision largely 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 readOnlyHint=true and idempotentHint=true, and the description's 'Return' wording aligns with that. It adds the context that the content comes from the official API appendix, but no deeper behavioral details such as caching, rate limits, or response characteristics are disclosed.

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

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

The description is a single, focused sentence that leads with the action and clearly states the output and source. Every word earns its place; there is no redundant or filler content.

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

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

For a zero-parameter, read-only reference tool with an output schema and safety annotations, the description is largely complete. It clearly communicates what the agent will receive. A minor gap is the lack of explicit relationship to sibling syntax-related tools.

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

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

The tool has zero parameters, so there is no parameter documentation burden. With schema coverage at 100% and no parameters to explain, the baseline of 4 applies and the description needs to add nothing further about parameters.

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

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

The description uses a specific verb ('Return') and names the resource ('FOFA query operators and syntax fields') with its source ('API appendix'). It is clear, but it does not explicitly distinguish itself from sibling tools like fofa_fields or fofa_rules.

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

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

The intended use is implied: call this tool to get FOFA syntax and operators. However, it does not state when to prefer this over related tools or mention any exclusions, so usage guidance is only implicit.

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

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

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 destructive and non-idempotent behavior, so the description does not need to restate those. It adds valuable specifics: the approval is consumed exactly once, which implies later calls will fail or have no effect. This goes beyond the annotation hints and clarifies the one-shot nature of execution.

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

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

The description is a single tight sentence with no filler. It front-loads the core behavior and the one-time consumption constraint, making every word meaningful.

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 cover destructive/non-idempotent behavior, the description covers the essential operational concept. However, with 0% parameter coverage, the agent still lacks guidance on what the two required inputs mean and how to obtain an approval token. The definition is minimally adequate but leaves room for confusion about invocation details.

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, but it never explicitly explains `plan_id` or `approval_token`. The phrases 'scope-bound approval' and 'exact plan' loosely map onto the parameters, but the description does not state how to obtain or format the token, nor what the plan_id refers to concretely.

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

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

The description names the exact operation: consume a scope-bound approval and execute that exact plan. The verbs 'consume' and 'execute' plus the resource 'scope-bound approval'/'exact plan' make the tool's function clear. It also distinguishes itself from sibling tools like nuclei_plan, which likely handles planning rather than execution.

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 'consume a scope-bound approval exactly once' establishes clear preconditions and a critical constraint: this tool should be called only when a valid approval exists and must not be called repeatedly. It does not explicitly name alternatives or state when not to use the tool, but the context is reasonably clear from the description.

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

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

Annotations already indicate this is non-read-only and non-destructive, but the description adds useful behavioral context: the plan expires, the token is one-time, and scanning must be enabled. This goes beyond the structured annotations without contradicting them.

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 conveys the core action, key constraints, and a prerequisite. There is no filler or redundancy.

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

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

For a tool with a nested request schema and an output schema, the description covers the main purpose and prerequisites well. It does not explicitly connect the generated plan/token to the nuclei_execute sibling, but the workflow is reasonably inferable from the tool naming and 'one-time approval token' phrasing.

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 explain any parameter beyond indirectly aligning 'expiring' with ttl_seconds and 'exact' with template/severity selection. The property names in the schema are self-explanatory, but the description adds little field-level value.

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

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

The description uses a specific verb ('Create') and specifies the resource ('an exact, expiring Nuclei plan and one-time approval token'). It clearly differentiates from sibling 'nuclei_execute' by focusing on plan/token creation rather than execution.

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

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

The description implies usage context through the plan/token workflow and gives the prerequisite 'Scanning must be enabled.' However, it does not explicitly say when to use this tool versus nuclei_execute or any other sibling, nor does it give exclusions.

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