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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds a distinct and useful guarantee of its own: the output will not expose secrets, which is real behavioral context not conveyed by any annotation.

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, front-loaded sentence with no filler; every clause (what it shows, what it does not expose) 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 zero-parameter read-only status check with no output schema, the description is nearly sufficient. It could go slightly further by naming what is reported (e.g., logged-in user, account tier, auth validity), but nothing needed to invoke the tool 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?

The tool takes zero parameters, so parameter documentation is not applicable and the baseline is 4. The description adds nothing about inputs, which is correct given there are none.

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 ('Show') and a specific resource ('Nexus authentication and account status'), which is clearly distinguishable from the sibling tools (nexus_games, nexus_mod, vortex_*), none of which deal with account/authentication state.

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: an agent would call this to check whether it is authenticated before making other Nexus calls. However, the description never states when to use it, what precedes it, or what alternatives exist, so explicit guidance is absent.

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/no-destruction and open-world scope. The description adds genuinely new context: links are temporary, they grant access, and they must not be shared. It also discloses the auth-tier requirement, which annotations do not.

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, no filler. The core action is front-loaded and the conditional requirement and security caveat follow in order of importance.

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?

No output schema exists, and the description covers the essential calling context: auth tier, required extras for free users, and the temporary/non-shareable nature of the result. It omits any indication of how many links come back or how long they last, which is a minor gap for a read-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 only 20% (only 'game' is documented), so the description must compensate. It does explain 'key' as a website NXM key and pairs it with 'expires', but says nothing about modId or fileId. Partial compensation keeps this at the baseline 3.

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

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

States a specific verb and resource: 'Get temporary download URLs'. An agent immediately knows the output class. It does not name or contrast any sibling (e.g. vortex_download_mod), so it falls short of the top tier.

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 conditional path: premium users can download directly, free users must supply the website NXM key and expires. That tells the agent which params apply under which account tier. No alternative-tool routing is offered, so 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?

Annotations already declare readOnly, idempotent, destructive=false and openWorld, so the safety profile is covered. The description adds one genuine behavioral fact — pagination is performed locally rather than server-side — which is useful, but it says nothing about filtering behavior, result size, or ordering.

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

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

Two short sentences, zero filler, with the resource and scope front-loaded before the pagination note. Nothing extraneous, though the compression leaves real gaps.

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 parameter descriptions, no output schema, and no enum hints, the definition leaves the agent guessing about query semantics, default page size, and result shape. Annotations cover mutations/safety, but the retrieval contract is under-specified.

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

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

Schema description coverage is 0% for three parameters, so the description must carry the load and largely does not. 'Paginated locally' gestures at limit/offset, but the 'query' parameter's matching semantics (what fields it searches, substring vs exact) are never explained anywhere.

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

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

States a specific verb ('Find') and resource ('Nexus game domains') with a scope qualifier ('documented legacy games catalogue'), so the agent knows this is a lookup against a fixed catalogue. It does not distinguish itself from the similarly named sibling vortex_games, which an agent could easily confuse with this one.

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

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

There is no explicit guidance on when to use this versus vortex_games or the other nexus_* catalogue tools. 'Paginated locally' hints at a retrieval pattern but never states a use case, prerequisite, or exclusion.

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

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

The annotations already declare read-only, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description still adds real value by flagging that mod descriptions are untrusted content, a prompt-injection caveat the annotations do not convey. It stops short of describing response shape or recovery from an unknown modId.

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

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

Two short sentences with the operation stated first and the trust caveat second; nothing is padded. The second sentence is arguably a warning rather than definition, but it 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 two-parameter read tool with rich annotations and no output schema, the description is adequate: it covers purpose and the untrusted-content risk. It is missing what metadata is actually returned and any error behavior for invalid game domains or mod ids.

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 50%: the 'game' domain is documented with an example, while modId is undocumented but self-evident from its name and positive-integer constraint. The description adds nothing about parameter format, which is acceptable at this coverage level but not more than baseline.

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

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

