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

Annotations already declare readOnlyHint=true, covering the safety profile. The description adds that it 'Returns full user objects,' which is useful output context absent from annotations, but it does not disclose authentication needs, error behavior when multiple identifiers are supplied, or whether all identifiers are mutually exclusive. This is decent but not rich.

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

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

Two tightly written sentences that front-load the core purpose and the key behavioral note (returns full user objects) before the usage hint. No filler; every clause 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?

The description conveys the core idea and that full user objects are returned, which helps since there is no output schema. However, for a 6-parameter optional lookup, it omits critical constraints such as requiring at least one identifier and what happens if multiple identifiers are provided or none match, leaving gaps that could lead to incorrect invocations.

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

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

The description simply lists the same parameter names that appear in the schema (id, username, shortUuid, telegramId, email, tag) without adding meaning such as expected formats, pseudonym handling, or whether identifiers can be combined. With schema description coverage at 67%, the description does not compensate for the two undocumented parameters (tag and shortUuid).

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 clear verb (Find) and resource (users) and enumerates all supported identifier types, making it obvious that it is a unified lookup rather than a single-field getter. The phrase 'instead of guessing which endpoint to call' hints at sibling tools but does not explicitly name them, so full sibling differentiation is missing.

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 says 'Use this instead of guessing which endpoint to call,' which implies it should be used when the correct specific endpoint is unknown. However, it does not specify when to prefer the specific single-field getters (e.g., get_user_by_id) or any exclusions, leaving usage largely implied.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description usefully adds that 30 keypairs are produced per call (implying a non-deterministic, regenerating output), but says nothing about whether keys are persisted, what format they take, or whether the call is expensive. With annotations carrying the safety burden, this is an adequate but thin contribution.

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 lines, front-loaded with the action and the output count. There is no filler, though the bracketed HTTP verb/path is redundant metadata rather than information the agent needs to choose or call the tool.

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 zero parameters and no output schema, the description carries the burden of describing the response, and it only discloses the count ('30 keypairs') without indicating the shape (e.g. public/private fields). For a trivial, stateless utility this is minimally sufficient, but a return-shape hint would close the remaining gap.

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 meaning to convey; per the rubric this baseline is 4. The description adds nothing parameter-related, which is acceptable.

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

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

The description gives a specific verb and resource ('Generate ... X25519 keypairs') plus the returned quantity ('30'), so the agent knows exactly what the call yields. No sibling tool deals with cryptographic key generation, so no differentiation statement is needed; it is only docked for being a bare name-plus-route rather than a full purpose sentence.

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, no prerequisites, and no mention of alternatives. The '[READ] GET /api/system/tools/x25519/generate' line is an endpoint marker, not usage guidance, and none of the sibling tools are referenced or excluded.

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

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

The annotations already establish read-only safety, but the description adds substantial behavioral detail: it waits for the result, drops the base64 SVG image and returns only the raw report, consumes node traffic, and caches/reuses results within a cooldown period for repeated calls. These are non-obvious operational traits an agent should know before calling.

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, each front-loaded with a distinct piece of information: purpose, output behavior, and caching/traffic behavior. There is no filler and 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?

For a diagnostic read-only tool with no output schema, the description adequately explains the return value (raw report with country and blocks; SVG discarded) and the notable cooldown caching behavior. It gives an agent enough context to call the tool correctly without needing to inspect structured fields.

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

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

Schema description coverage is 100%, so all four parameters are already documented in the input schema. The description refers to checking 'a node' but adds no syntax, format, or constraint details beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

The description names a specific action (Run GeoCheck) on a specific resource (a node) and explains the output semantics (how services see the node IP: country, blocks). It is unambiguous and cannot be mistaken for any sibling tool in the list, none of which perform a GeoCheck diagnostic.

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 purpose statement: this tool is for checking how a node's IP is seen externally. However, it does not explicitly say when to prefer this tool over alternatives or when not to use it, nor does it mention prerequisites beyond the cooldown behavior.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered by structured data. The description adds only the REST endpoint path (GET /api/config-profiles/inbounds); it says nothing about pagination, ordering, or size of the returned collection for an unbounded 'all profiles' read.

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 lines, purpose front-loaded and the endpoint reference supplementary. Nothing is wasted, though the bracket-tagged endpoint line is a formatting convention rather than added meaning.

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

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

For a no-parameter, read-only, no-output-schema tool the description covers what the agent needs to select and invoke it. It is not quite complete on scale/ordering of the returned set, but that gap is minor given the tool's simplicity.

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

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

The tool takes zero parameters, so the baseline is 4; the schema (additionalProperties: false, empty properties) fully documents that no inputs exist. Nothing further is needed from the description.

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

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

States a specific verb and resource ('Get all inbounds') plus the scope ('from all config profiles'), which lets an agent distinguish it from the sibling get_inbounds_by_profile_uuid without opening either schema. It does not name that sibling explicitly, so it falls short of a 5.

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

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

The phrase 'from all config profiles' implies the selection condition — use this when you want every profile's inbounds rather than one profile's — but the description never states when to prefer it over get_inbounds_by_profile_uuid or any exclusions. Usage is inferable, not 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=true/destructiveHint=false, and the description is consistent with them while adding genuinely useful context beyond them: the admin-JWT-only auth requirement and the grouped-by-resource shape of the payload. It does not, however, describe pagination or output structure in detail.

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?

Compact and front-loaded, with the auth constraint and HTTP route kept short. Minor redundancy in restating the tool name ('Get available API token scopes' → 'Returns the catalog of scopes...'), but every line is useful.

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 compensates reasonably by saying what the return value is (a scope catalog grouped by resource) and who may call it. Complete enough for a zero-parameter read tool, though it could say more about the returned fields.

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

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

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate beyond confirming that no input 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+resource ('Get available API token scopes') and clarifies what the result contains: a catalog of grantable scopes grouped by resource. It is clearly distinct from the many sibling get_* tools, though it never explicitly contrasts with any of 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?

Provides a real constraint — the endpoint is 'Forbidden via API-key, admin JWT only' — which tells the agent when the call will fail, but gives no positive guidance on when to reach for this tool versus alternatives.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description's '[READ]' tag merely repeats that. It discloses nothing extra: no return format, no rate limits, no scoping, no indication of what the bandwidth figures cover.

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?

Extremely terse and front-loaded: the name and endpoint are given with zero padding. It is efficient, though verging on under-specification rather than true conciseness.

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 tool there is no output schema and no return-value context, the tz parameter is unexplained, and no differentiation from the ~80 sibling get_* tools is offered. An agent cannot confidently decide when this is the right call.

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

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

There is one optional parameter (tz) with 0% schema description coverage, and the description never mentions it. The agent receives no explanation of what the timezone parameter does or what format it expects, 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 clear verb and resource ('Get Bandwidth Stats') and adds the concrete endpoint GET /api/system/stats/bandwidth, so the agent knows it retrieves bandwidth data. However, it never distinguishes this from near-identical siblings such as get_stats, get_http_stats, get_status, or get_stats_digest, leaving the agent to guess which stats tool fits its need.

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

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

No when-to-use guidance, no prerequisites, and no mention of alternatives among the many sibling stats tools. The agent gets the what but no criteria for choosing this over get_stats or get_http_stats.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description's '[READ]' tag merely restates that. It does add the underlying REST endpoint (GET /api/config-profiles/:uuid/computed-config), which is mildly useful transport context, but says nothing about whether the profile is materialized, cached, or expensive to compute.

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?

Extremely short and front-loaded, with the resource named in the first clause. The second line is largely redundant with the name and annotations, costing a little value but not much space.

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 tool with no output schema, the description is minimally viable: it names the resource and the route. It omits any explanation of the computed profile concept or how the return differs from the sibling endpoint, which is the main gap an agent would need filled.

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 only echoes 'by uuid' with no additional detail about what the uuid identifies (config profile, not user/node/profile-of-subscription). The schema's format/pattern constrain the value but add no domain semantics.

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 (computed config profile) keyed by uuid, which distinguishes it reasonably well from the sibling get_config_profile_by_uuid by the 'computed' qualifier. However, it never explains what 'computed' means or how the returned profile differs from the plain config profile, leaving the differentiation implicit.

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

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

