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

Annotations already establish read-only/harmless behavior. The description adds valuable behavioral context: it loads FiveM's current CEF pin, statically audits code, and is heuristic rather than authoritative. This goes beyond the annotations without contradicting them, though it doesn't detail return values or edge cases.

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 tightly written sentences, front-loaded with the core action ('Load... then statically audit'). Every word earns its place; no fluff 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?

Given the output schema, annotations, and sibling context, the description fully covers the tool's purpose and its constraints. It clarifies the heuristic nature and the dependency on FiveM's CEF pin, making it complete for an AI agent to make an informed invocation decision.

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%, but the description compensates by enumerating the supported file types (JavaScript, TypeScript, JSX, TSX, CSS), which directly maps to the 'loader' enum. The 'source' parameter's purpose is clear from the audit context, even if not spelled out explicitly.

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 ('audit') and a clear resource ('NUI compatibility' with supported file types). It distinguishes itself from sibling tools by specifying that it loads FiveM's CEF pin and performs a static, build-time review rather than a runtime test.

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

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

The description clearly frames when to use the tool: for static, build-time compatibility checks against the verified Chromium milestone. It explicitly excludes runtime browser testing, which helps differentiate from possible runtime test tools, though it does not name specific sibling 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 declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds a meaningful behavioral trait: 'It never claims a speedup without measurements,' which sets expectations for evidence-based output. This goes beyond the annotations by specifying a policy.

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

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

The description is two sentences, front-loaded with the verb and object. Every word provides value: the evidence types and the no-speedup claim. No fluff or repetition.

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 only two parameters and an output schema, so return values are covered. However, the description lacks guidance on what constitutes a valid 'scenario' or how 'runtime' influences the plan. This creates a gap in fully supporting a correct invocation, though the low complexity keeps it from being critically 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 by explaining parameters. However, it does not mention 'scenario' or 'runtime' at all. The enum values for runtime are self-explanatory, but 'scenario' is undefined beyond a length constraint, leaving the agent to guess its meaning.

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

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

The description clearly states a specific verb ('Create') and resource ('reproducible measurement plan'), and specifies the evidence types (profiler, resmon, network, or NUI). This distinguishes it from sibling tools like get_native or audit_nui_compatibility, which serve different purposes.

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

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

The description implies usage for creating a measurement plan but does not explicitly state when to use this tool over siblings or mention any exclusions. The phrase 'Create a reproducible measurement plan...' indicates the context, but no alternatives or prerequisites are given.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that it reads from the official FiveM repository and parses the build pin, but does not disclose additional behaviors such as network access, caching, or rate limits. It provides minimal extra value 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?

The description is two sentences, with the action and resource stated first, followed by a practical usage hint. Every word earns its place with no redundancy or filler.

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

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

For a read-only tool with no parameters and an output schema present, the description provides the essential information: what it does and when to use it. No important gaps are apparent, and the context is fully adequate for the tool's simplicity.

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

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

The input schema has zero parameters, so there are no parameter semantics to explain. The baseline for 0-parameter tools is 4, and the description properly avoids unnecessary parameter details.

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

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

The description uses a specific verb 'Read and parse' and identifies the exact resource: 'the current CEF/Chromium build pin from the official FiveM repository'. This clearly distinguishes it from sibling tools like audit_nui_compatibility or get_native, which serve different purposes.

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

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

The instruction 'Use before choosing an NUI browser target' provides a clear and explicit usage context. It does not mention alternatives or exclusions, but for a 0-parameter read-only getter, this is sufficient 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 indicate a safe read operation. The description adds valuable behavioral context: 'unknown identifiers return not_found' and the requirement to specify the API set, which are not covered by annotations. No contradiction.

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

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

The description is two sentences, front-loaded with the core action, and every word contributes. It is concise without being under-specified.

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 an output schema, the description adequately explains the lookup purpose, required disambiguation (apiSet), and error behavior (not_found). It could go deeper on case sensitivity or exact matching rules, but the essentials are covered.

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

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

With 0% schema description coverage, the description partially compensates by clarifying 'identifier' as a native name or hash and 'apiSet' as the execution API set. However, it does not explicitly address the 'kind' parameter, though the name/hash enum is implied. Some meaning is added, but not fully.

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 the specific verb 'Look up' and names the resource ('exact native name or hash') and source ('official sources'). It distinguishes itself from the sibling 'search_fivem_docs' by emphasizing exact lookup rather than 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 implies usage for exact native lookup and notes a requirement (must provide execution API set), but it does not explicitly mention when to prefer this tool over alternatives like search_fivem_docs, nor does it state any exclusions.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description does not contradict them. It adds the context that the result is 'verified' and intended as pre-coding knowledge, but it does not disclose additional behavioral traits such as whether it performs version checks or network calls. With annotation coverage, a score of 3 is appropriate.

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

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

The description is one clear, front-loaded sentence that efficiently states the purpose and usage context without any filler.

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

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