States a specific verb and resource ('Get mod metadata') and adds the access path ('legacy API/Vortex client'), which distinguishes it from the v3 siblings such as nexus_v3_mod. It does not name those siblings explicitly, so an agent must infer the legacy-vs-v3 split.

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

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

There is no when-to-use guidance or comparison against nexus_v3_mod, nexus_mod_files, or nexus_mod_feed. The phrase 'supported legacy API' is context, not a selection rule, so the agent must guess which mod-metadata tool applies.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds the useful feed-vs-search distinction, but does not disclose pagination, ordering, or return-shape behavior beyond what annotations 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?

Two short sentences, front-loaded with the action and followed by the key disambiguation. No filler or redundant restatement of the tool name.

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

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

For a simple read-only feed tool with no output schema, the description is nearly complete: it covers purpose, feed modes, and the main usage boundary. It omits minor details like default feed value and required game parameter, but those are available in the 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?

Schema coverage is only 50%: the game parameter is documented by the schema pattern/description, while the feed enum has no schema description. The description compensates by naming the three feed modes in natural language, but it does not explain the required game domain or default behavior.

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 ('Get ... mods') and enumerates the three feed scopes: trending, newly added, recently updated. It also distinguishes the tool from full-text search, helping separate it from sibling mod-search 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 sentence 'This is a feed, not full-text search' clearly frames the intended use case and excludes full-text search behavior. It does not name the competing search tool explicitly, but the usage boundary is clear for an agent.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive behavior, so the safety profile is covered structurally. The description contributes 'Paginated locally', a genuinely useful behavioral note about pagination semantics, but says nothing about result shape, rate limits, or failure modes.

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

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

A single tight sentence with the core purpose front-loaded and zero filler. Slightly terse given the tool's undocumented parameters, but structurally efficient.

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

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

There is no output schema, so the description must carry the full burden of explaining what is returned, and it does not describe the file/version record shape. Combined with low parameter coverage and no logical sibling routing, it is adequate but leaves real gaps for an agent invoking 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 only 25% — only 'game' is documented in the schema, while 'modId', 'limit', and 'offset' carry no descriptions. The description does not compensate: it never explains modId's meaning or the limit/offset pagination contract beyond the vague phrase 'paginated locally'.

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 ('List downloadable files and versions for a mod') and adds a scoping note about legacy game-scoped file IDs, which implicitly distinguishes it from the nexus_v3_files sibling. Clear and actionable, though the legacy-vs-v3 distinction is hinted rather than stated outright.

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 'legacy game-scoped file IDs' implies this is the legacy-API variant and the v3 siblings are the modern alternative, but there is no explicit when-to-use or when-not-to-use guidance. Usage is inferable from context rather than stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered. The description adds only the 'Currently experimental' caveat, which is useful stability context but no detail on pagination, response shape, or failure 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?

A single compact sentence that leads with the verb and resource and ends with the experimental caveat. Nothing is wasted, though it is terse enough that key routing and flag semantics are omitted.

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

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

For a two-parameter read-only tool with no output schema, the description covers the core purpose but leaves the `resolved` flag's exact effect and any sibling-routing guidance unstated. Adequate, but with visible gaps.

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

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

Schema coverage is 50%: fileVersionId carries a strong description, while `resolved` has only a type and default. The description partially compensates by contrasting 'raw dependency definitions' with 'resolved version-range candidates', implying what `resolved` toggles, but it never states which value yields which output.

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) and resource (API v3 raw dependency definitions / resolved version-range candidates), and the scoping key (GLOBAL file version ID). It distinguishes raw vs resolved output modes, so an agent understands the subject matter without opening the schema, though it does not explicitly differentiate itself from nearby siblings like nexus_v3_file_version.

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

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

There is no when-to-use or when-not-to-use guidance and no named alternative. The description never says which situation should drive the `resolved` flag, leaving the agent to infer its purpose from the phrase 'resolved version-range candidates'.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful context by labeling the tool 'experimental,' but says nothing about return shape, pagination, or failure modes.

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, both load-bearing: the first establishes scope and identity, the second establishes prerequisite and stability caveat. No filler, though the phrasing is telegraphic rather than fully formed.

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 single-parameter read with no output schema and full annotation coverage, the description supplies the two things an agent most needs: the correct ID namespace and the required prior call. Only return-value behavior is left unstated, which is acceptable given the low complexity.

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%, and the schema itself explains that modUid is the global identifier rather than the game-scoped website ID. The description restates the GLOBAL emphasis but adds no syntax or format detail beyond the schema, so 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?