There is no guidance on when to use this tool versus the closely named sibling get_config_profile_by_uuid or any other profile endpoint. The only context given is the HTTP route, which does not help an agent decide between alternatives.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description reinforces this with '[READ]' and the HTTP verb/path, adding light context but no behavioral detail such as error behavior on unknown UUIDs or whether the profile is resolvable vs. computed.

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 lines with zero waste, and the read/endpoint annotation sits compactly after the purpose. It is front-loaded and easy to scan, though the minimal content limits how much the structure can accomplish.

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 could have said what a config profile contains or how it differs from the computed variant; it does not. For a simple single-parameter getter whose annotations carry the safety profile, this is adequate but leaves a real ambiguity 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 0% and there is one parameter, but the schema itself gives full typing (uuid format with a strict pattern), and the parameter name plus the phrase 'by uuid' is self-explanatory. The description adds no meaning beyond the schema, so a baseline 3 is appropriate.

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 ('Get') and resource ('config profile by uuid'), matching the tool name exactly. However, it does not distinguish this from the closely named sibling 'get_computed_config_profile_by_uuid', leaving the agent to infer the difference between a raw profile and a computed 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 guidance on when to use this tool versus alternatives such as 'get_config_profiles' (list) or 'get_computed_config_profile_by_uuid'. The agent must infer that this single-UUID fetch is appropriate when a specific profile identifier is already known.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the '[READ]' tag is pure duplication rather than added transparency. The description discloses no pagination behavior, filtering, default limits, or return shape for what is evidently a collection endpoint.

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?

Very short and front-loaded, with the operation named first and the endpoint last. The '[READ]' token is redundant with annotations, but the definition is not bloated.

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 zero parameters and no output schema, the description is minimally adequate, but it never explains what a 'config profile' is, whether the result is paginated, or what fields come back. For a list endpoint among many similar siblings, a bit more scoping would materially help selection.

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 burden on the description and the baseline is 4. Nothing in the description misrepresents or contradicts the empty 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 clear verb+resource ('Get config profiles') and the underlying endpoint, but gives no differentiation from closely related siblings such as get_config_profile_by_uuid, get_computed_config_profile_by_uuid, and get_subpage_configs. An agent cannot tell from the description alone whether this returns a collection or a single profile scope.

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

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

There is no when-to-use guidance, no mention of alternatives, and no condition that selects this tool over the several sibling profile-retrieval tools. The endpoint string implies a list operation but nothing is made explicit.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the endpoint annotation ('[READ] GET /api/system/configuration') and the useful caveat that only 'some' configuration values are returned, but says nothing about which values, size, or sensitivity of the payload.

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 lines, front-loaded with the operation and endpoint. The first line is essentially a restatement of the tool name and the endpoint line largely duplicates the annotation hint, so it is efficient but slightly redundant.

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 no-parameter read tool with annotations covering safety, the description is close to sufficient, but 'some of the configuration values' leaves ambiguity about scope and overlap with get_remnawave_settings/get_metadata. Without an output schema, a bit more detail on what is returned would help.

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 clarify; the baseline of 4 applies. The schema itself is fully described with additionalProperties: false.

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 Remnawave Configuration') and pins down the underlying endpoint GET /api/system/configuration. It does not distinguish itself from the very similar sibling get_remnawave_settings, which an agent could easily confuse with this 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?

There is no guidance on when to call this versus the many sibling getters (get_remnawave_settings, get_metadata, get_stats, etc.), and no prerequisites or context are given. The agent must infer usage entirely from the name.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description's '[READ]' tag and endpoint path restate that safety profile and add the HTTP verb/path, but nothing about error behavior (e.g. unknown UUID) or return characteristics.

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 lines, zero filler, resource stated first. It is arguably under-sized for a tool definition, but no sentence 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?

For a simple single-parameter read with full schema coverage and no output schema, the definition is minimally sufficient. It does not address failure modes or indicate what the returned squad object contains, leaving a modest gap.

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 single uuid parameter is fully documented in the schema with format and pattern. The description adds no syntax or semantic detail beyond what the schema already provides, 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 and resource ('Get external squad by uuid') plus the REST mapping, so the agent knows this retrieves a single squad. It is distinguishable from the list sibling get_external_squads only by the 'by_uuid' phrasing rather than an explicit contrast, so it falls just short of a 5.

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

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

Usage is only implied: the name and UUID parameter make clear it is for fetching one squad by identifier. There is no explicit statement of when to prefer this over get_external_squads or what happens if the UUID is unknown.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered; the '[READ] GET /api/external-squads/' line merely restates that. Nothing is said about pagination, result size, or filtering behavior on a list endpoint, which is the kind of extra context that would raise this score.

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 line, front-loaded with the purpose, followed by a compact HTTP hint. It is not padded, though the method/route fragment adds little beyond the annotations.

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-param read tool with annotations and no output schema, the description is minimally sufficient to call it, but it says nothing about what the list contains or its size. 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool applies. No parameter semantics are missing.

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 all') and resource ('external squads'), and the plural form distinguishes it from the sibling get_external_squad_by_uuid. No further scope detail is given, but the intent 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?

There is no when-to-use guidance, no statement of when-not to use it, and no pointer to the singular sibling for single-record lookups. The agent must infer that this is the unfiltered list endpoint.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the HTTP verb and endpoint path ('GET /api/hosts/:uuid'), which confirms the read nature but discloses nothing about lookup behavior such as what happens on a missing UUID.

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 lines, front-loaded with purpose and zero filler. The endpoint line is arguably redundant with the annotations but no more than one line 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?

A simple single-parameter read tool with no output schema and annotations covering safety, so the burden is light. Still, the description never says what a 'host' is or what an absent/not-found UUID yields, which an agent would benefit from knowing.

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

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

Schema description coverage is 0%, but the single uuid parameter is heavily constrained in the schema itself (uuid format plus regex pattern). The description's 'by UUID' only maps the parameter to the purpose and adds no format or sourcing 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 and resource ('Get a host by UUID'), which distinguishes it from the list sibling get_hosts by implying single-item lookup. However, it does not explicitly name get_hosts as the alternative, so an agent must infer the singular/plural 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?

No when-to-use guidance, no prerequisites, and no mention of alternatives. The only hint is the implicit 'by UUID' lookup semantics, leaving the agent to infer that get_hosts is the plural counterpart.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds only the concrete HTTP method/path (a read of the hosts collection), but says nothing about pagination, filtering, or the shape/size of results. With annotations carrying the burden, this is an adequate but thin 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?

Two short lines, zero padding, purpose front-loaded. It is not bloated, but it is also nearly as terse as a bare identifier, so it earns efficiency points without adding explanatory substance.

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 no-param, read-only listing endpoint with no output schema, the definition is minimally viable: an agent knows it returns hosts, but not whether the list is paginated, filtered, or complete, nor what a 'host' contains. Acceptable, 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?

The tool takes zero parameters, so there is nothing for the description to compensate for. Baseline for a no-parameter tool applies; no parameter meaning is missing because none exist.

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 (get hosts) and reinforces it with the actual endpoint GET /api/hosts/, so an agent can tell this is a collection-listing read. It does not differentiate from nearby siblings such as get_hosts_tags or the node/host stat tools, so it stops short of a 5.

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

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

There is no when-to-use statement, no mention of prerequisites, and no reference to any alternative tool for host-related data. The agent is left to infer usage entirely from the name and the sibling 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 already declare readOnlyHint=true and destructiveHint=false, and the description adds only '[READ] GET /api/hosts/tags', which repeats the read-only nature without adding new behavioral context such as return format, pagination, or auth requirements.

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 and very short. The second line duplicates the read-only annotation and includes an endpoint path that is not essential for tool invocation, but it is compact overall.

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 no-argument read endpoint with annotations covering safety and no output schema, the description adequately states what the tool does. It could add a brief note on the return content, but it is sufficient for correct selection.

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

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

The tool has zero parameters, so the baseline for parameter semantics is 4. The description correctly does not introduce any parameter-related confusion.

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 tags of hosts' clearly identifies the operation. It does not explicitly differentiate from siblings like get_hosts or get_nodes_tags, but the resource 'hosts' and object 'tags' are 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?

