RPScripts FiveM Developer

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld=false, and the description adds genuinely new behavioral context: results are tri-state (supported, unsupported, unknown) each with evidence, and nothing is asserted without a source. That tells the agent how to interpret and trust the output, which the annotations do not. It stops short of describing response shape or how conflicts are reported.

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

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

Two sentences, front-loaded with the verb and the two input modes, with no filler. The first sentence is a long comma chain of check dimensions, but each item carries information the agent needs; the closing sentence justifies the evidence-based behavior.

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

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

With 8 optional parameters and no output schema, the description covers both the input modes and the nature of the result (tri-state with evidence), which is the hard part. The remaining gap is that zero parameters are required and the description never says what a minimal or empty call yields, which slightly underspecifies an 8-param optional-only 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 coverage is 88%, so baseline is 3; the description earns an extra point by mapping nearly every parameter to a purpose — product slug, framework list matching the enum, artifact number, game build, OneSync, and server resource-list conflicts — and by naming concrete resource examples (ox_lib, ox_inventory, ox_target, oxmysql) for the `check` array. It does not address the `files` payload beyond what the schema already says.

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?

Opens with a precise verb+resource: checks whether a product (by slug) or the caller's own resource files fit a server, and enumerates exactly which axes are evaluated (framework, required resources, artifact, game build, OneSync, conflicts). That enumeration separates it from validate_resource and validate_server_cfg in practice. It never names those siblings, so the 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?

Usage is implied by the parameter framing ("your server's framework", "resources your server starts"), so an agent can guess this is a pre-install/feasibility check. But there is no explicit when-to-use, when-not, or pointer to validate_resource / validate_server_cfg for the adjacent tasks.

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 closed-world, and the description is consistent with that by saying the output is returned after checking ('checked statically with RPScripts Lab before it is returned') rather than describing server-side mutation. It adds genuine behavioral context beyond annotations: which framework install entries are emitted (shared jobs entry or ESX SQL), that a README is included, and that a static validation gate runs before return. Minor gap: it doesn't confirm whether any files are written to disk, which would fully resolve the 'create' vs readOnlyHint tension.

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 opening clause is well front-loaded (verb, resource, frameworks) and the preset/spec sentence earns its place. However, the middle is a single sprawling enumeration of ~20 feature components that reads as a feature dump, and the trailing template list duplicates the preset enum verbatim, so not every token pays for itself.

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

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

There is no output schema, so the description carries the return-value burden, and it does so reasonably: it describes the generated resource contents, the framework install entries, and the README, and it flags that results pass static validation first. It could say more about error/validation-failure behavior or the exact return shape, but an agent has enough to call it correctly.

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

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

Schema description coverage is already 80% and the schema documents the name/label/preset/spec overrides. The description reinforces the preset-plus-spec composition and notes the spec replaces the template, but it repeats the template list that is already an enum and adds no format detail for the free-form nested spec object beyond pointing at rpcrate.job.json. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

States a specific verb and resource: 'Generates a complete job resource with the RPScripts Jobs Creator for QBCore, Qbox or ESX', followed by the concrete artifacts produced (job definition, grades, duty, stash, garage, install entries, README). This is clearly distinguishable from generation siblings like generate_script or generate_fxmanifest because the resource type and framework scope are named up front.

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 explains the two invocation strategies explicitly: 'Start from a template (preset) and/or pass a full spec', and gives an iterative workflow ('generate a preset, edit that file, pass it here'). It stops short of the 5 level because it never states when NOT to use this tool or names the sibling to use instead (e.g. validate_resource for an existing resource).

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, so the safety profile is covered. The description adds real behavioral detail beyond that: the fixed header (fx_version 'cerulean', game 'gta5'), automatic validation against RPScripts manifest rules, and the deliberate omission of a lua54 line because Lua 5.4 is the default runtime. It stops short of saying whether the manifest is written to disk or returned as text, which matters even with readOnlyHint set.

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 action is front-loaded in the first clause and the entire definition is a single dense sentence with no filler. It is tightly packed but borderline overloaded, holding header values, supported content, validation, and runtime defaults in one run-on.

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 12 optional parameters, 67% schema coverage, and no output schema, the description should clarify the return shape and validation failure behavior. It explains the header and runtime defaults but leaves open whether the manifest text is returned, whether validation errors abort generation, and how preset interacts with explicit script/file parameters.

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

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