The tool has no parameters and an output schema exists, so the description does not need to explain return values. The description adequately conveys the tool's role as a pre-coding baseline provider. It could elaborate on what the baseline includes, but given the presence of an output schema and low complexity, it is sufficiently complete.

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

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

The tool accepts zero parameters, so the input schema fully covers parameter semantics. The description does not need to elaborate on parameters, and the baseline for 0 params is 4.

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 'Return[s] the verified GTAV Enhanced baseline and the context that must be known before writing code.' The verb 'Return' and resource are specific, and the purpose is distinct from sibling tools like search_fivem_docs or get_native. Slight vagueness in 'baseline' prevents a 5.

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

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

The description implies usage context with 'before writing code,' suggesting when to call this tool. However, it does not explicitly compare with alternatives or state when not to use it, which limits the 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?

Beyond the annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false), the description adds valuable context: it explicitly states the tool refreshes from allowlisted official sources and that it does not alter FiveM projects or external services. This clarifies that the only mutation is to the local cache, providing a complete safety profile.

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

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

The description is two sentences, front-loads the primary action ('Explicitly refresh'), and includes only relevant information. Every word serves a purpose, with no redundancy or filler.

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

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

For a zero-parameter tool with an output schema present, the description is entirely sufficient. It covers what the tool does, the sources it uses, and its non-destructive nature. There is no additional complexity that requires further 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?

The tool has zero parameters, so there is nothing for the description to explain. The schema coverage is trivially 100%, and no parameter information is needed. The description adds no parameter details, but that is appropriate given the input schema is empty.

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 function: explicitly refreshing the local cache from allowlisted official Cfx.re and citizenfx sources. It uses a specific verb (refresh) and identifies the resource (local cache) and the sources, distinguishing it from sibling tools like source_health or get_native. The additional clarification that it does not modify any FiveM project or external service further disambiguates its scope.

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

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

The description implies usage when a cache refresh is needed, but it does not explicitly state when to use this tool versus alternatives such as source_health, or mention any prerequisites or exclusions. No alternative tools are referenced, so guidance is limited to the implied context of manual cache refresh.

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 destructiveHint=false, so the description adds the 'static heuristic' nature and specific review focus, which goes beyond the annotations. It does not contradict annotations and provides useful context about the review's scope and limitations (heuristic implies possible false positives).

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 front-loads the action and lists the specific review aspects. No redundant words or filler, making it highly concise and well-structured.

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

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

Given the presence of an output schema and annotations covering safety, the description is complete enough for the tool's purpose. It conveys the scope (static heuristic review) and the specific security concerns, though it could add a brief mention of the language parameter or typical use case, but these are not critical.

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 parameter meanings. It references 'supplied code' (implying the 'code' parameter) but does not explain the 'language' parameter at all. The description adds minimal value beyond the schema's enum values, leaving the language parameter's role 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 the tool's function: performing a static heuristic review of supplied code for specific security issues (untrusted network input, broadcasts, unstable source usage, event-context mistakes). This specific verb+resource+scope distinguishes it from sibling tools like review_resource_structure and review_state_bag_usage, which focus on different aspects.

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

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

The description implies the tool is used when a user wants to review code for security concerns, but it does not explicitly state when to use it versus alternatives or mention any exclusion criteria. Unlike a high-scoring example, it lacks explicit 'when to use' or 'use instead' 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 and destructiveHint=false, so the safety profile is known. The description adds useful context by specifying that the review checks against 'documented FiveM requirements' and the 'client/server/shared/NUI house standard', giving the agent a sense of what criteria are applied. It does not mention side effects, rate limits, or auth, but the non-destructive nature is reinforced by the verb 'Review'.

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

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

The description is a single, well-structured sentence that leads with the action verb 'Review' and the object, followed by the criteria. There is no redundant phrasing, and every word contributes to the meaning. It is appropriately sized for the tool's 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?

Given that an output schema exists (so return values need not be described) and annotations cover safety, the description is largely complete. It conveys the tool's purpose, what it checks against, and the target audience (project-specific standards). However, the lack of parameter semantics and explicit usage guidance leaves minor gaps, but overall it is sufficient for a review tool with a clear scope.

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 explicitly explain the parameters. 'paths' is only vaguely implied by 'resource file list', and 'uiRequired' is only hinted at via 'NUI house standard'. The description fails to compensate for the lack of schema descriptions, leaving the agent to infer the meaning and format of the inputs, especially the boolean 'uiRequired' flag.

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

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