There is no guidance on when to use this tool versus alternatives such as get_hosts, get_nodes_tags, or get_users_tags. The description only implies the basic purpose, with no context or exclusions.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the '[READ]' tag in the description merely restates structured data and earns no credit. Beyond the endpoint path, the description discloses nothing further — no return shape, freshness, or scope of the HTTP stats.

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 lines, front-loaded with the resource and backed by the endpoint identifier — no filler or redundancy. The trade-off is that it is terse to the point of being under-informative rather than 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 zero-parameter read tool with no output schema, the minimum needed to call it correctly is present (it is safe and takes no args). It is still incomplete because it never says what 'HTTP stats' contains or how it differs from the other stats tools an agent could pick.

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 by the rubric baseline is 4. There is nothing for the description to clarify beyond the empty schema, and it introduces no misleading parameter expectations.

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 verb plus resource ('Get HTTP Stats') and adds the backing endpoint (GET /api/system/stats/http), so the resource is identifiable. However, it makes no attempt to distinguish this from the many sibling stats tools (get_stats, get_bandwidth_stats, get_stats_digest, get_nodes_statistics), leaving scope ambiguous.

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

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

There is no guidance on when to use this tool rather than get_stats, get_bandwidth_stats, or the other stats endpoints. No prerequisites, exclusions, or alternatives are mentioned, so the agent must infer usage purely from the resource name.

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 readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds genuinely useful non-obvious behavior: filters rely on expensive LIKE operators and misuse can degrade database performance, which is not derivable from the schema or annotations.

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

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

Brief and front-loaded: the purpose line comes first, followed by a single targeted warning. No padding or repetition, though the first line is essentially a restatement of the tool name rather than added information.

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

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

With 6 parameters, nested filter/sort structures, 33% schema coverage, and no output schema, the description should explain how to construct filters and sorting. Instead it only warns about performance, leaving the agent without enough information to invoke the tool correctly with filters.

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 33% across 6 parameters, including nested 'filters' and 'sorting' objects whose item fields are undocumented. The description acknowledges that filters exist but adds no detail on valid filter ids, values, sorting syntax, or filter modes, so it fails to compensate for the schema 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 clear verb+resource ('Get HWID devices') and includes the underlying endpoint, so the operation is identifiable. However, it gives no differentiation from close siblings like get_user_hwid_devices, get_hwid_devices_stats, or get_top_users_by_hwid_devices, leaving ambiguity about which HWID-device view this returns.

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

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

The description warns that filters are primarily for frontend use and can be expensive, which implies a usage constraint. But it never says when to choose this tool over get_user_hwid_devices or the stats variants, and no prerequisites or exclusions are stated.

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

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

The annotations already declare readOnlyHint=true and destructiveHint=false, and the description's '[READ]' marker only restates that. It adds nothing beyond the structured data: no scope (global vs per-user), no time window, no aggregation semantics, no indication of whether the result is paginated or expensive to compute.

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?

Very short and front-loaded, with the purpose in the first clause. The second line ('[READ] GET /api/hwid/devices/stats') is largely redundant with the annotations, but it costs little and the overall entry is not padded.

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 endpoint with no output schema, the description carries the full burden of explaining what comes back, and it says nothing about the shape or contents of the stats. It is minimal but not misleading, so it clears the viability bar without being complete.

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

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

The tool takes zero parameters, so the schema-description baseline of 4 applies. There is no parameter semantics to clarify and the description does not need to compensate for any 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?

It states a concrete verb+resource ('Get HWID devices stats'), which separates it from the sibling get_hwid_devices that lists devices. However, 'stats' is undefined and the sibling set contains many near-identical stats endpoints (get_stats, get_stats_digest, get_nodes_statistics, get_bandwidth_stats), so an agent cannot tell what this particular stats call returns or how it differs from 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?

No when-to-use guidance, no prerequisites, and no mention of the obvious alternatives (get_hwid_devices for the raw list, get_top_users_by_hwid_devices for per-user breakdowns, get_user_hwid_devices for a single user). The agent is left to infer selection from the name alone.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds '[READ]' and 'GET /api/config-profiles/:uuid/inbounds', but does not disclose auth requirements, rate limits, or other operational behavior beyond the annotations.

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

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

The description is extremely compact and front-loaded, with no filler. The endpoint line is brief and supports the main purpose without bloating the definition.

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 getter with one documented parameter and no output schema, the description is mostly complete. It does not explain pagination or return shape, but those omissions are minor for this tool's 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 single parameter is already documented as the config profile UUID. The description repeats the 'profile uuid' concept but adds no syntax or format detail beyond what the schema provides, so baseline 3 is appropriate.

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 inbounds') scoped by profile UUID, and adds the HTTP endpoint for additional precision. It is clearly distinguishable from sibling tools like get_all_inbounds because it is limited to a single config profile.

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

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

The description gives no explicit when-to-use guidance and does not name or contrast alternatives such as get_all_inbounds or get_config_profile_by_uuid. The required UUID implies context, but there is no routing guidance for the 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 readOnlyHint=true and destructiveHint=false, and the '[READ]' tag simply restates that. The description adds no pagination behavior, response shape, scoping, or auth context beyond the bare endpoint path.

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?

Extremely terse and front-loaded with no wasted sentences. It is not under-specified to the point of being a single word, but the brevity is achieved by omitting content rather than by tight editing.

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 and no parameters, the description carries the whole burden of explaining what this read returns, and it says nothing. Among 80+ get_* siblings, an agent cannot tell what a 'billing node' is or when this result is useful.

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

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

The tool takes zero parameters, so the schema is trivially complete at 100% coverage and there is nothing for the description to explain. Baseline 4 applies for a no-parameter tool.

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

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

The description states a verb and resource ('Get infra billing nodes') and includes the HTTP endpoint, so the basic operation is identifiable. However, 'infra billing nodes' is never disambiguated against siblings like get_infra_billing_records, get_nodes, or get_infra_providers, leaving the agent to guess what this resource actually contains.

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, no prerequisites, and no mention of alternatives among the ~80 sibling tools. The agent gets no signal for choosing this over get_nodes or get_infra_billing_records.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds the HTTP route ([READ] GET /api/infra-billing/history), which is mildly useful context but not substantive behavioral detail such as pagination caps 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?

It is short and front-loaded, which is good, but the '[READ] GET /api/infra-billing/history' line is largely redundant with the readOnly annotation and restates the tool name rather than adding agent-relevant 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 parameterless-required, read-only list endpoint with full schema coverage, the description is minimally adequate. With no output schema, it could have described the shape or ordering of returned records, but does not.

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%, so both 'size' and 'start' are fully documented in the schema itself. The description adds no syntax or format detail beyond what the schema provides, so the 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?

Names a specific verb ('Get') and resource ('infra billing history'), which is clear. It does not, however, differentiate itself from sibling infra-billing tools like get_infra_billing_nodes or get_infra_providers, so an agent must infer scope from the name alone.

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

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

There is no when-to-use guidance, no exclusions, and no mention of sibling alternatives. The agent gets the resource name but no condition telling it when this is the right call versus another billing tool.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description's '[READ]' simply restates that. It adds the HTTP endpoint, which is routing metadata rather than behavioral context, and says nothing about not-found behavior or what the response contains.

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 lines with the purpose front-loaded and no filler. Efficient, though the bracketed route line adds little value for an agent.

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 trivial single-parameter lookup with no output schema, this is close to adequate, but the absence of any error/not-found semantics or guidance relative to the sibling list tool leaves a small but real gap.

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 should compensate. It only says 'by uuid', adding no format, validation, or lookup semantics beyond the parameter name and the schema's own uuid pattern.

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 (infra provider) scoped to a single uuid lookup. The singular form plausibly distinguishes it from the sibling list tool get_infra_providers, though the description 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?

No guidance on when to use this tool versus get_infra_providers or the other infra-billing tools (get_infra_billing_nodes, get_infra_billing_records). The agent must infer that 'by uuid' means a single-record fetch.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the '[READ]' tag merely repeats that. The description adds the underlying endpoint path (GET /api/infra-billing/providers), which is useful for traceability, but it says nothing about scope, pagination, or result size.

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 plus the endpoint reference; there is no filler and the purpose is immediately clear. Appropriately sized for a zero-argument read.

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 does not indicate what an 'infra provider' record contains or whether the list is paginated. For a simple list endpoint this is adequate but not complete, and it could do more given the absence of a return schema.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline of 4 applies for a parameterless tool with an empty, well-formed schema.

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

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

States a specific verb and resource ('Get all infra providers'), which is unambiguous. It does not explicitly differentiate itself from the closely-named sibling 'get_infra_provider' (singular), leaving the plural/singular distinction for the agent to infer from naming alone.

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

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