Schema coverage is 67%, and the description's content list loosely maps to several parameters (scripts to client/server/shared_scripts, NUI to files/ui_page, maps and vehicle data to data_files). However, it never mentions the preset enum, author, version, description, or node_version explicitly, so parameters without schema descriptions remain unclarified.

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 artifact: generates an fxmanifest.lua with a fixed fx_version/game header, and enumerates the content classes it can cover (client/server/shared scripts, NUI, maps, vehicle data, dependencies). This is clearly distinguishable from siblings like generate_script, validate_resource, and check_compatibility.

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

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

Usage is implied by the content list (Lua or JS scripts, NUI, maps, vehicle data), but there is no explicit when-to-use or when-not-to-use guidance and no reference to alternatives such as validate_resource or generate_script. The agent must infer the calling context from the feature list.

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

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

Annotations only tell the agent it is non-read-only and non-destructive; the description adds the valuable operational context that annotations cannot: personal link, minimum 5-minute lifetime, a 20-downloads-per-product-per-day quota, and auth. Minor gap: it references 'expires_at' which is not defined anywhere (no output schema), and it does not say what happens when the quota is exhausted.

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 action and resource, with no filler. Slightly dense with parenthetical asides ('longer for large files, see expires_at'), but every clause carries information.

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

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

For a two-param, no-output-schema tool, it covers auth, quota, and link lifetime well enough to call it correctly. The remaining hole is file_index semantics and what the response actually contains (the URL field), which the agent must 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%, so the description must carry parameter meaning. It explains where product_id comes from (list_purchases) but says nothing about file_index – how to determine it, what 0 means, or that it selects among multiple files. Half of the parameter surface is 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 verb, resource and scope: 'Creates a signed download link for one file of a product the signed-in customer owns'. It even names the sibling (list_purchases) that supplies the product_id, so an agent can tell it apart from get_product or list_purchases without opening a schema.

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

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

Gives a clear precondition ('from list_purchases') and an auth requirement ('Requires signing in'), which routes the agent to the right prerequisite tool. It does not state exclusions or alternatives (e.g., when to use get_product instead), 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?

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), so the description's added value is in revealing payload composition — notably that install requirements come from a static check of the download rather than a live install, which hints at reliability limits. It doesn't cover behavior on unknown slugs, but that is minor.

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 identifies the resource and scope before the long field list. The nested parenthetical at the end is dense but still parseable; 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?

With no output schema, the description carries the burden of describing returns and does so field by field, including the less obvious install-requirements section. Only error/empty-result behavior is left unstated, which is a small gap for a simple read 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 coverage is only 50%: the required 'slug' has no schema description, and the description compensates by defining it as a product slug sourced from search_products. The 'locale' parameter is already fully documented by the schema enum, so the description correctly does not repeat 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 and resource ('Details of one RPScripts product by slug') and enumerates exactly what the payload contains (description, frameworks, version, categories, price, purchasability, install requirements). It also distinguishes itself from the sibling search_products by naming it as the source of the slug.

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 parenthetical '(from search_products)' establishes the intended workflow: search first, then fetch details by slug. There is no explicit exclusion (e.g. 'do not use for browsing or keyword search'), but the single-product scope makes the alternative 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?

With annotations already declaring readOnlyHint=false, idempotentHint=true and destructiveHint=false, the description goes well beyond them: asynchronous queueing, the RPScripts agent performing the download/check/unpack, the target path resources/[rpscripts]/<name>/, backup creation, owner confirmation before replacing an existing folder, refusal of server packs and non-ZIP files, and the fact it consumes a download quota. This is exactly the extra context annotations cannot carry.

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 core action is front-loaded, and every clause carries information (provenance, defaults, side effects, refusals, next step) with no filler. It is dense, though the long parenthetical about list_purchases and list_servers makes the opening sentence a little heavy.

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

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