States a specific verb (Get), resource (mod files), and scoping detail (API v3, GLOBAL mod ID), which lets an agent distinguish it from the legacy sibling nexus_mod_files. It stops short of explicitly naming that sibling, so differentiation is implicit 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?

Gives a clear sequencing prerequisite — 'use nexus_v3_mod first' — and flags the tool as experimental, which tells the agent to prefer alternatives when stability matters. It does not explicitly say when to choose nexus_v3_files over nexus_mod_files, leaving that inference to the v3/legacy naming.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint false, and openWorldHint, so the safety profile is covered. The description adds the useful note that the response contains a global file version ID, which is a behavioral/response detail not in annotations. It doesn't cover error cases or auth requirements, but with annotations present the bar is lower.

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

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

Two short sentences with no waste, front-loading the action and then the distinguishing detail about the response. Every sentence 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?

No output schema exists, so the description's mention of the global file version ID in the response is helpful. However, it's a simple read tool with annotations that cover the safety profile, and the missing fileId parameter detail leaves a minor gap. Adequate but not rich.

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 50%. The 'game' parameter is well documented in the schema (game domain example), but fileId has no schema description. The tool description mentions 'game-scoped file ID' which hints at the relationship between the two parameters, adding some value, but doesn't fully compensate for the missing fileId documentation. Baseline 3 aligns with the mixed coverage.

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

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

States a specific verb and resource ('Get an API v3 file version'), and clarifies it is keyed by the game-scoped file ID, which distinguishes it from sibling tools like nexus_v3_files. It does not explicitly name an alternative sibling, but the operation is clear.

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

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

No guidance on when to use this tool versus alternatives such as nexus_v3_files or nexus_mod_files. The description only states what it does, not when it should be selected.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and non-destructive, so safety is covered. The description adds two useful bits of context beyond the annotations: the endpoint is experimental (stability risk) and the response carries a global mod ID. It stops short of describing response shape or failure modes.

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

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

Two short sentences with the core purpose front-loaded and the experimental caveat second; nothing is padded. It is efficient, though terse enough that the second sentence does double duty as both warning and return-value hint.

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 some of the return-value burden and does so minimally by mentioning the global mod ID. For a two-parameter read tool whose annotations cover safety, this is adequate but leaves the undocumented modId parameter and the distinction from nexus_mod unresolved.

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 only 50% (game is documented with an example domain, modId is not). The description contributes nothing about parameter meaning, format, or valid ranges, so the bare modId integer is left for the agent to guess at.

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 and resource ("Get mod details") plus the API surface it targets (API v3), so the agent knows what it retrieves. It does not differentiate from the sibling nexus_mod, leaving the v3-vs-legacy choice to inference.

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

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

There is no statement of when to use this tool versus nexus_mod or nexus_v3_files, and no prerequisites. The only usage-flavored signal is the "Currently experimental" caveat, which is a warning rather than 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 readOnlyHint=false and destructiveHint=true, so the description's 'Writes mod files into the game through Vortex' is consistent and useful confirmation of exactly what is mutated. It also discloses the return shape ('Returns a job ID'), which matters because no output schema exists, but it stops short of saying what happens to previously deployed files or whether the job can be awaited/cancelled.

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, each load-bearing: what is queued, what it touches, and what comes back. The mutation and return information are front-loaded with 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?

For a single-parameter mutation tool with no output schema, the description covers purpose, the write behavior, and the return value, which is nearly everything an agent needs. The remaining gaps (parameter meaning, effects on existing deployed files) are modest but real.

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

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

Schema description coverage is 0% and the single profileId parameter is never mentioned by name or meaning in the description. The phrase 'ACTIVE Vortex profile' only vaguely gestures at profile state and does not explain whether profileId must reference the active profile or how it is validated, so the description fails to compensate for the coverage 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?