No guidance on when to use this versus the sibling 'get_infra_provider' or the related 'get_infra_billing_nodes'/'get_infra_billing_records'. Usage is only implied by the name, so this is a plain no-guidance case.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the underlying endpoint (GET /api/internal-squads/:uuid), but says nothing about return shape, 404/error behavior, or auth requirements, so it adds only modest context.

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 lines, front-loaded with the action and resource; no filler. The endpoint tag is compact and useful rather than padding.

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 whose annotations already cover safety, this is nearly adequate, but with no output schema it omits what a squad object contains and what happens when the uuid is unknown, leaving an agent to discover the return contract by calling 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?

There is 1 parameter at 0% schema description coverage; the schema does enforce uuid format and a strict pattern, so typing is handled structurally. The description only restates 'by uuid' and adds no meaning about which squad identifier is expected or where it comes from.

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 (internal squad) with the identifier qualifier 'by uuid'. It contrasts implicitly with siblings like get_internal_squads (list) and get_external_squad_by_uuid (external variant), though it never names them 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?

Only 'by uuid' implies when this applies; there is no statement of when to use this versus get_internal_squads or get_external_squad_by_uuid, and no prerequisites or exclusions are given.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description's '[READ]' tag merely duplicates that. It adds no behavioral context beyond the annotations: no note on what 'accessible nodes' means, whether results are paginated, or what permissions are required to read another squad's node 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?

Two short lines with zero preamble, so it is front-loaded and compact. The '[READ]' tag is redundant with the annotations, and the brevity reflects under-specification rather than disciplined concision.

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 annotations covering the safety profile, this is minimally adequate. It still omits any indication of what the returned node list contains or how 'accessible' is determined, which is exactly the gap an agent would need filled.

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 there is one required 'uuid' parameter. The embedded path '/api/internal-squads/:uuid/accessible-nodes' does implicitly identify the uuid as an internal squad UUID, adding a small amount of meaning over the bare schema. That is better than nothing but far short of documenting the identifier's source or format.

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 ('Get internal squad accessible nodes') plus the HTTP route, so the agent knows this returns the node set reachable by an internal squad. However, it adds little beyond restating the tool name and does not distinguish it from siblings like get_internal_squad, get_internal_squad_usage, or get_user_accessible_nodes. Purpose is identifiable but not sharpened.

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, no conditions, and no pointer to alternatives such as get_user_accessible_nodes or get_internal_squad. The agent must infer the scenario entirely from the name.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description's '[READ] GET /api/internal-squads/' merely restates that same read-only fact rather than adding context. It says nothing about return shape, pagination, or result size for what could be a large list.

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

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

It is a single short line with the operation front-loaded, so there is no wasted prose. The bracketed method and raw endpoint add little for an agent but cost minimal space.

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 no-arg list tool with no output schema and safety already covered by annotations, this is minimally viable. However, it never clarifies what an 'internal squad' is or what the list contains, which matters given the many squad-related siblings.

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 explain; the baseline for a parameterless tool is 4. No parameter-related gap exists.

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 ('Get all') and resource ('internal squads'), making the operation instantly identifiable. It implicitly distinguishes itself from the singular sibling get_internal_squad, though it never names it explicitly, so it falls short of a 5.

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

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

There is no guidance on when to use this tool versus alternatives. With siblings like get_internal_squad, get_internal_squad_usage, and get_internal_squad_accessible_nodes in the list, the agent gets no signal about which to pick for a list vs. detail vs. usage query.

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 cover the safety profile (readOnlyHint=true, destructiveHint=false), and the description adds useful behavioral context beyond them: the >= minTotalBytes threshold filter, node scoping through internal squad inbounds, and a data-freshness caveat ('flushed to the database roughly every 2 minutes'). Pagination behavior is not mentioned, but the freshness note is genuinely 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?

Three sentences plus an endpoint tag, front-loaded with the tool's purpose and filtering behavior. The endpoint citation is somewhat redundant with the tool's operation but still compact and informative; no sentence 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 is responsible for conveying what returns; it does so via the threshold and node-scoping explanation. Parameters are fully documented and the freshness caveat is included, though pagination/cursor behavior could be worth a sentence for a 6-param endpoint.

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%, so the schema already documents all six parameters, including minTotalBytes, cursor, limit, and dates. The description reinforces the minTotalBytes filter and node scoping but adds no syntax or format detail beyond what the schema provides, making the baseline 3 appropriate.

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 internal squad users traffic usage for a period') and clarifies the filtering semantics (>= minTotalBytes, scoped to nodes reachable via internal squad inbounds). It is clear what the tool returns, but it never differentiates itself from very similar siblings like get_internal_squad_user_usage or get_stats_user_usage.

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

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

The description gives no explicit when-to-use or when-not-to-use guidance, and no alternative tool is named. Because get_internal_squad_user_usage is a near-identical sibling in the tool list, this omission is a meaningful gap for an agent trying to route between them.

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 read-only/no-destruction profile, so the bar is lower, and the description adds genuinely useful behavior: results are zero-filled for every day in the range, users below the threshold are filtered out, and data is flushed roughly every 2 minutes (latency/freshness). It does not disclose pagination or output shape, holding it below a 5.

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

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

Front-loaded with the core purpose, then supporting constraints. Sentences earn their place, though the reference to a nonexistent minTotalBytes parameter and the endpoint line add minor noise. Efficient overall.

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 stats tool with no output schema and an annotation-covered safety profile, the description covers return semantics (zero-filled daily series, threshold filtering) and data freshness. The dangling minTotalBytes reference is a real gap, but overall 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 75%, so start/end and squadUuid are already documented in the schema; userId is undocumented there. The description references minTotalBytes filtering and node scoping, but minTotalBytes does not appear in the schema parameters at all, leaving a semantic mismatch and confusion about where the threshold comes from. Roughly baseline value.

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

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

States a specific verb (Get) and resource (single user daily traffic usage on internal squad nodes for a period). The scope is precise enough to distinguish it from close siblings like get_internal_squad_usage (squad-scoped), get_stats_user_usage and get_stats_node_users_usage (global scoping). The agent can identify exactly what is returned.

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 clarifies that results are restricted to nodes reachable via Internal Squad inbounds and that users with total usage >= minTotalBytes are included, which implies when to use this over broader stats tools. But it never names an alternative or states when-not to use it, so usage guidance is implied rather than explicit.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered and the [READ] tag is largely redundant. The only added context is the underlying endpoint path, which hints that this is a system-level read, but nothing is said about auth requirements, caching, or what the metadata contains.

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 lines with zero filler and the purpose front-loaded; the endpoint line is compact and structured. It is efficient, though arguably so terse that the header-like phrasing borders on under-specification rather than crispness.

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-param read tool with no output schema, the description is minimally sufficient but leaves the key ambiguity unresolved: what 'metadata' actually returns and why it differs from the many other system-info siblings. No return-value detail is expected given no output schema, so this lands at the minimum-viable level.

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

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

The tool takes zero parameters, so the baseline of 4 applies. There is no parameter syntax or meaning the description could usefully add.

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?

It states the verb 'Get' and the resource loosely as 'Remnawave Information', plus the concrete endpoint [READ] GET /api/system/metadata. However, 'information' is nearly a restatement of the name 'get_metadata' and does not distinguish this tool from siblings like get_stats, get_status, or get_remnawave_health, all of which also return system-level information.

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

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

The description gives no when-to-use guidance and names no alternatives, despite a crowded sibling set (get_stats, get_status, get_remnawave_health, get_configuration) that an agent must choose between. Nothing tells the caller what condition selects this tool.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the '[READ]' tag is redundant. The genuinely useful disclosure is that the default response is a compact view while full:true returns the raw, large panel response — a real behavioral trait about payload size and shape that goes beyond the annotations.

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

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

Three short lines, front-loaded with the action and lookup key, then the endpoint and response-mode hint. The '[READ] GET /api/nodes/:uuid' line is mostly redundant with the tool name and annotations, but costs little and does not bury the useful content.

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

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