For a three-parameter mutation tool with no output schema, the definition covers inputs, async lifecycle, filesystem target, replacement confirmation flow, failure modes (server packs, non-ZIP), and how to verify the outcome. An agent has everything needed to invoke it and interpret the result.

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

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

Schema description coverage is 0%, so the schema documents only types, UUID patterns and the 0-999 range for file_index. The description compensates by explaining that product_id identifies an owned product, that file_index selects one file of that product, and that server_id identifies a connected server and is optional when exactly one exists. It does not spell out what happens when file_index exceeds the product's file count, leaving the upper bound of 999 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 opens with a precise verb+resource+scope: 'Queues one file of a product the signed-in customer owns ... for installation on one of their connected FiveM servers.' It distinguishes itself from adjacent siblings (get_download_url, list_purchases, install-adjacent validation tools) by naming the file-level, server-targeted unit of work and where the identifiers come from.

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

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

It states the provenance of both key inputs (product_id/file_index from list_purchases, server_id from list_servers) and the exact condition under which server_id may be omitted. It also prescribes the follow-up ('Follow the result with list_servers'). It stops short of naming a concrete alternative operation (e.g. download-only via get_download_url) for users who do not want installation.

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 closed-world, so the safety profile is fully covered. The description's only added behavioral content is that entries include paths and URLs — a useful return-content hint given there is no output schema — but it says nothing about result size, ordering, or whether the list is complete vs paginated.

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 compact sentence with no filler that front-loads the resource and its scope before the return detail. It is arguably over-terse, leaving the list/browse nature implicit rather than stating it.

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 listing tool with full annotation coverage, this is nearly sufficient — it tells the agent what categories exist and that paths/URLs come back, compensating for the absent output schema. It still omits the obvious follow-on framing (use these paths with get_download_url) and any note that results are localized, which is the only thing the single parameter controls.

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?

One optional parameter with 100% schema description coverage (locale enum en/de/fr/pt/es), so the schema fully explains it. The description adds no information about how locale affects category names, descriptions and URLs beyond what the schema already states — baseline 3 applies.

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

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

The description names the exact resource set (all RPScripts shop categories) and enumerates its scope — framework/job scripts, MLOs, vehicles, clothing, server packs — plus what each entry carries (paths and URLs). It implicitly marks this as a catalogue/browse operation, distinguishable from get_product and search_products, though it never uses an explicit verb like 'list' or '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?

No guidance on when to call this versus search_products, get_product, or get_download_url, and no mention that it takes no required arguments and is safe to call as a discovery step. The agent must infer the browse-then-fetch workflow entirely from sibling names.

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, so the description's added value is the auth requirement, the bundle-item inclusion rule, and the note that file indexes feed into get_download_url. It does not say how paging behaves or whether a total count is returned, which is the remaining behavioral 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?

A single dense sentence that front-loads the verb, owner scope, and returned data, with the auth prerequisite last. Every clause carries information; no filler.

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

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

With no output schema, the description carries the return-shape burden well by listing product id, name, product page, files with index, download availability and install requirements. The missing piece is pagination semantics for the two undocumented paging parameters.

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

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

Schema coverage is only 33% — only locale is documented — yet the description says nothing about page or limit, including that they are bounded (max 100/50) and default to 1/25. With below-half coverage the description needed to compensate for the undocumented pagination parameters 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 definition gives an explicit verb plus resource ('Lists the RPScripts products the signed-in customer owns') and scopes it to active purchases including bundle items, which separates it from catalog-browsing siblings like search_products and list_categories. It even enumerates the returned fields, so an agent knows exactly what it gets.

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 scope statement ('the signed-in customer owns') plus the prerequisite 'Requires signing in to RPScripts' gives a clear condition for use. It stops short of explicitly naming alternatives (e.g. use search_products to browse the full catalog) or stating exclusions, so it is not 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?