The description clearly states a specific verb ('Review') and resource ('supplied resource file list'), and specifies the criteria ('documented FiveM requirements and this project's explicit client/server/shared/NUI house standard'). This distinguishes it from sibling tools like validate_fxmanifest (which likely validates manifest syntax) by focusing on structural review against both external and project-specific standards.

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

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

The description implies when to use the tool: when you need to check a resource file list against FiveM requirements and the project's house standard. It does not explicitly name alternatives or exclusions, but the scope is clear enough to differentiate from sibling tools like review_event_security or validate_fxmanifest. It lacks explicit 'use this instead of X' guidance, but the context is sufficiently defined.

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 destructiveHint=false, so the safety profile is known. The description adds the 'static heuristic' nature, indicating analysis without execution, and lists the specific risk categories it checks. This provides behavioral context beyond the annotations, though it does not detail the output 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, front-loaded sentence that efficiently conveys the action and the three review focus areas without unnecessary words or repetition. It is concise and well-structured.

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 (not shown), so return values are presumably documented there. The description clearly scopes the review to three risk areas and implies a code context via the language parameter. However, it does not explicitly mention that the code should be for a specific platform or that input code must be provided, though these are inferable from the sibling tools and schema.

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

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

The schema has 0% description coverage, and the description does not mention the parameters 'code' or 'language' at all. The parameter names are somewhat self-explanatory, but the description fails to explain that 'code' is the source code to review and 'language' selects the language-specific parser. This is a notable gap given the 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 ('Perform') and resource ('State Bag usage') with three concrete focus areas: nested State Bag serialization, scope-event scaling, and client replication risks. This clearly distinguishes it from sibling tools like review_resource_structure or audit_nui_compatibility, which target broader or different concerns.

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 for code review related to State Bags, but it does not explicitly state when to use this tool versus alternatives or provide exclusions. The focus on State Bag risks provides clear context, but there is no direct guidance on selecting it among sibling review 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, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that the search is over a 'focused corpus' and from 'official Cfx.re documentation,' which is useful context. But it does not disclose other behavioral traits like return format, pagination, or rate limits. This aligns with the baseline where annotations carry safety and the description contributes minimal extra behavior.

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

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

Two concise sentences, front-loaded with the core action. Every word 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 is a simple search over a specified corpus, and the description covers purpose, scope, and usage topics. With safe annotations and an output schema present, this description is sufficient for an agent to select and invoke the tool correctly without additional context.

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

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

The input schema already documents both parameters with constraints (query: minLength/maxLength; limit: default/min/max). The description does not explain parameter semantics further, and schema coverage is 0%. While the parameter names are intuitive for a search tool, the description adds no value beyond what the schema provides.

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 'Search a focused corpus loaded from official Cfx.re documentation' with a specific verb (search) and resource (focused corpus). It also differentiates from siblings by specifying the domain (GTAV Enhanced, runtime, NUI, etc.), making it distinct from other tools like get_native or validate_fxmanifest.

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

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

The description gives explicit usage context: 'Use for GTAV Enhanced resource, runtime, NUI, networking, security, and performance questions.' This tells the agent when to invoke the tool. However, it does not mention when not to use it or mention alternative tools, so it is slightly below the highest bar.

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 destructiveHint=false, covering the safety profile. The description adds specific behavioral context by listing what is reported (freshness, cache state, errors), which aligns with read-only status and no contradiction.

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

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

A single, front-loaded sentence with the verb 'Report' and no filler. Every word adds value, making it appropriately sized and structured.

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 status-reporting tool with no parameters, a read-only annotation, and an output schema, the description is complete enough. It states the subject and key report aspects. Minor gaps exist (e.g., when to use vs. refresh_sources), but complexity is low.

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

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

The tool has zero parameters, so the description cannot add parameter meaning. Per baseline for 0-param tools, this is a 4. The description fully explains what the tool does without needing parameter details.

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

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

The description uses the specific verb 'Report' with resource 'official sources' and scope 'checked by this MCP process.' It clearly distinguishes this from the sibling refresh_sources, which implies updating rather than reporting 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?

No explicit when-to-use guidance or alternative comparison is provided. The context implies a reporting/status role, but there is no mention of how it relates to refresh_sources or when one would prefer this over other 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 and destructiveHint=false, so the safety profile is covered. The description adds value by disclosing the specific rule categories checked (Enhanced-only, compiled outputs, NUI packaging, deprecated/experimental fields), which goes beyond the annotations. No contradictions found.

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 immediately states the purpose and lists specific validation aspects without any redundant phrasing. Every word contributes meaning.

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

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

Given the tool's moderate complexity (validation with one required and one optional parameter), the description covers the core behavior and validation categories. The presence of an output schema and annotations compensates for lack of return detail. However, the unexplained 'resourceFiles' parameter prevents a perfect score.

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 explains the 'manifest' parameter implicitly via 'supplied fxmanifest.lua text'. It does not explain 'resourceFiles' at all, leaving a significant gap for the optional array parameter. Even though there are only two parameters, half are 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?

Description uses a specific verb ('Validate') with a distinct resource ('supplied fxmanifest.lua text') and enumerates specific validation dimensions (Enhanced-only rules, compiled script outputs, NUI packaging, deprecated/experimental fields). This clearly distinguishes it from sibling tools like audit_nui_compatibility or review_resource_structure.

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 implicitly communicates when to use this tool by listing the exact validation criteria, which aligns with validating a manifest before deployment. It does not explicitly name alternatives or exclusions, but the scope is clear enough to guide tool selection among siblings.

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