For a simple two-parameter read tool with no output schema, the description covers the key question an agent would have — what the default response looks like versus the full one. Missing are any error semantics (e.g., behavior for a nonexistent UUID) and sibling routing, but those are minor for this complexity level.

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%, and the description's 'pass full: true for the raw panel response' largely restates what the schema already says ('Return the raw panel response (large)'). The uuid parameter's format/pattern is fully specified by the schema, so the description adds little beyond the 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 node by UUID') and pins the retrieval key, which separates it from the list-oriented sibling get_nodes. It does not, however, differentiate itself from same-resource siblings like get_node_metadata, get_node_usage, or get_node_plugins, so an agent still has to infer the boundary.

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 alternative sibling is named despite a crowded set of node-related getters. The only implied context is 'you have a UUID', which comes from the schema itself rather than 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=true and destructiveHint=false, so the safety profile is covered. The description adds the '[READ]' marker and the underlying endpoint (GET /api/node-integrations/:uuid), which is mildly useful context but not behavior beyond the annotations. It does not describe what a 'node integration' contains or how errors (missing uuid) surface.

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 terse lines with the resource and key front-loaded and no filler. The endpoint line is arguably redundant with the name, but it costs little and is not padding.

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 single-record fetch with one well-constrained uuid and no output schema, the definition is minimally sufficient. It never says what a node integration is or what the response contains, which matters for an agent deciding between this and the plural 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%, but the single parameter is self-documenting: 'uuid' with format=uuid and a strict regex pattern. The description's 'by uuid' phrasing confirms the lookup key but adds no format, scope, or example 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 and resource ('Get Node Integration by uuid'), so an agent knows it fetches a single integration record. However, it does not distinguish itself from the sibling 'get_node_integrations' (plural/list) beyond the singular resource name, leaving the singular-vs-collection distinction 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 guidance on when to use this tool versus 'get_node_integrations', 'get_node', or the other node-related getters in the sibling list. The HTTP route is included but no context, prerequisites, or alternative selection criteria are given.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds only the underlying HTTP verb and path ('[READ] GET /api/node-integrations/'), which contributes little beyond the annotations, and it says nothing about pagination, filtering, or result size for a collection endpoint.

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 lines, front-loaded with the purpose. The trailing '[READ] GET /api/node-integrations/' is largely redundant with the readOnly annotation, but the description is not bloated.

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 does not indicate what a 'Node Integration' record contains or whether results are paginated. Annotations cover safety, but for a list endpoint feeding siblings like get_node_integration, a bit more on the returned collection would help.

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 parameterless tool is 4. No misleading parameter claims are made.

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 all Node Integrations'), and the phrase 'all' signals this is a collection/list operation rather than a single-resource fetch. However, it offers no differentiation from the sibling get_node_integration (singular), so an agent must infer the list-vs-item distinction from the name alone.

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

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

There is no explicit when-to-use guidance and no mention of the closely related get_node_integration sibling that selects a single integration. The agent gets no conditions or alternatives, only the implied fact that this returns a collection.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the "[READ]" tag merely restates structured data. The description adds no auth requirements, rate limits, or behavioral context, and exposes only the raw HTTP route, which is of little value to an agent.

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?

Extremely short and front-loaded with the action and resource. The appended HTTP method/path is mildly redundant with the read-only annotation but does map the tool to an endpoint.

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 one-parameter read tool with full schema coverage and read-only annotations, the definition is minimally adequate. It says nothing about what node metadata is returned or how it differs from sibling read tools, which is the main remaining gap.

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% for the single required uuid parameter, so the schema already carries the semantics. The description adds no format or meaning beyond what is structured, making the baseline 3 appropriate.

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 node metadata"), which is clearly a read of node-level metadata. However it offers no differentiation from siblings like get_node, get_metadata, or get_user_metadata, leaving the agent to infer node-vs-user-scoped metadata from the name alone.

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

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

There is no guidance on when to use this tool versus get_node, get_metadata, or get_user_metadata, and no prerequisites or exclusions are stated. The only hint is the implicit node scope.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description's only additional content is the '[READ] GET /api/node-plugins/:uuid' line, which merely restates the annotation and HTTP route rather than disclosing return shape, error behavior, or access requirements.

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 lines with the essential resource and identifier front-loaded and no wasted prose. The endpoint/verb line is somewhat redundant with the annotations but does not bloat the definition.

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 single-parameter read tool with a fully constrained schema and safety annotations already present, the definition is adequate to invoke correctly. It omits any indication of what the plugin object contains, which is a minor gap given no output schema exists.

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

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

Schema description coverage is 0%, but the single uuid parameter is heavily constrained by the schema's format=uuid and regex pattern. The description adds only 'by uuid', which is minimal; it neither expands on the identifier's origin nor compensates meaningfully for the absent prose description.

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

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

States a specific verb (Get) and resource (Node Plugin) with a scope qualifier (by uuid), which implicitly separates it from the sibling list tool get_node_plugins. However, it does not explicitly name the sibling, so the agent must infer the singular/plural 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 only implied: retrieve a single node plugin keyed by uuid. There is no explicit when-to-use statement, no exclusion ('use get_node_plugins to list all'), and no prerequisites, but the singular resource plus required uuid makes the intent reasonably clear.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description's '[READ]' tag merely restates that. Beyond the endpoint path, it adds no behavioral context such as whether the list is paginated, filtered, or scoped to a node.

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 lines with the purpose front-loaded and no wasted words. Size is proportionate to a simple zero-argument list endpoint.

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-param read with no output schema, the definition is minimally viable but omits anything about the shape or volume of the returned node-plugin list. Nothing is incorrect, but an agent gets no help anticipating results or pagination.

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 of 4 applies. The empty schema and additionalProperties=false leave no ambiguity.

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 all Node Plugins'), and the plural distinguishes it from the sibling get_node_plugin. However, it does not explain what a 'Node Plugin' is or how it relates to the node-plugin integrations siblings, so differentiation is only implied by naming.

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

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

There is no guidance on when to use this versus get_node_plugin (single) or get_node_integrations. The agent must infer usage entirely from the tool name.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe-read profile is covered. The description adds modest value by noting the default is a 'compact view' and that full:true yields a 'raw panel response (large)', giving a sense of payload size, but says nothing about pagination, filtering, or result fields.

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 lines that are front-loaded with the resource and endpoint, with no wasted prose. It is terse but everything present earns its place, though the terseness borders on under-specification.

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-required-parameter read tool with annotations and a fully documented schema, this is roughly adequate, and the compact-vs-full distinction is the key behavioral fact. Still, with no output schema and dense node-related siblings, more scope clarification would help an agent 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 100% and the single 'full' parameter already carries the description 'Return the raw panel response (large)'. The description largely restates that same semantics ('pass full: true for the raw panel response'), so it adds little beyond the schema; 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 states a verb ('Get') and resource ('nodes') plus the underlying endpoint GET /api/nodes/, so the operation is identifiable. However, it does not differentiate this tool from close siblings like get_node (singular), get_user_accessible_nodes, or get_nodes_metrics, leaving the agent to infer scope from the name alone.

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

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

There is no explicit guidance on when to use get_nodes versus get_node or the other node-related siblings. The only conditional hint ('pass full: true for the raw panel response') concerns a parameter, not tool selection, so usage guidance is essentially 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 declare readOnlyHint=true and destructiveHint=false, and the '[READ]' tag merely repeats that. Beyond the endpoint path (GET /api/system/nodes/metrics), the description discloses nothing about scope, auth, cost, or what the metrics represent.

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

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

It is short and front-loaded, but the first line duplicates the tool name and the second line only supplies verb+path. Minimal waste, but also minimal value per sentence.

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 saying what is returned, and it says nothing. For a read endpoint amid a dense cluster of node-metrics/statistics siblings, this leaves the agent unable to predict the result shape or choose 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 takes zero parameters, so per the rubric the baseline is 4; there is nothing for the description to clarify beyond what the empty schema already states.

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 is essentially the tool name restated ('Get Nodes Metrics') plus an HTTP verb/path hint. It never explains what metrics are returned or how this differs from near-identical siblings such as get_nodes_statistics, get_node_usage, or get_stats_nodes_usage, so an agent cannot disambiguate from the text alone.

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

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

There is no guidance on when to call this versus the many overlapping node/statistics tools in the sibling list. No context, no exclusions, no alternatives are given.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond that: no indication of what the statistics cover, freshness, aggregation window, or response shape. The '[READ]' tag merely repeats the 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?

Two short lines with zero padding and the resource name front-loaded. However, this brevity reflects under-specification rather than disciplined conciseness; nothing meaningful was cut because nothing meaningful was present.

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 statistics endpoint with no output schema and an undocumented parameter, the description should at minimum say what data is returned and what the parameter does. It provides neither, so an agent cannot confidently invoke or interpret it.

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

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