Beyond the annotations, the description discloses the returned data: online state, newest install per product, install status values, folder, and remaining setup such as dependencies, SQL, and config. It also explains that planned means waiting for the owner's confirmation, which is meaningful behavioral context not captured by the read-only 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 front-loaded with the core action and result scope, followed by the practical use case. It is dense and includes a long status list, but the details are relevant rather than filler.

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

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

There is no output schema, so the description carries the burden of explaining return values, and it does so by naming online state, per-product newest install, status values, folder, and remaining setup. For a zero-parameter, read-only listing tool, this is complete enough for an agent to call and interpret 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?

The tool has zero parameters, so there is no parameter semantics to clarify beyond the empty input schema. The baseline for a parameterless tool is 4, and the description does not create ambiguity about inputs.

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

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

The description states a specific verb and resource: it lists the FiveM servers connected to the signed-in customer under My account. It also scopes the result to online state and the newest install of each product per server, which makes the tool's purpose concrete and distinguishable from a generic server lookup.

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 explicitly says to use the tool to pick a server_id for install_on_server and to follow an install, giving clear usage context. It does not state when not to use it or compare it directly with lookup_server, so it stops short of full sibling routing 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 establish read-only, open-world, idempotent, non-destructive behavior. The description adds important behavioral context beyond annotations: private/local refusal, unreachable handling, omission of player names/identifiers, and the six-item cap for shop_products.

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 front-loaded with what is looked up and how, then adds return fields and edge cases in compact sentences. Every clause carries useful information without 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?

There is no output schema, so the description responsibly lists the returned fields and key caveats such as unreachable servers and excluded player data. For a single-parameter read tool, this is complete enough 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?

The schema already documents the sole parameter at 100% coverage, including its accepted format. The description restates and exemplifies the format but adds no additional syntax, validation, or edge-case meaning beyond the schema.

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

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

Uses a specific verb and resource (look up a public FiveM server) and immediately scopes it to cfx.re join codes/links or host:port. This clearly separates it from siblings such as check_compatibility or validate_server_cfg, which operate on other targets.

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?

Explains accepted inputs and explicitly notes that private/local addresses are refused and offline servers are reported unreachable, which clarifies usage boundaries. It does not explicitly name alternative siblings or say when to prefer them, so it falls short of full when/when-not routing 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 readOnly, idempotent, non-destructive and closed-world, so safety is covered; the description adds genuine value on behavior by stating the return shape ('matching sections with source URLs') and the dual-mode read behavior. It does not mention result ranking, truncation, or error behavior when a page path is invalid.

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

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

Three front-loaded sentences with no filler; the coverage list is dense but functional and the mode instruction comes last where it belongs. The parenthetical topic enumeration and the 'reads from pinned ... sources' phrasing are slightly heavy but each element 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 5-parameter search tool with no output schema, the description covers scope, source corpora, return shape (sections plus URLs), and the page mode. The main residual gaps are the limit/paging semantics and whether query is mandatory when page is absent.

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

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

With only 60% schema coverage, the description compensates well: it explains the two operating modes (query search vs. page fetch), clarifies that 'scope' spans docs versus framework API reference, and that 'framework' selects which API reference is searched. It says nothing about 'limit' behavior, leaving one parameter to the schema alone.

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

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

The description gives a specific verb+resource ('Searches RPScripts documentation') and then enumerates the covered topics (installation, downloads, server packs, updates, framework guides, troubleshooting) plus the framework API sources, which clearly separates it from siblings like search_products, get_product and check_compatibility.

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 establishes clear usage context: search documentation and framework API reference, and it explicitly tells the agent how to switch to full-page reading via 'Pass page to read one docs page in full.' It does not name alternatives or exclusion conditions (e.g., when to prefer check_compatibility or lookup_server over a docs search), so it falls short of a 5.

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

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