States a specific verb and resource ('Queue deployment of the ACTIVE Vortex profile') and narrows scope with 'ACTIVE', which separates it from the several sibling tools that list or manage profiles/mods. It also names the mechanism ('through Vortex'), so an agent can distinguish it from vortex_profiles or vortex_install_download 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?

The word 'ACTIVE' implies the profile must already be active, but there is no explicit when-to-use statement, no prerequisite (e.g. a deployable profile must exist), and no named alternative for related operations like vortex_install_download or vortex_job. Usage is only inferable from the scope wording.

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

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

Annotations already declare readOnlyHint=false, openWorldHint=true, and non-idempotency, so the safety profile is covered. The description adds meaningful un-annotated context: the return is a job ID, free-tier users may hit an interactive step, and no install occurs — behavior an agent can't infer from annotations alone.

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?

Four short sentences, purpose front-loaded, every sentence carrying distinct information (action, return, caveat, boundary). 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?

Behavior is reasonably covered and the job-ID return partially substitutes for a missing output schema, but two of three required parameters remain undocumented in both schema and description, and no workflow routing to the install/deploy siblings is given. Adequate but with clear gaps.

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

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

Schema coverage is only 33% (only gameId is documented in the schema), and the description adds nothing about modId or fileId. With coverage below 50%, the description was the place to compensate and it does not, leaving two required identifiers 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+resource: 'Queue a Nexus file download in Vortex'. The scope is precise, and 'Does not auto-install' implicitly separates it from the sibling vortex_install_download, so an agent can distinguish it 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 situational context ('using its signed-in session', 'Free users may need to complete a website/dialog step') and a negative ('Does not auto-install'), but never names the alternative tool (e.g. vortex_install_download) or states explicitly when to call it versus those siblings. Usage is implied rather than prescribed.

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 the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds genuine value by disclosing what the output deliberately omits (signed URLs, filesystem paths), which tells the agent these items must be fetched elsewhere.

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

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

A single tight sentence with zero filler, and the core action is front-loaded ahead of the output constraint.

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 more return-value burden; saying it lists downloads 'and their state' while omitting URLs/paths partially covers that. It does not address pagination via limit/offset or the gameId filter, leaving notable gaps for a list tool.

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

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

Schema description coverage is 0% and none of the three parameters (limit, gameId, offset) are explained or even mentioned in the description. gameId in particular is non-obvious filtering behavior that the description leaves 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 (List) and resource (Vortex downloads) plus the returned state, and implicitly differentiates itself from signed-URL siblings via the negative constraint. It does not name a sibling outright, but an agent can tell this is the read-only listing rather than the link-fetching tool.

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

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

The phrase 'without returning signed URLs' implies this is the alternative to a link-fetching tool such as nexus_download_links, but no when-to-use or when-not-to-use condition is stated explicitly. Usage is inferable rather than 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 readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds useful content context by naming the return fields (Vortex IDs and Nexus domain mappings), which the annotations do not convey, but says nothing about ordering, limits, or how 'discovered' is determined.

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

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

A single front-loaded sentence with no filler. Every clause (local scope, Vortex IDs, Nexus domain mappings) adds distinct 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 zero-parameter, read-only listing tool with no output schema, the description sketches the returned shape adequately. It is not fully complete because the agent cannot know the item structure or count, but nothing needed to invoke 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?

The tool takes zero parameters, so there is no parameter semantics to explain and the schema carries nothing to contradict. Baseline 4 applies; the description correctly implies no filtering is needed.

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

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

States a specific verb ('List') and resource ('discovered local games') and names the key payload (Vortex IDs, Nexus domain mappings). It implicitly distinguishes itself from nexus_games by the 'local' scope, though it never names that sibling explicitly.

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

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

There is no statement of when to call this versus the many sibling game/mod tools, nor any prerequisite or exclusion. The agent must infer that 'discovered local' means games already found by the local Vortex client.

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 declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false; the description adds real behavioral context beyond them: it is asynchronous ('Returns a job ID'), Vortex may surface installers/dialogs, and the installed mod is not auto-enabled. It does not state permissions or failure modes, but for a queued job tool this is a meaningful addition.

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?