Schema description coverage is 0% for the single 'tz' parameter, so the description carries the full burden — but it says nothing about it. The agent cannot tell that 'tz' is a timezone affecting how statistics are bucketed.

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 is essentially the tool name restated ('Get Nodes Statistics') plus a raw HTTP route. It does not say what statistics are returned or how they differ from the many sibling stats tools (get_stats, get_nodes_metrics, get_stats_nodes_usage, get_hwid_devices_stats). Only the '/api/system/stats/nodes' path hints at system-level node stats.

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

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

No guidance on when to use this versus the numerous other stats/metrics endpoints. There is no statement of preconditions, scope, or alternatives, leaving the agent to guess from the name alone.

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

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

The annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered by structured data. The description adds nothing behavioral on top of that — no mention of whether the tags are globally defined or per-node, caching, or scope. It does not contradict the annotations, but it contributes no extra context.

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 line with no filler and the route front-loaded after the purpose. It is appropriately sized for a no-argument read endpoint, though it is arguably under-specified rather than elegant.

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 and no parameter schema, so the description carries the burden of explaining what comes back. It never states the return shape (a list of tag names? objects with counts? per-node groupings?), leaving the agent unable to predict the response for an endpoint whose result is the entire point.

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 per the rubric the baseline is 4. There is nothing about parameter semantics the description could usefully add, and it does not misdescribe the empty 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?

"Get nodes tags" essentially restates the tool name verbatim, with the only added information being the HTTP route (GET /api/nodes/tags) and a [READ] marker. It does not clarify what a "tag" is here, what set of nodes is covered, or how this differs from the many sibling tag/list endpoints (get_hosts_tags, get_users_tags, get_nodes).

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, no precondition, and no mention of alternatives. The sibling list contains near-miss options such as get_nodes, get_node, and get_hosts_tags, and the description gives the agent nothing to choose between them.

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 readOnlyHint=true already covering safety, the description adds two pieces of genuinely new context: the underlying usage data is flushed roughly every 2 minutes (so results can be stale), and the "[READ] POST" marker resolves the apparent conflict between a POST route and a read-only operation. It does not describe the shape of the returned user objects, but the annotation-relative bar is met.

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 outcome before the freshness caveat, and the endpoint/method tag is compact. Slight redundancy between sentence one and sentence two (both restate the threshold condition), which keeps it from being fully waste-free.

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 must carry return-value semantics; it names the returned entity and the applied filter but not the fields on each returned user (usage totals, uuid, etc.). Combined with no usage guidance among ~90 siblings, the definition is adequate but leaves real 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 description coverage is 100%, so start, end, body.nodesUuids and minTotalBytes are all already documented in the schema. The description only restates the minTotalBytes comparison semantics that the schema already states verbatim, adding no syntax, units or edge-case detail beyond 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?

The description states a specific verb and resource with scope: "Get users exceeding a traffic threshold on the given nodes for a period," which precisely identifies the entity returned (users) and the filter (threshold over nodes). It is clearer than the crowded sibling set of stats tools, but it never names which sibling (e.g. get_stats_node_users_usage, get_stats_nodes_usage) to prefer, so differentiation is left to inference.

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

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

There is no explicit guidance on when to use this tool versus the many adjacent stats/usage siblings (get_stats_user_usage, get_stats_node_users_usage, get_internal_squad_usage). The only usage-adjacent detail is the data-freshness caveat, which is behavioral rather than a selection rule.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds only the HTTP path, which conveys nothing behavioral beyond what the annotations state — no indication of what a "recap" contains, whether it is cached/aggregated, or whether it requires auth.

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 very short lines, front-loaded and free of padding. The endpoint line is thin on value but does not bloat the definition and is arguably the only concrete anchor provided.

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 and no explanation of what the recap returns, a 0-param read tool still needs the description to say what data comes back and how it differs from the many other stats endpoints in the sibling list. That gap leaves the agent unable to select this tool confidently.

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 parameterless tool is 4. No schema information is lost.

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?

"Get Recap" essentially restates the tool name; the only added information is the raw endpoint GET /api/system/stats/recap, which hints at a system-stats domain but does not state a specific verb+resource in agent-readable terms. It gives no signal that distinguishes it from siblings such as get_stats, get_status, or get_stats_digest.

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

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

There is no guidance on when to call this tool, what scenario it fits, or which alternative siblings (get_stats, get_stats_digest, get_http_stats, get_bandwidth_stats) it should be preferred over. The agent is left to guess entirely.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds only the HTTP verb/path (GET /api/system/health), which slightly corroborates the read-only nature but discloses nothing about auth requirements, rate limits, or what 'health' actually reports.

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

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

Two compact lines, front-loaded with the action and then the endpoint. The only waste is mild redundancy between the name and the first line.

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, no-output-schema health endpoint the definition is minimally sufficient, and annotations carry the safety profile. It still omits what the check evaluates (process liveness vs. downstream node health) and whether a non-200 result is surfaced as an error, which would meaningfully help an agent interpret the call.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. The description adds nothing about parameters, but there is nothing to add.

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 Remnawave Health') and even names the underlying endpoint (GET /api/system/health), so the agent knows exactly what it retrieves. It does not, however, distinguish itself from plausible siblings such as get_status or get_stats, leaving overlap ambiguous.

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

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

There is no guidance on when to prefer this health check over get_status, get_stats, or get_metadata, nor any stated preconditions. The agent must infer usage entirely from the name.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description only repeats the read nature with '[READ] GET /api/remnawave-settings/', adding endpoint context but no behavioral details such as authentication needs, rate limits, or what settings are affected.

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 very short and front-loaded. The '[READ]' tag is redundant with the annotations, but overall it avoids unnecessary text.

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, zero-parameter endpoint, the description is minimally adequate. It does not describe what 'Remnawave settings' include or what the response looks like, and there is no output schema to compensate.

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 no parameters, so there is no parameter semantics burden. The baseline for a zero-parameter tool is 4.

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

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

The description states a specific verb and resource: 'Get Remnawave settings'. This is clear enough to distinguish from most siblings, though it does not explicitly differentiate from adjacent settings-oriented tools such as get_subscription_settings or get_configuration.

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 tool versus alternatives. The [READ] marker and GET path imply a read operation, but no conditions or exclusions are provided.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds the underlying endpoint (GET /api/node-plugins/shared-lists/:name), which is minor, but says nothing about not-found/error behavior or response shape for a lookup-by-key tool.

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 lines, front-loaded with the purpose. The endpoint line is mildly redundant given the read annotation but is compact and harmless.

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 could usefully describe the returned shared-list object but does not. For a simple single-resource getter this is adequate-but-thin, leaving the agent to infer both error behavior and return format.

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 type constraints (pattern, length) with no meaning. The description's 'by name' does clarify that the lone parameter is the shared list's name, partially compensating, but adds no format, case-sensitivity, or resolution detail beyond that.

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 ('Get Shared List') and narrows scope with 'by name', so the agent knows this retrieves a single shared list rather than a collection. It does not, however, name or contrast with the obvious sibling get_shared_lists, so differentiation is implied rather than explicit.

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

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

No guidance on when to use this versus get_shared_lists (the plural collection tool) or what happens if the name does not exist. The 'by name' phrasing hints at single-item retrieval but no condition or alternative is 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=true and destructiveHint=false, so the safety profile is covered. The description adds real value beyond that by disclosing the narrowed return shape (name, type, item count only) and marking the endpoint as Preview, though it says nothing about pagination or result limits for a full-list call.

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 terse lines: what it returns, what it omits, then the alternative tool, followed by the endpoint. Front-loaded with the return-value constraint and zero 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 parameters and no output schema, the description carries the return-shape burden itself and does so ('name, type and item count'), while annotations cover the read-only safety profile. An agent has everything needed to select and 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?

The tool takes zero parameters (empty schema, no required fields), so there is no parameter semantics to document and the baseline of 4 applies. The description adds no misleading parameter hints.

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 Shared Lists') and precisely delimits the payload: 'Returns only the name, type and item count of every shared list.' This distinguishes it from the sibling get_shared_list, which returns the items themselves.

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

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

Explicitly routes the agent: use this for the summary listing, and 'Use "Get Shared List by name" to fetch the items themselves.' Names the alternative tool and the condition that selects it, leaving nothing to inference.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description merely repeats that this is a read operation via "[READ] GET". It adds no extra behavioral context such as authentication needs, rate limits, pagination, or what the endpoint returns.

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

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

The description is very short and front-loads the operation and HTTP method. It is efficient, though it is under-specified rather than optimally concise.

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

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