Annotations already declare readOnly, idempotent, non-destructive and non-open-world, so the safety profile is covered. The description adds real value beyond that: it discloses the visibility filter ('only published, listed products'), the ranking policy that couples query presence to sort order, and a fixed page size of 24.

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

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

Three sentences with zero filler: identity, filter/ranking behaviour, visibility constraint and page size. The most decision-relevant facts (what it searches, how results are ordered) are 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?

For a 10-parameter, zero-required search tool with no output schema, the definition covers filtering, ordering, visibility and pagination — enough for an agent to call it correctly. A brief note on the shape of returned results (fields per product, total count/available pages) would close the remaining gap, since no output schema exists to cover 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 coverage is 70%, and the description meaningfully reinforces the filtering semantics (framework, category, USD price) and the ranking/sort coupling, which matters because the sort enum's behaviour depends on whether query is set. It does not touch locale or buyable_only, leaving those to the schema, which is reasonable given their self-documenting 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?

States a specific verb (search) plus the exact resource domain (RPScripts catalogue of FiveM scripts, MLOs, server packs, vehicles, assets) and enumerates the filter axes. This is clearly distinguishable from get_product (single item) and list_categories (browsing), which appear as siblings.

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

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

The description establishes the retrieval context clearly — ranked by relevance when a query is supplied, by popularity otherwise — and the schema points back to list_categories for valid category paths. It stops short of explicitly saying when to prefer get_product or list_categories, but the surrounding context makes the boundary easy to infer.

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 closed-world, so the safety bar is lower; the description still adds real value by declaring 'Code is parsed, never run' and by describing the return shape (severity, rule code, file, line, fix). It doesn't mention limits such as the 200-file / 512KB caps or runtime cost, leaving a small 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 sentences, front-loaded with the verb and scope, then the full checklist of checks; the final clause 'Code is parsed, never run' is a high-value closer. No filler or repetition of the title.

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

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

For a 3-parameter, fully documented, annotation-covered read-only tool with no output schema, the description covers purpose, scope, non-execution behavior and the diagnostic return shape. Nothing an agent needs in order to call it correctly is missing.

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

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

Schema description coverage is 100%, with the files array, the framework enum and resource_name all documented, including the note that framework is auto-detected when omitted. The description adds no parameter-level meaning beyond the schema, which is the correct baseline here.

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 ('statically checks') and resource ('a FiveM resource'), then enumerates exactly what is checked: Lua syntax, fxmanifest directives, structure, dependencies, framework API versions, natives, net-event security and backdoors. That enumeration makes it trivially distinguishable from siblings like validate_server_cfg and check_compatibility.

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 use case (static analysis of a resource bundle before running it) but never says when to pick this over check_compatibility or validate_server_cfg, nor any exclusions such as size or framework limits. Usage is inferable but not spelled out.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the description doesn't need to restate safety. It does add genuinely non-obvious context: processing is in-memory with nothing stored, secret values are never echoed, and results are delivered with line numbers plus a suggested fix. It stops short of describing severity levels or how issues are ordered.

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

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

Front-loaded with the verb and target, then a dense enumeration of check categories and the return shape. Every clause is informative, though the long comma-run check list is slightly harder to scan than a short structured list would be.

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

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

A one-parameter, non-destructive tool with no output schema needs the description to cover the return shape, and it does ('returns issues with line numbers and a suggested fix'), plus data-handling guarantees. An agent has everything needed to call it correctly and interpret the result.

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

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

There is a single required parameter with 100% schema description coverage ('server.cfg text (max 256 KiB)'), so the schema carries the load. The description implies the input is config text but adds no format or framing detail beyond the schema.

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

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

States a specific verb pair (parses and checks) against a named resource (an FXServer server.cfg) and enumerates the check categories, so an agent knows exactly what class of problems it surfaces. It is clearly distinct from the sibling validate_resource, which targets resource content rather than the config file.

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: an agent can infer this belongs before deploying a config, but the description never says when to call it versus check_compatibility or validate_resource, nor any exclusions. No prerequisites or conditions for invocation are given.

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