Four short sentences, front-loaded with the action and scope, then return value, UI behavior, and post-condition. No filler 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?

No output schema, but the description covers the return value ('a job ID'), the precondition (finished download), the target (active profile game), and the post-condition (not auto-enabled) plus what Vortex handles. Enough for an agent to call it correctly; only parameter formats and the profileId/active-profile ambiguity remain.

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

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

Schema description coverage is 0%, so the description must carry the parameter burden. It does implicitly map downloadId to 'a finished Vortex download' and profileId to the target game profile, but gives no format, source, or constraints. It also creates mild ambiguity by saying 'ACTIVE profile' while the schema requires an explicit profileId.

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?

Specific verb+resource ('Queue installation of a finished Vortex download') with explicit scope ('into the ACTIVE profile game'), which separates it from the download-side siblings like vortex_download_mod. It does not explicitly name those siblings, so sibling differentiation is implied 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?

'Finished Vortex download' establishes the precondition that the download must already exist, and 'Does not auto-enable' signals the follow-up action. No explicit exclusion or named alternative ('use X instead') is given, 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 readOnlyHint, idempotentHint, and non-destructive behavior. The description adds meaningful behavioral context beyond annotations: jobs are in memory and disappear on Vortex restart, and an unfinished job should not be resubmitted. It does not describe return format or error behavior, but the added ephemerality warning is valuable.

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 three tight sentences. It front-loads the core purpose and follows with two relevant operational caveats. Every sentence earns its place, with no filler 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?

For a simple one-parameter getter, the description plus annotations cover the essential safety profile and the ephemeral nature of jobs. The main remaining gap is that it does not explain how an agent should obtain the jobId, but the schema defines its UUID format and the rest of the usage context is reasonably 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 input schema has 0% description coverage, and the description provides no information about the single jobId parameter—where it comes from, whether it must be the UUID from a prior operation call, or how to handle missing jobs. The parameter name is somewhat self-explanatory, but the description fails to compensate for the complete lack of schema documentation.

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 and resource: 'Get the state/result of a Vortex operation job.' That clearly distinguishes it from most siblings, which manage games, mods, downloads, and deployments. It does not explicitly name or compare against an alternative, so it falls short of the 5-level sibling differentiation.

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

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

The description implies the tool is used to check on an operation job, and adds a caution: 'Do not resubmit an unfinished job.' However, it does not explicitly state when to use this tool versus alternatives, nor does it explain how or when to obtain the jobId required for the call.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and non-destructive, so the safety profile is covered. The description adds the genuinely useful caveat that IDs are local Vortex IDs, but says nothing about pagination behavior despite limit/offset parameters.

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, correctly front-loaded with the core action, no filler. It is efficient though perhaps a touch thin given the undocumented parameters.

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

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

For a read-only list tool with no output schema, the description conveys what is returned (mods with enabled state), which is the essential part. However, pagination and the profileId format are left entirely to the schema, leaving the agent guessing about result-set size.

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 explains none of the three parameters: profileId's expected format, limit's default of 50/max 100, or offset's role. The 'local Vortex IDs' note is the only parameter-adjacent hint and it is indirect.

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 (list) and resource (installed mods in a Vortex profile) plus the returned attribute (enabled state). It contrasts implicitly with the nexus_* siblings and with vortex_profiles, but never names an alternative to sharpen the distinction.

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 name and description — retrieve mods for a given profile before acting on them — but there is no explicit when-to-use, when-not-to-use, or pointer to siblings like vortex_set_mod_enabled or vortex_profiles.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds no behavioral context beyond that – no pagination, no result ordering, no auth requirements – despite the lowered bar that annotations grant.

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

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

A single front-loaded sentence with no filler; the resource and the optional filter both appear immediately. Nothing wasteful.

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 list tool with one optional parameter and full annotation coverage, the description is minimally adequate. However, with no output schema it never indicates what a profile entry contains, and pagination/volume behavior is unstated.

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

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