For a simple read endpoint with no parameters and no output schema, the description still omits what snippets are and when this endpoint is relevant. An agent can call it mechanically, but it is not well equipped to select it correctly among the many sibling tools.

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

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

The tool takes zero parameters, so the baseline for parameter semantics is 4. The description does not need to explain any parameter syntax or filtering, and the empty schema is consistent with a simple no-argument GET.

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 snippets") and adds the HTTP method and path ("[READ] GET /api/snippets/"). However, it does not explain what a "snippet" is in this API or distinguish this tool from any of the many sibling get_* 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?

There is no guidance about when to use this tool versus alternatives, nor any prerequisites or exclusions. The description only identifies the operation, leaving selection entirely to the 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?

The annotations already declare readOnlyHint=true and destructiveHint=false, and the description's "[READ]" marker merely repeats that. Beyond confirming the HTTP verb, it adds no behavioral context such as scope of the statistics, refresh behavior, or whether the data is aggregated.

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 short and front-loaded, but the first line duplicates the tool name and the second line repeats annotation content, so it packs very little value per token despite being brief.

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 tool with no output schema and one undocumented parameter, the description should at minimum clarify the parameter and the scope of the statistics. It provides only the endpoint path, leaving the agent without enough information to call it correctly or distinguish it from siblings.

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

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

The single parameter "tz" has 0% schema description coverage and is never mentioned in the description, so neither source explains what it means (presumably a timezone) or how it affects results. 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?

"Get Stats" simply restates the tool name and is a tautology; the only added information is the HTTP route GET /api/system/stats, which hints at system-level scope but does not say what stats are returned. With many siblings (get_bandwidth_stats, get_http_stats, get_status, get_nodes_statistics), there is no differentiation whatsoever.

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 contains no when-to-use guidance, no prerequisites, and no mention of any alternative sibling tool. An agent has no basis for choosing get_stats over get_bandwidth_stats or get_status.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the '[READ]' prefix is redundant. The description nonetheless adds real behavioral context absent from the annotations: the half-open interval semantics and the daily UTC granularity caveat explaining that 'traffic by new users' snaps to whole days at the range edges. That caveat materially affects interpretation of results.

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?

Content is front-loaded and the metric list is dense and useful. The only waste is the leading 'Get Stats Digest' restatement of the tool name and the redundant '[READ] GET /api/system/stats/digest' line, both of which duplicate structured metadata.

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 compensates by enumerating the returned metrics, and it documents boundary semantics and granularity caveats. An agent has enough to call and interpret it, though it lacks any hint about the response shape or 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 coverage is 100% and both parameter descriptions already state inclusive/exclusive boundary behavior, so the description's restatement of [start, end) adds little. Baseline 3 applies when the schema carries parameter semantics.

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

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

The description names a specific verb and resource (aggregated statistics digest over a datetime range) and enumerates the exact metrics returned: created/expired users, total traffic, traffic by newly created users, and new HWID devices. This clearly distinguishes it from generic siblings like get_stats. It does not, however, explicitly contrast itself with the other stats tools (get_bandwidth_stats, get_stats_user_usage), which would have earned a 5.

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

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

The range-based framing implies when the tool applies, but there is no explicit when-to-use, no exclusions, and no routing to the many sibling stats tools (get_stats, get_bandwidth_stats, get_hwid_devices_stats). An agent must infer selection from the metric list alone.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the '[READ]' marker and endpoint path add essentially no behavioral information. The description does not disclose aggregation semantics, pagination, default window, or what the usage figures represent.

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

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

It is compact and front-loaded with the operation. The trailing endpoint line is of marginal value and edges toward redundancy with the readOnly annotation, but overall there is no wasted prose.

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 annotated read tool with full schema coverage this is minimally viable. However, with no output schema and heavy sibling overlap, the description could reasonably say what is returned (per-node bandwidth over the range) and how it differs from adjacent stats tools.

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

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

Schema description coverage is 100%: start and end are documented as YYYY-MM-DD dates and topNodesLimit has a default and description. The description adds nothing beyond the schema (it only implies the date range), so the 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 states a clear verb+resource ('Get Nodes Usage') with a scoping qualifier ('by Range'). It is not a tautology, but it offers no differentiation from the many sibling stats tools such as get_node_usage, get_nodes_metrics, get_nodes_statistics, and get_stats_nodes_users_usage, so it lands at 'clear but no 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?

There is no when-to-use or when-not-to-use guidance and no named alternative, despite a crowded sibling space of node/usage statistics tools. The agent must infer selection entirely from the name.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds essentially nothing behavioral beyond reiterating readability via '[READ]', and it omits pagination/return-shape context for a stats endpoint with a topUsersLimit parameter.

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?

Very short and front-loaded, with the action leading. The trailing endpoint/method tag is marginally useful for confirming a POST-based read but borders on noise.

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 nested-body stats tool surrounded by many similar usage/stat tools, the description does too little: it neither disambiguates from siblings nor clarifies the nested nodesUuids body or the topUsersLimit cap. Read-only annotations and the schema carry most of the load, but routing context 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 75%, so most parameters (start, end, body/nodesUuids) are documented in the schema itself. The description adds no parameter meaning and leaves topUsersLimit, the undocumented 25%, unexplained in either place; baseline 3 fits given the decent 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?

The description names a specific verb and resource ('Get Nodes Users Usage') and a scoping dimension ('by Nodes UUIDs'), which tells an agent roughly what it returns. However, it never distinguishes itself from near-identical siblings such as get_stats_node_users_usage, get_stats_nodes_usage, or get_stats_user_usage, so the agent cannot confidently pick this one over the others.

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, no when-not-to-use, and no mention of alternatives despite several overlapping stats siblings. The '[READ] POST /api/bandwidth-stats/nodes/users' fragment is endpoint metadata, not usage guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the '[READ]' tag in the description is redundant. The description adds only the raw endpoint path and no context on result size, aggregation window semantics, or what the top-users limit affects.

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 lines, front-loaded with the action and resource, no wasted prose. It is terse but not padded.

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 four-parameter query tool with no output schema and no annotations beyond the read-only pair needs more explanation than this: what the usage figures represent, the time-range semantics, and how the limit parameter behaves are all 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?

Schema description coverage is only 50%: uuid and topUsersLimit are undocumented in the schema, and the description does nothing to compensate. It only restates 'by Node UUID', adding no format, range, or 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?

The description names a specific verb and resource ('Get Node Users Usage by Node UUID'), so the basic purpose is legible. However, it does not differentiate from several closely-named siblings such as get_stats_nodes_users_usage, get_stats_nodes_usage, and get_stats_user_usage, leaving an agent unclear which scope applies.

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 the many sibling stats tools, nor any prerequisite or exclusion guidance. The only clue is the implied 'node UUID' scoping in the title.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the '[READ] GET ...' line merely restates that. The description adds no behavioral context beyond the annotations: no indication of what 'usage' is measured in, whether results are aggregated or time-bucketed, or any rate/pagination 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?

It is short and the purpose is front-loaded, but the '[READ] GET /api/bandwidth-stats/users/:userId' line largely duplicates the readOnlyHint annotation and the tool name rather than adding information, and the remaining brevity reflects under-specification more than tight writing.

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 4-parameter tool with no output schema, the description omits the meaning of 'usage', how start/end bound the aggregation, and what topNodesLimit controls. An agent can infer the call shape from the schema but not the semantics of 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 coverage is 75% (userId, start, end are documented; topNodesLimit is not), and the description explains none of the parameters. In particular topNodesLimit — which shapes the response — is left undefined in both schema and description, so the description does not 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+resource+scope ('Get User Usage by Range') and the endpoint path /api/bandwidth-stats/users/:userId makes clear it is per-user bandwidth usage over a time window. It does not, however, distinguish itself from close siblings such as get_stats_node_users_usage, get_stats_nodes_users_usage, or get_internal_squad_user_usage.

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 and no mention of alternatives among the many usage/stats siblings. The only selection hint is the implicit [READ] marker, which does not help an agent choose between this and the other per-user or per-node usage tools.

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

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