Schema description coverage is 0%, so the description must compensate. It does partially by explaining that gameId acts as an optional filter keyed to a 'Vortex game ID', but it gives no format, casing, or validity guidance for the string parameter (1-200 chars in 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 (List) and resource (Vortex profiles) with an explicit scope (existing, optional game filter). It does not name any sibling, so an agent must infer it is not vortex_games/vortex_mods, but the resource is unambiguous.

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

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

The 'optionally filtered by Vortex game ID' clause implies when the filter is useful, but there is no explicit when-to-use guidance, no exclusions, and no routing to alternatives. Usage is implied rather than stated.

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

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

Annotations already declare destructiveHint=true and idempotentHint=false, but the description adds genuinely new behavior: removal spans ALL profiles for the game, the call is queued asynchronously, and it returns a job ID (useful since there is no output schema). It stops short of describing the job lifecycle or undo options.

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

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

Three short sentences, front-loaded with the action, then scope, then warning and return value. Every sentence carries distinct information with 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 annotations covering the safety profile and no output schema, the description supplies the missing behavioral facts: destructive cross-profile scope, async job queueing, and the job-ID return. Only the ambiguous profileId parameter remains under-explained.

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 50%: modId is documented (sourced from vortex_mods) while profileId has no schema description. The description adds a relevant nuance – removal applies across ALL profiles – which explains the role of profileId in this operation, but it never describes either parameter directly.

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?

Clear verb+resource ("Queue removal of a local mod") with scope stated ("Removes it from ALL profiles for its game"). This distinguishes it from siblings like vortex_set_mod_enabled and vortex_install_download, though no sibling is named explicitly.

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

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

"Inspect profiles before calling" gives a precondition, and "Destructive" signals caution. However, no alternatives are offered (e.g., disabling via vortex_set_mod_enabled instead of removing), so usage is implied rather than fully guided.

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 declare it is not read-only, not idempotent, and not destructive; the description adds the material behavior that the operation is queued asynchronously, returns a job ID, and may trigger Vortex auto-deploy. That downstream side effect is exactly the kind of context annotations cannot convey. It stops short of saying whether the change persists or needs deployment to take effect.

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

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

Two short sentences, front-loaded with the action and scope, followed by the async return and side effect. 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 usefully explains that a job ID is returned and that auto-deploy may follow. However, for a 3-parameter mutation tool with weak schema coverage, it omits permission requirements, how job completion is confirmed, and the meaning of profileId.

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 modId is documented), so the description must carry the rest but largely does not. It implies the enabled flag toggles state and references the active profile, but says nothing about profileId and even risks confusing it with the 'ACTIVE profile' phrase.

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 (enable/disable) and resource (an installed mod) with scope (ACTIVE Vortex profile), which separates it from vortex_mods (listing) and vortex_remove_mod (removal). The 'ACTIVE profile' phrasing is slightly muddled because the schema separately requires a profileId, so the scope claim is not entirely clean.

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 given, and no sibling is named as an alternative. The only routing hint ('get it from vortex_mods') lives in the schema, not 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 declare readOnlyHint, idempotentHint, destructiveHint=false and a closed-world scope, so the safety profile is fully covered. The description adds value beyond that by disclosing what is actually inspected (bridge liveness, active profile, signed-in account) and implicitly the local-bridge dependency; it stops short of describing failure behavior when the bridge is not running.

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

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

A single front-loaded sentence with no filler; the resources checked are enumerated compactly and nothing is redundant with the name.

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

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

For a zero-parameter, read-only probe with full annotation coverage, the description supplies enough for correct invocation. The only gap is that no output schema exists and the return shape (fields, error states when the bridge is down) is only sketched by the three enumerated items.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a no-parameter tool is 4. The description correctly implies the call is argument-free.

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 ('Check') and three concrete resources: the local Vortex bridge, the active profile, and the signed-in account. The purpose is unambiguous and distinct from sibling tools like vortex_profiles or nexus_account, though it does not explicitly contrast itself with them.

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

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

Usage is only implied — a status probe that an agent would naturally call before or after other Vortex operations, or to diagnose a connection. There is no statement of when to prefer it, no mention of alternatives, and no preconditions or exclusions.

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