The annotations already declare readOnlyHint=true and destructiveHint=false, so the non-mutating nature is fully covered by structured data. The description adds only the underlying route (GET /api/auth/status) and nothing about what the status reflects (token validity, session state) or how failures are surfaced; with annotations carrying the safety profile, this is adequate but thin.

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 single sentence is front-loaded and wastes no words. The appended "[READ] GET /api/auth/status" restates what the annotations and name already imply, which is minor redundancy rather than bloat.

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, no-output-schema tool, the definition is functional but omits the one thing an agent would want: what the returned status actually represents. Read-only safety is covered by annotations, so the gap is moderate rather than severe.

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 per the baseline there is nothing for the description to disambiguate. Schema coverage is 100% and the empty object is self-explanatory.

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 clear verb and resource ("Get the status of the authentication"), which is enough to distinguish it from data-heavy siblings like get_stats or get_subscription_info_by_short_uuid. It does not, however, contrast itself against near-neighbours such as get_remnawave_health or get_api_token_scopes, so the boundary is left to inference.

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

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

There is no statement of when this tool should be used, no preconditions (e.g. whether it requires an existing token), and no named alternative. The agent must guess that this is the auth-check probe rather than a general health check.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description corroborates with '[READ]' and adds the underlying HTTP endpoint (GET /api/subscription-page-configs/:uuid), which is real but marginal context; it says nothing about error behavior or what the returned config contains.

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 lines with zero filler, and the resource plus its key discriminator (uuid) is front-loaded. It is appropriately sized for a simple getter, though the endpoint annotation could be considered slightly redundant.

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 tool with annotations covering the safety profile and a self-constraining uuid schema, the description supplies the essential identity and discriminator. The only minor gap is that no output schema exists and the shape of the returned config is never hinted at.

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

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

Schema description coverage is 0%, but the schema itself carries a strict uuid format and regex pattern that fully constrain the single parameter, so the description's contribution ('by uuid' = the config's identifier) is minimal. Baseline 3 is appropriate given the schema's strong type/format constraints.

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 subscription page config by uuid'), which is clearer than a bare noun. The 'by uuid' phrasing and singular form implicitly separate it from siblings get_subpage_config_by_short_uuid and get_subpage_configs, though the distinction is never made explicit.

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

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

There is no when-to-use or when-not-to-use guidance, and no alternative sibling is named. An agent must infer from the tool name alone that this variant is for a full uuid while get_subpage_config_by_short_uuid takes a short uuid. No prerequisites or context are given.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the '[READ]' prefix plus the GET path merely repeat that read-only fact rather than adding new context. Nothing is said about what the subpage config contains, whether it requires subscription-scoped auth, or error behavior for unknown short UUIDs. It does not contradict the annotations, but adds nothing beyond them.

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

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

Very short and front-loaded, with no filler, but the brevity reflects under-specification rather than disciplined concision — it is a title plus an endpoint line with no substantive content.

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

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

For a read tool with no output schema and an undocumented parameter, the description should explain what the returned subpage config is and how it relates to sibling config tools. Instead it gives only a name and route, leaving the agent unable to confidently select or invoke it.

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

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

Schema description coverage is 0% and the single required parameter 'shortUuid' is completely undocumented. The description never explains what a short UUID is, its format, or how it differs from the UUID accepted by sibling get_subpage_config, so it fails to compensate for the schema gap.

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

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

The description is essentially the tool name restated plus the HTTP endpoint: 'Get Subpage Config by Short UUID' / 'GET /api/subscriptions/subpage-config/:shortUuid'. It does not distinguish this tool from close siblings like get_subpage_config, get_subpage_configs, or get_subscription_by_short_uuid_protected, so an agent cannot tell which subpage-config variant to pick.

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

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

There is no when-to-use guidance, no statement of when to prefer this over get_subpage_config (which likely takes a full UUID) or the list endpoint get_subpage_configs. The reader must infer the selection rule purely from the name.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description's '[READ]' and endpoint path are largely redundant with that, and it adds no new behavior context such as pagination, result size, or whether full config bodies are returned. Minor added value at best.

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 lines, front-loaded with the purpose. The '[READ] GET /api/...' fragment is arguably redundant given the readOnlyHint annotation, but it is compact and does not bloat the definition.

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 parameterless list read with no output schema, the definition is mostly sufficient, but it leaves open whether pagination applies, how large the response is, and how the returned configs differ from those of the singular siblings. 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?

The tool takes zero parameters and the schema is empty with 100% coverage, so there is nothing for the description to explain. Baseline 4 applies; no parameter ambiguity exists.

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 all subscription page configs'. The plural 'configs' paired with 'all' implicitly distinguishes it from the singular siblings get_subpage_config and get_subpage_config_by_short_uuid, but those siblings are never named, so the differentiation is inferable rather than explicit.

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

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

Usage is only implied by the word 'all' — an agent can guess this is the list-everything variant versus the single-config siblings, but there is no stated when-to-use, when-not-to-use, or named alternative. No prerequisites or filtering conditions are described.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description's '[READ]' merely restates that. The REST path (GET /api/subscriptions/by-id/:userId) adds a little context about the underlying resource, but nothing about permissions, 404 behavior, or rate limits.

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

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

Two short lines, front-loaded with the purpose. The bracketed HTTP verb/path is somewhat redundant with the annotations but costs little.

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 simple single-parameter read tool whose safety profile is covered by annotations and whose parameter is fully described in the schema. However, with no output schema, the description says nothing about what is returned (subscription object, link, status), leaving a small but real gap.

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 100% and the single userId parameter is fully documented in the schema. The description reinforces that the identifier is a User ID (not a subscription ID), which is mildly useful, but adds no format or constraint detail beyond the schema. 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 subscription) plus the lookup key (User ID), which distinguishes it from siblings like get_subscription_by_short_uuid_protected and get_subscription_by_username. It does not explicitly name those alternatives, but the key difference is inferable.

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

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

No when-to-use guidance, no prerequisites, and no mention of when to prefer this over get_subscriptions or the username/short-uuid variants. The agent must infer selection purely from the key type.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description's only added behavioral claim is 'protected route', which is unexplained jargon — it does not say what auth or permission is required, or what that protection means for the caller's 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?

Very short and front-loaded: purpose first, then route/HTTP method. The endpoint string is largely redundant metadata, but nothing is bloated or buried.

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, no explanation of the return payload, no explanation of 'protected', and a completely undocumented required parameter, the description leaves too much for the agent to infer about a tool that fetches a subscription object.

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

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

Schema description coverage is 0% for the single required shortUuid parameter, and the description only echoes the name ('by short uuid') without format, source, or validation details. It does not compensate for the undocumented parameter.

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

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

The description names a specific verb+resource (get subscription) plus the lookup key (short uuid), which is clearer than a bare name restatement. However, it fails to differentiate from the near-identical sibling get_subscription_info_by_short_uuid or explain what 'protected' adds, so it falls short of a 5.

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

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

There is no guidance on when to use this versus get_subscription_by_id, get_subscription_by_username, or the very similar get_subscription_info_by_short_uuid. The '(protected route)' parenthetical hints at a different access context but never states when an agent should pick this one.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the '[READ]' prefix is largely redundant. Beyond that, the description says nothing about auth requirements, behavior for unknown usernames, or return shape.

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 lines, resource stated first, with no filler sentences. Minor redundancy in restating the name and the read nature, but nothing is bloated.

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 one-parameter read tool with no output schema, minimal documentation is defensible, but the description still omits what the returned subscription represents and how it behaves for a nonexistent username. Adequate rather than complete.

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

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

Schema description coverage is 100% and there is a single parameter, so the schema carries the burden entirely. The description adds no extra meaning about username format or constraints, which is the baseline 3 case.

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 clear verb (get) plus resource (subscription) and the lookup key (username), which distinguishes it from get_subscription_by_id and get_subscription_by_short_uuid_protected. It is specific but adds no scope detail beyond the name itself.

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

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

Usage is implied by the required username parameter and the tool name, and the sibling set contains obvious alternatives (by id, by short uuid), but the description never states when to prefer this lookup over them. No exclusions or prerequisites are given.

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

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

The '[READ] GET' prefix merely echoes the readOnlyHint=true and destructiveHint=false annotations rather than adding context. No mention of authentication requirements, whether the shortUuid is public-facing, or what happens on an unknown ID.

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

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

It is short and front-loaded with the resource, with no filler sentences. However, the second line is largely redundant metadata (a verb repeat plus a raw route), so brevity here reflects under-specification rather than economy.

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 lookup with no output schema, the description should at least explain what the returned 'info' covers and how it relates to the 'protected' and subpage-config siblings. It does neither, leaving the agent unable to choose confidently among the subscription tools.

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