Remnawave Tools MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Most tools target distinct resource-action pairs, but there are overlaps like legacy vs non-legacy methods and multiple user lookup tools (by email, id, username, etc.) that could confuse selection.
Naming Consistency5/5
All tools follow the exact pattern remnawave_<resource>_<action> with snake_case, making naming perfectly predictable and consistent.
Tool Count1/5
With 152 tools, the surface is extremely bloated. Many tools are redundant or overly granular (e.g., multiple bulk operations, legacy methods), making it unwieldy for agents.
Completeness3/5
Covers major domains like users, nodes, hosts, billing, and profiles, but includes many niche or redundant operations while lacking some lifecycle operations (e.g., no straightforward user delete? Actually there is users_delete, so it's okay but uneven).
Average 1.8/5 across 152 of 152 tools scored. Lowest: 1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It only labels the tool as a mutation, omitting details such as whether it removes one or multiple users, if it requires an existing squad, or what side effects occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is too terse to the point of being unhelpful. It consists of a single line that adds no value beyond the tool name, failing to earn its space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, nested objects, no output schema, no annotations), the description is severely incomplete. An agent cannot determine how to invoke this tool correctly without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 4 parameters with 0% schema description coverage. The description adds no explanation for 'payload', 'confirmToken', 'responseMode', or 'mutationApproved', leaving the agent without context for proper usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description merely repeats the tool name and classifies it as a mutation, without stating what action it performs (e.g., 'remove users from an external squad'). It fails to specify the verb and resource, making it tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus siblings like remnawave_external_squads_add_users or remnawave_internal_squads_remove_users. There is no mention of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits but only says 'mutation'. It lacks details on side effects, permissions, or what 'set port' entails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely short, but under-specified to the point of being uninformative. Conciseness should not come at the cost of utility.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 params, nested object, no annotations or output schema), the description is completely inadequate for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no information about the four parameters, including payload, confirmToken, responseMode, or mutationApproved.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description merely repeats the tool name and labels it as a mutation, offering no verb or resource clarification. It does not distinguish from sibling bulk host operations like bulk_delete or bulk_set_inbound.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, nor any context on prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavior. It only states it's a mutation, which is already evident. It does not mention the need for a confirmToken, the effect of mutationApproved, or any side effects like cascading removals.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While extremely short, the description fails to be informative. Every sentence should add value, but this single sentence adds none beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (nested payload, confirmation token, response mode), the description is grossly incomplete. With no annotations or output schema, the agent cannot understand preconditions, effects, or response format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides zero explanation of the four parameters (payload, confirmToken, responseMode, mutationApproved). The agent gains no insight into how to structure the payload or use the confirmation flow.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description is a tautology, restating the tool name and adding '(mutation)'. It does not specify which users are removed from which squad, nor distinguish it from the sibling tool 'remnawave_internal_squads_add_users'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like remnawave_external_squads_remove_users or remnawave_internal_squads_add_users. No context for prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only says 'mutation' which is implied by 'upsert'. No disclosure of side effects, permissions, or other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely short but fails to convey any useful information. Every sentence should earn its place; this one does not.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, 4 params with 0% coverage, and no annotations, the description is completely inadequate for an agent to correctly invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and description adds no meaning to any parameter. The 4 parameters are completely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description is a tautology: it only repeats the tool name and adds '(mutation)'. Does not state what the tool does, the resource involved, or distinguish from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. No context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description only labels the tool as a 'mutation'. It fails to disclose behavioral traits like confirmation requirements, side effects, or error scenarios. The schema includes confirmToken and mutationApproved fields, but the description ignores them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that merely repeats the tool name. It is not concise in a helpful way; it is under-specified and lacks structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, nested objects, no output schema), the description provides no information about return values, prerequisites, or behavior. It is completely insufficient for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 4 parameters are documented in the schema. The description does not explain any parameter (payload, confirmToken, responseMode, mutationApproved), leaving the agent without guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description simply restates the tool name ('Remnawave users.bulk_extend_expiration_date (mutation)') without explaining what the tool does. It is a tautology, providing no additional clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as remnawave_users_bulk_all_extend_expiration_date or other bulk operations. Missing context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only labels the tool as a 'mutation' but provides no details on what state changes occur, whether permissions are required, or how confirmToken and mutationApproved affect execution.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While extremely short, the description is not concise in a helpful way—it is under-specified and lacks necessary details. It fails to communicate the tool's purpose or usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, 0% schema coverage, no output schema), the description is woefully incomplete. It provides no information about return values, side effects, or how to structure requests.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description adds no meaning to the parameters. The payload object with additionalProperties is especially vague; the agent cannot know its expected structure or content without explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remnawave external_squads.add_users (mutation)' is a tautology that merely restates the tool name. It does not specify what action is performed (e.g., adding users to a squad) or distinguish it from siblings like remnawave_external_squads_create or remnawave_external_squads_remove_users.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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. For example, it doesn't explain the difference between external and internal squads, or when adding users is appropriate versus creating or removing them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and no description of side effects, permissions, or reversibility, the agent cannot understand the tool's behavioral implications. 'Mutation' is already obvious from the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While very short, the description is under-specified and fails to provide necessary detail. It is not concise in a helpful way; it omits critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a bulk operation with a complex payload and no output schema, the description is grossly incomplete. An agent cannot determine how to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not explain any of the four parameters (payload, confirmToken, responseMode, mutationApproved). The agent has no guidance on how to use them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description merely restates the tool name with '(mutation)', providing no new information about what the tool actually does. It fails to specify that it disables hosts or any other action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus its siblings like remnawave_hosts_bulk_enable or remnawave_hosts_bulk_delete. The description offers no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description only says 'mutation,' which is insufficient. It does not disclose any behavioral traits such as destructive nature, authorization needs, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely short but at the cost of under-specification. Not concise; it's insufficient. Every sentence should earn its place, but this single sentence fails to communicate essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, nested objects, and four parameters, the description is completely inadequate. It lacks context for the agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description adds no meaning to the four parameters (payload, confirmToken, responseMode, mutationApproved). The agent gets no help understanding what each parameter does.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description merely repeats the tool name and notes it's a mutation, without stating what specific action (e.g., set inbound on hosts) is performed. It fails to distinguish from sibling tools like remnawave_hosts_bulk_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description provides no context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It only marks the tool as a 'mutation' but omits any side effects, required permissions, reversibility, or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is short, it fails to convey any useful information beyond the name. It is under-specified rather than concisely informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is completely inadequate given the tool's complexity: 4 parameters, a nested payload object, no output schema, and no annotations. Essential usage context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description provides no explanation for any of the 4 parameters (payload, confirmToken, responseMode, mutationApproved). The agent cannot infer their meaning or usage from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a tautology: it merely restates the tool name 'Remnawave infra_billing.delete_history_record' and adds '(mutation)', which is already implied by 'delete'. It does not specify what a history record is or what deleting it entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like other delete tools or listing tools. There are no prerequisites, exclusions, or context for when deletion is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No behavioral traits are disclosed beyond the bare 'mutation' label. There are no annotations to supplement, and the description omits any indication of side effects, requirements, or outcomes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, but this is under-specification rather than efficient conciseness. It fails to earn its place by providing any useful information beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with a nested object parameter and no output schema, the description is wholly incomplete. It lacks essential details about what the tool does, how to use it, and what to expect as a result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description adds nothing about parameters. The payload object, confirmToken, responseMode, and mutationApproved are entirely unexplained, leaving the AI agent without guidance on how to properly invoke the tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description is 'Remnawave infra_billing.update_provider (mutation).' This is a tautology, restating the tool name with no additional explanation of what updating a provider entails. It does not clarify the action or distinguish it from other billing tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like create_provider or delete_provider. No prerequisites, context, 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only labels the tool as a 'mutation' but provides no details on side effects, required permissions, or the confirmation mechanism hinted by confirmToken and mutationApproved parameters. With no annotations, the description carries full burden and fails to disclose behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is short (one sentence), it is a case of under-specification rather than conciseness. It lacks crucial information and does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters including a nested object, no output schema, no annotations), the description is completely inadequate. It fails to provide any useful context for an AI agent to select or invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain any of the 4 parameters (payload, confirmToken, responseMode, mutationApproved). With schema description coverage at 0%, the description must compensate but offers no information on parameter meaning or usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remnawave nodes.profile_modification (mutation).' is essentially a tautology, restating the tool name without clarifying what the tool modifies about node profiles. It fails to distinguish from sibling tools like remnawave_nodes_update or remnawave_profiles_update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as nodes update or profiles update. There is no mention of prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description merely labels it as a 'mutation' without revealing any behavioral traits such as idempotency, side effects, authentication needs, or potential for data loss.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While only 12 words, this is under-specification rather than conciseness. The description fails to provide essential information needed for correct tool invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain what the tool accomplishes, how to use the parameters, or what to expect after invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description provides no explanation for any parameter. The 'payload' object is left completely unspecified, and 'confirmToken' and 'mutationApproved' suggest a confirmation mechanism but are not described.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description only states the function name in a different format ('Remnawave subscription_page_configs.create (mutation)'). Does not specify the verb or resource, and does not distinguish from sibling tools like 'remnawave_subscription_page_configs_update' or 'remnawave_subscription_page_configs_clone'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool over alternatives. Does not mention prerequisites, conditions, or exclusions. Leaves the agent without context for appropriate selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says '(mutation).' It fails to disclose behavioral traits such as what gets modified, required authorizations, side effects, or confirmation steps. The description carries the full burden but adds no value beyond the label.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but under-specified. It is not concise in the sense of efficient communication; it merely restates the name. A helpful description would be longer but more informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, high parameter count, and no annotations, the description should provide comprehensive context. It fails to explain the tool's purpose, how to use the parameters, or what the mutation entails. The description is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 4 parameters with no descriptions (schema coverage 0%), and the tool description does not explain any parameter meaning. For example, 'payload' likely contains extension details but is not clarified. The description adds no semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description restates the tool name as 'Remnawave users.bulk_all_extend_expiration_date (mutation).' It does not specify what the tool does, just that it's a mutation. This is a tautology and provides no purpose clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. Sibling tools like 'remnawave_users_bulk_extend_expiration_date' exist but no differentiation or usage context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only labels the tool as a 'mutation', which is obvious from the name. It does not disclose what traffic resetting entails, whether it is irreversible, or what permissions are needed. Parameters like confirmToken and mutationApproved are not explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this sacrifices completeness. It is under-specified rather than concise. One sentence that says nothing beyond the name and type is insufficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a bulk mutation tool with no annotations, no output schema, and multiple parameters, the description is woefully incomplete. It fails to provide essential context for safe and correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 4 parameters with 0% description coverage in the schema, yet the description adds no information about them. The 'payload' object is left undefined, and the purpose of confirmToken, responseMode, and mutationApproved is not clarified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description merely restates the tool name as 'users.bulk_all_reset_traffic (mutation)' without explaining what it does. It does not clarify that it resets traffic for all users, nor does it distinguish it from similar sibling tools like remnawave_users_bulk_reset_traffic or remnawave_users_reset_traffic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, side effects, or scenarios where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only says 'mutation' but fails to disclose behavioral traits: what enabling a user entails (e.g., changes to status, traffic, subscription), required permissions, side effects, or any safety concerns. Agent cannot infer consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely short but not concise in a useful way. Lacks structure; every sentence should earn its place. This is an under-specified label, not a functional description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero annotations, no output schema, 4 undocumented params, and a large sibling set, the description fails to provide sufficient context for safe and correct tool invocation. Essential information about payload structure and effects is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 4 parameters with 0% description coverage. The description adds no meaning beyond schema structure. Payload is a generic object with no documented fields; confirmToken, responseMode, mutationApproved are unexplained. Agent cannot determine correct usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description is nearly a tautology: 'Remnawave users.enable (mutation).' It restates the tool name and indicates it's a mutation but provides no specific verb or resource distinction. Fails to differentiate from siblings like remnawave_users_disable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. No context about prerequisites, filtering, or when not to use it. Among many user-related tools, the agent has no basis for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description labels the tool as '(read)', implying it is non-destructive, but no annotations exist. It lacks details on required permissions, rate limits, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but under-specified; it prioritizes brevity over usefulness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters (including a nested object), no output schema, and many siblings, the description fails to provide essential context. It omits return value, parameter usage, and selection criteria.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds no meaning to the input parameters. It does not explain payload, confirmToken, responseMode, or mutationApproved.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description merely restates the tool name and adds '(read)'. It does not specify what the tool retrieves (e.g., bandwidth usage for a node and user) or differentiate it from similar sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this legacy tool versus other bandwidth stats tools like get_node_users_usage or get_user_usage_legacy.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, description claims '(read)' but input schema includes 'mutationApproved' and 'confirmToken' parameters typically used for mutations, creating confusion. No disclosure of behavioral traits, safety, or side effects. The read claim contradicts the schema's implication of a possible write.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely short but under-specified. Single sentence lacks essential information, making it ineffective. Not a model of conciseness as it omits critical details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 complex parameters (nested object, enum) and no output schema or annotations, the description fails to provide any context for usage. Completely inadequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and description provides no explanation for any of the 4 parameters (payload, confirmToken, responseMode, mutationApproved). The description adds no meaning; agent cannot infer how to correctly populate the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description only says 'Remnawave bandwidth_stats.get_user_usage_legacy (read).' It vaguely indicates a read operation but does not specify what data is retrieved (bandwidth stats for a specific user?). It minimally distinguishes from siblings like get_user_usage (non-legacy) but lacks a clear verb+resource statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. Does not mention when legacy vs non-legacy should be used, nor how it differs from other bandwidth stats tools. No context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description only labels the tool as a 'mutation'. It does not disclose behavioral aspects such as authorization requirements, side effects, or the role of the confirmToken and mutationApproved parameters. The agent has no insight into what happens when this tool is called.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is short, it is under-specified to the point of being unhelpful. Conciseness should not compromise substance; here it fails to convey essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, one nested object, no output schema) and the lack of annotations, the description is completely inadequate. The agent has no information on return values, error conditions, or how to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of the parameters (payload, confirmToken, responseMode, mutationApproved). The payload is an open object with no guidance on its structure. This leaves the agent unable to construct a valid call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'external_squads.create (mutation)' which hints at creation but does not explicitly say what is created (e.g., 'external squad'). It is nearly a tautology as it restates the tool's method name. Contrast with high-scoring examples that use specific verb+resource constructions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus its many siblings (e.g., remnawave_external_squads_add_users, update, delete). There is no mention of context, prerequisites, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only labels the tool as a mutation, but fails to mention side effects, required permissions, whether confirmation is needed, or what state changes occur. The schema hints at confirmation tokens and approval, but this is not explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (7 words), but it sacrifices essential information. It is under-specified rather than efficiently informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters (including a nested object), no output schema, and multiple siblings, the description is wholly inadequate. It fails to provide any context for proper tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides zero information about parameters. The payload, confirmToken, responseMode, and mutationApproved fields are undocumented, leaving the agent to guess their roles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remnawave hosts.bulk_enable (mutation)' essentially restates the tool name and notes it's a mutation, but does not explicitly state that it enables multiple hosts. This is a tautology, lacking a specific verb and resource description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not indicate when to use this tool versus alternatives like bulk_disable, bulk_delete, or bulk_set_inbound. Agents receive no context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the burden is on the description to disclose behavioral traits. The word 'mutation' implies a write operation, but there is no detail on side effects, required permissions, rate limits, or what happens to existing hosts. This is severely lacking.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but not effectively concise; it sacrifices useful information. It does not earn its place as it provides little value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's mutation nature with a complex nested payload, no output schema, and absence of annotations, the description is completely inadequate. It fails to provide necessary context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 4 parameters with 0% description coverage. The description adds no meaning to the 'payload', 'confirmToken', 'responseMode', or 'mutationApproved' parameters. The 'payload' is a vague object with additionalProperties, leaving the agent guessing its structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remnawave hosts.create (mutation)' indicates a mutation action but does not clarify what a host is or what creating entails. It barely restates the tool name and fails to distinguish from sibling tools like remnawave_hosts_update or remnawave_hosts_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, context, or conditions under which this tool should be invoked.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only says 'mutation'. It does not disclose required permissions, side effects, idempotency, or what happens upon deletion. The agent learns nothing beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise at 6 words, but at the expense of usefulness. It is under-specified and does not earn its place as a helpful description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, no output schema, and no annotations, the description is completely inadequate. It fails to provide any context for the agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no parameter meaning. The payload is an open-ended object, and confirmToken, responseMode, and mutationApproved are unexplained. The agent cannot infer correct usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description restates the name 'hosts.delete' and adds 'mutation', but does not specify what kind of hosts or what deletion entails. It fails to distinguish from similar tools like remnawave_hosts_bulk_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. There are sibling tools for bulk operations, but no mention of appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It only says 'mutation', which implies a write operation but fails to describe side effects, success/failure behavior, authorization needs, or whether the operation is reversible. This is completely inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (8 words) but this is under-specification rather than conciseness. It lacks critical details and does not effectively communicate the tool's purpose or usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, nested payload, no output schema, no annotations), the description is severely incomplete. It fails to explain return values, required fields, or any behavioral context, making it nearly useless for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 4 parameters with 0% description coverage. The description adds no information about the payload, confirmToken, responseMode, or mutationApproved parameters. The payload is an open object with additionalProperties, and no guidance is given on required fields or expected structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it is a 'mutation' for 'create history record', but it merely restates the tool name and provides no specific verb or resource context. It does not explain what the history record is, what it contains, or how it differs from sibling tools like remnawave_infra_billing_delete_history_record.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives, such as list_history or delete_history_record. There is no mention of prerequisites, context, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'read', but the input schema includes parameters like mutationApproved and confirmToken, which are typical for mutations. This inconsistency is not addressed, and no additional behavioral details are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but fails to convey essential information; it is under-specified rather than concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, 0% parameter coverage, and a minimal description, the agent has insufficient context to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description adds no information about any of the four parameters (payload, confirmToken, responseMode, mutationApproved).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description merely restates the tool name and labels it as a read operation. It does not specify what 'accessible nodes' are or how this tool differs from similar tools like remnawave_internal_squads_get or remnawave_nodes_get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor are there any prerequisites or context for its invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description only labels it a mutation. No side effects, idempotency, permissions, or other behavioral traits are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely brief but at the cost of informativeness. It is under-specified, not concise in a helpful way.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 4 parameters including a complex object, the description fails to provide necessary context. Agents cannot determine required fields or expected behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 4 parameters with no descriptions. The description adds no value, leaving agents without any understanding of what each parameter does, especially the critical 'payload' object.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states it is an update mutation on internal squads, but does not elaborate on what specific attributes or operations are involved. It barely clarifies the resource beyond the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like remnawave_external_squads_update or other squad operations. Context is completely absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist; description merely labels it a mutation without disclosing side effects, permissions, or specifics about behavior (e.g., whether it creates/updates, conflict handling).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely short, but under-specified to the point of being unhelpful. Not a model of conciseness; every sentence should add value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, no output schema, and no annotations, the description fails to provide necessary context for correct invocation. Incomplete and insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and description does not explain any of the 4 parameters (payload, confirmToken, responseMode, mutationApproved). The payload object's structure is entirely opaque.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'upsert_node (mutation)', which identifies the action and resource but does not clarify what upserting node metadata entails or how it differs from other node operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No information on when to use this tool versus alternatives like remnawave_nodes_create or remnawave_metadata_get_node. No context or conditions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only labels the operation as a 'mutation' but fails to explain side effects, whether it requires a confirmation token, or how the payload is processed. This is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is short (one sentence), it sacrifices essential detail. True conciseness would provide clear, necessary information without fluff; here it lacks substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no parameter descriptions, and a complex nested payload, the description is entirely inadequate. It does not explain how to construct a request or interpret the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 4 parameters with 0% description coverage. The description does not explain the purpose of any parameter, particularly the 'payload' object, which is critical. No guidance on structure or required fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description is extremely brief: 'Remnawave nodes.bulk_update (mutation).' It barely indicates it's a mutation for bulk updating nodes, but does not specify what 'bulk' entails or differentiate it clearly from siblings like remnawave_nodes_update. The purpose is vague and provides little actionable clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. There is no mention of when to use this tool over alternatives like remnawave_nodes_update (single node) or remnawave_nodes_bulk_actions. The agent is left without context to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must disclose behavioral traits. It only says '(read)', which is minimally informative. It does not mention any side effects, authentication needs, rate limits, or response structure, leaving the agent uninformed about how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is due to under-specification rather than conciseness. Every sentence should add value; here, the single sentence adds almost no value beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters, no output schema, many sibling tools), the description is grossly incomplete. It fails to explain how to invoke the tool, what parameters are for, or what the expected output is, making it nearly useless for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage and the description adds no meaning to any of the four parameters (payload, confirmToken, responseMode, mutationApproved). The agent receives no explanation of their purpose, defaults, or expected values beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remnawave nodes.list (read)' essentially restates the tool name and indicates a read operation, but it is too vague to clarify what is being listed or how it differs from sibling tools like remnawave_nodes_get or remnawave_nodes_list_tags. It lacks specificity about the resource and scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With many sibling tools for node operations, the agent has no basis to choose this tool over others like remnawave_nodes_get or remnawave_nodes_create.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits but only states 'read'. It does not explain side effects, authentication needs, or output expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is too brief to be useful; it is under-specified rather than concise. Every sentence should earn its place, but this single sentence adds no value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and no parameter elaboration, the description is completely inadequate. It does not help the agent understand what the tool returns or how to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description adds no meaning to the four parameters (payload, confirmToken, responseMode, mutationApproved). The user must infer their purpose from names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description repeats the tool name with '(read)' appended, offering no additional clarity on what 'tags' are or how they relate to nodes. It fails to distinguish from sibling tools like remnawave_users_list_tags.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description lacks any context about scenarios or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only labels the tool as 'read', but the input schema includes mutation-related fields (mutationApproved, confirmToken), which suggests potential side effects not disclosed. No behavioral traits beyond the read hint are described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but it under-specifies the tool. It lacks essential details and does not earn its place as a standalone description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given four parameters, no output schema, and many sibling tools, the description is completely inadequate. It provides no context about computed profiles, return values, or parameter behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation for any of the four parameters (payload, confirmToken, responseMode, mutationApproved). The agent has no semantic understanding of what to input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description vaguely states it's a read operation on profiles, but 'computed' is undefined. It does not distinguish from sibling tools like remnawave_profiles_get or remnawave_profiles_list, leaving the agent without a clear purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of context or exclusions, leaving the agent to guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear the full burden. It only says 'mutation' but fails to disclose any behavioral traits such as required permissions, side effects, or what reordering entails. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. It lacks structure and fails to provide essential information. A single sentence repeating the tool name does not constitute a helpful description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (4 parameters, nested objects, no output schema), the description is entirely inadequate. It omits all contextual information needed for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention any parameters. With 0% schema description coverage and 4 parameters (including a nested object and an enum), the agent has no hints about what the payload or confirmToken represent. The description adds zero value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description repeats the tool name and indicates it's a mutation, but provides no additional detail to distinguish it from sibling reorder tools like remnawave_hosts_reorder or remnawave_profiles_reorder. It barely adds value over 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.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool vs alternatives. There are many sibling reorder tools, and the agent has no context to decide which to invoke.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only labels the tool as a 'mutation' but does not describe side effects, permissions required, or what state changes occur. Crucial context is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While concise, the description is severely under-specified. It fails to provide necessary information, making it unhelpful rather than efficiently informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (a mutation with a payload and confirmation token) and the lack of output schema, the description is completely inadequate. It does not explain return values, errors, or the effect of reordering.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 4 parameters with 0% description coverage, and the description provides no explanation of the payload, confirmToken, responseMode, or mutationApproved fields. The description adds no semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Remnawave templates.reorder (mutation)', which redundantly repeats the tool name. It indicates a mutation but provides no specifics about what reordering entails or what 'templates' refers to. It does not differentiate from sibling reorder tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus the many other reorder tools (e.g., remnawave_hosts_reorder, remnawave_profiles_reorder). There is no mention of prerequisites, context, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It only labels the operation as a mutation but does not disclose that it updates all users, requires a confirmation token, or the implications of the payload parameter. Critical behavioral traits are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, but it is under-specified rather than concise. It does not earn its place because it provides no useful information beyond a repeat of the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters including a nested payload, no output schema, and no annotations), the description is completely inadequate. It fails to explain the tool's purpose, parameters, or effects, leaving the agent unable to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no information about any parameter. The payload, confirmToken, responseMode, and mutationApproved parameters are not explained at all, leaving the agent without meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remnawave users.bulk_all_update (mutation)' repeats the tool name and adds the term 'mutation', but does not specify what the tool actually updates, the scope ('all users' is implied by name), or how it differs from similar sibling tools like 'remnawave_users_bulk_update'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, prerequisites, or the role of parameters like confirmToken or mutationApproved. The description offers no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It only labels the tool a 'mutation', which is implicit from the name. It fails to mention side effects, required permissions, or whether traffic is reset to zero, making it opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but sacrifices informativeness. It is not effectively concise; it omits critical details. A single sentence restating the name is under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters with a nested payload object, no output schema, and no annotations), the description is grossly inadequate. It does not explain what the payload expects, the purpose of confirmToken, or the result of the mutation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, yet the description provides no explanation for any of the four parameters (payload, confirmToken, responseMode, mutationApproved). The agent has no guidance on how to populate them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remnawave users.bulk_reset_traffic (mutation)' barely adds beyond the tool name. It does not specify which users are affected (e.g., selection criteria) nor distinguishes from siblings like 'remnawave_users_reset_traffic' (single user) or 'remnawave_users_bulk_all_reset_traffic' (all users).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. There is no mention of prerequisites, context, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only labels it as a mutation but does not disclose behavioral traits: what happens to users' subscriptions, reversibility, side effects, or required permissions. The agent lacks critical safety information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One line is not conciseness; it is under-specification. The description lacks structure and fails to present key information upfront. Every sentence should add value, but this text adds none beyond the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation with 4 params, nested objects, no output schema, and zero annotations, the description is critically incomplete. The agent cannot determine how to construct a valid request or interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 4 parameters including a generic 'payload' object with no constraints, but description provides zero detail about how to populate them. With 0% schema description coverage, the tool is unusable without external knowledge.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description merely restates the name as 'Remnawave users.bulk_revoke_subscription (mutation).' It adds no detail about what bulk revoking a subscription entails or how it differs from singular revoke. Sibling tools like remnawave_users_revoke_subscription have similar naming, but no distinction is provided.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like remnawave_users_bulk_delete_by_status or remnawave_users_revoke_subscription. No prerequisites, context, or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only labels the tool as a 'mutation', but does not explain side effects, authorization needs, or the role of confirmToken and mutationApproved. The agent cannot infer behavioral implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but lacks essential information, making it under-specified rather than concisely informative. It fails to earn its place by not adding value beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters, nested object, no output schema, no annotations), the description is grossly incomplete. It does not cover what the tool does, how to use confirmToken/mutationApproved, or what the response looks like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description provides zero explanation for any parameter. The payload is an opaque object with additionalProperties, yet no hint is given about its structure or expected fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description 'Remnawave users.bulk_update (mutation)' is nearly a tautology, restating the tool name and type. It does not specify the resource being updated (e.g., which user fields) or distinguish from sibling tools like remnawave_users_bulk_all_update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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 other bulk user tools such as remnawave_users_bulk_delete or remnawave_users_bulk_extend_expiration_date. The description omits any conditions, prerequisites, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only says 'mutation', which is already implied by 'update'. It fails to disclose whether the operation is additive or replaces squads, if confirmation is required (despite confirmToken and mutationApproved parameters), or what side effects occur. No annotations exist to cover this gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but fails to convey essential information. Effective conciseness retains necessary detail; here, the brevity results in under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, no output schema, and no annotations, the description is woefully incomplete. It does not explain the tool's role within the broader squad/user ecosystem, leaving the agent without enough context to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does not explain any of the four parameters (payload, confirmToken, responseMode, mutationApproved) beyond what the schema's property names imply. The purpose of payload and the confirmation workflow are completely opaque.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only restates the tool name and labels it as a mutation. It does not explain what 'squads' refers to (internal/external) or what updating squads for users entails. Siblings include multiple squad tools, but no differentiation is provided.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like remnawave_external_squads_update or remnawave_users_bulk_update. There is no mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only states 'mutation', which is clear from the operation name. There is no information about the effects of calling the tool, the role of parameters like confirmToken or mutationApproved, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, but it is under-specified to the point of being unhelpful. It consists of a single phrase that adds no new information, making it more of a tautology than a concise, informative summary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (4 parameters, no output schema, nested objects, and many sibling tools), the description is severely lacking. It does not explain how to use the parameters, what the payload should contain, or how it differs from similar tools like bulk delete. This is inadequate for an AI to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameter meaning, but it does not. Parameter names like 'payload' and 'confirmToken' are somewhat self-explanatory, but the complex 'payload' object is left completely undocumented. The description adds no value beyond raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remnawave users.delete (mutation)' essentially repeats the tool name and adds '(mutation)', which is already implied by 'delete'. It fails to specify whether the tool deletes a single user or multiple users, and does not distinguish it from sibling tools like 'remnawave_users_bulk_delete'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as bulk delete. There is no mention of prerequisites, context, or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior but only says 'mutation'. It fails to explain what disabling entails, side effects, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but lacks substance; it is under-specified rather than concise. A single vague sentence does not qualify as good content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and complex parameters, the description provides no context about return values or how to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description adds no meaning to the 4 parameters (payload, confirmToken, responseMode, mutationApproved). Completely inadequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remnawave users.disable (mutation)' barely indicates it disables users; it's a vague restatement of the tool name. It does not distinguish from sibling tools like remnawave_users_enable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like remnawave_users_delete or remnawave_users_enable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must supply behavioral details, but it only labels the tool as a 'mutation'. It does not disclose required permissions, side effects, what occurs on success/failure, or the role of parameters like confirmToken or mutationApproved.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (7 words), but it is under-specified rather than concise. It fails to include essential information that could be conveyed in a few more sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a nested payload parameter and no output schema, the description must provide context on input structure and behavior. It does neither, leaving the agent with no usable information beyond the name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds nothing about the four parameters. The payload, confirmToken, responseMode, and mutationApproved remain completely unexplained, leaving the agent unable to construct valid calls.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description merely restates the tool name and adds '(mutation)', providing only that it is a write operation. It does not specify what a device is or what creating it entails, and it barely distinguishes from sibling HWID tools (e.g., delete, list).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool, prerequisites, or alternatives. The agent receives no context to decide between this and similar tools like remnawave_hwid_delete_device or remnawave_hwid_get_user_devices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as irreversibility, authorization needs, or the role of parameters like 'confirmToken' and 'mutationApproved' in controlling the operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is due to underspecification rather than conciseness. It fails to provide necessary information, so brevity here is a drawback.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, nested object, no output schema, no annotations), the description is woefully incomplete. An agent cannot determine how to construct a valid request or interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description offers no explanation for any of the four parameters. The 'payload' object, 'confirmToken', 'responseMode', and 'mutationApproved' remain completely undocumented, leaving the agent without guidance on how to properly invoke the tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description merely restates the name as 'Remnawave hwid.delete_all_devices (mutation).' It does not clarify what scope the deletion applies to (e.g., all devices for a specific user or globally). Compared to sibling 'remnawave_hwid_delete_device,' the differentiation is implied but not explained.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No instructions on when to use this tool versus alternatives like 'remnawave_hwid_delete_device.' There is no mention of prerequisites, confirmation requirements, or context where bulk deletion is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description labels it 'sensitive-read', hinting at read-only behavior, but the presence of parameters like 'mutationApproved' and 'confirmToken' could suggest mutation capabilities, creating ambiguity. No side effects or permissions are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but lacks substance. It fails to convey essential information, making it under-specified rather than concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 undocumented parameters, no output schema, and no annotations, the description is wholly insufficient. It does not cover tool behavior, return values, or parameter details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description does not explain any of the 4 parameters (payload, confirmToken, responseMode, mutationApproved). Agents cannot infer their meaning or usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Remnawave hwid.list_users (sensitive-read)', indicating it lists users, but it does not clarify what 'hwid' refers to or differentiate this from many sibling tools like 'remnawave_users_list' that also list users. The purpose is vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. With many sibling tools listing users, the description provides no criteria for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description labels the tool as a 'mutation', implying a destructive operation, but provides no further behavioral details. With no annotations, it fails to disclose what exactly gets deleted, potential side effects, or required confirmations. The schema includes a confirmToken and mutationApproved field, but these are not mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence), but it lacks essential information. It is under-specified rather than appropriately concise, and it does not front-load important details that would help an agent decide to invoke the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema, no annotations, and a complex input schema with a nested object, the description is severely inadequate. It does not provide enough context for an agent to use the tool correctly or safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the four parameters (payload, confirmToken, responseMode, mutationApproved) or their roles. This is a critical gap given the presence of nested objects and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remnawave infra_billing.delete_node (mutation)' adds only the word 'mutation' beyond the tool name, which already clearly indicates deletion. It does not specify what node is being deleted or provide any unique context, making it barely above a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like remnawave_nodes_delete or other deletion tools in the infra_billing group. There is no mention of prerequisites, conditions, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only labels the tool as a mutation, which is obvious from the name. It does not explain what disabling does, whether it is reversible, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While short, the description is ineffective and under-specified. It does not earn its place as it adds no value beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a nested object parameter and no output schema, the description is severely incomplete. It fails to provide enough context for an AI agent to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to any of the four parameters (payload, confirmToken, responseMode, mutationApproved). Their purpose and impact are completely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a tautology, restating the tool name 'Remnawave nodes.disable (mutation).' It fails to differentiate between disabling and other node actions like enable or delete, which are present in siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as remnawave_nodes_enable or remnawave_nodes_delete. There is no when-not-to-use or prerequisite information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only labels the tool as a 'mutation' but omits critical details such as side effects (e.g., user disconnections, traffic interruption), required permissions, or return behavior. This is severely inadequate for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one sentence, 3 meaningful words), but it is under-specified rather than concise. Every sentence does not earn its place because it fails to convey essential information about the tool's operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description is completely inadequate. It fails to explain the effect of restarting nodes, the expected input format, or the outcome. The agent cannot reliably determine how to invoke or what to expect from this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for 4 parameters, and the description adds no explanation for 'payload', 'confirmToken', 'responseMode', or 'mutationApproved'. The agent receives no help understanding their purpose or valid values beyond the schema's basic types and enums.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remnawave nodes.restart (mutation).' essentially restates the tool's name ('remnawave_nodes_restart') and labels it as a mutation. It fails to specify what restarting a node entails or to distinguish it from siblings like 'remnawave_nodes_restart_all', which is a clear alternative. The purpose is vague and tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'remnawave_nodes_restart_all' or 'remnawave_nodes_disable/enable'. There is no context about prerequisites, when a restart is appropriate, or when other tools should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only labels the tool as a mutation, failing to disclose side effects, required permissions, or what happens during creation. This is insufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, but it is under-specified rather than concise. It lacks critical information that would justify its brevity, making it unhelpful despite being short.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (four parameters, nested objects, no output schema, no annotations), the description is remarkably incomplete. It fails to explain what the tool does, what inputs are required, or what the output looks like, leaving the agent with virtually no actionable information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has four parameters (payload, confirmToken, responseMode, mutationApproved) with 0% description coverage, and the tool description provides no explanation of their meaning or usage. The agent receives no help in constructing valid inputs, especially for the opaque 'payload' object.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Remnawave profiles.create (mutation)', indicating a creation action, but it is vague and does not explain what a 'profile' is or how this tool differs from siblings like remnawave_profiles_update or remnawave_profiles_delete. It essentially restates the tool name with a mutation label, providing minimal clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. There is no mention of prerequisites, use cases, or contexts where profiles_create is appropriate, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states it is a 'mutation'. It does not disclose any behavioral traits such as side effects, idempotency, required permissions, or potential destructive actions. The description carries the full burden but is nearly empty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (two words plus '(mutation)'), which is underspecification rather than conciseness. Every sentence should earn its place, but here there is no substantive content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters (including a nested object), no output schema, and no annotations, the description is entirely insufficient. It does not help the agent understand what the tool does, what parameters are needed, or what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 4 parameters with 0% description coverage, yet the description does not explain any of them. It fails to add meaning beyond the schema, despite the schema being minimal (e.g., 'payload' is an untyped object).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is 'Remnawave snippets.create (mutation)', which essentially repeats the tool name and resource. It adds no detail about what a snippet is or what creation entails, and does not distinguish from sibling tools like 'remnawave_snippets_delete' or 'remnawave_snippets_list' beyond implying it is a create operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description provides no context about prerequisites, typical use cases, or situations where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description labels the tool a 'mutation' but provides no details about what gets destroyed, authorization requirements, irreversibility, or side effects. With no annotations, the description fails to disclose critical behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this conciseness comes at the cost of informativeness. It could be longer to include necessary context while remaining efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of schema descriptions, no output schema, and a mutation tool with 4 parameters, the description is wholly inadequate. It provides no information about return values, error conditions, or how to safely invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and no parameter details in the description, the agent receives no help understanding the four parameters. 'payload' is an untyped additionalProperties object, and 'confirmToken', 'responseMode', 'mutationApproved' have no explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remnawave templates.delete (mutation)' merely restates the tool name and action. It does not clarify what templates are being deleted or provide any distinguishing context beyond the verb 'delete'. This is a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus its siblings (e.g., remnawave_templates_create, remnawave_templates_update). There is no mention of prerequisites, when not to use, or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'mutation.' Important behavioral details such as destructive nature, required permissions, safety checks (e.g., confirmToken, mutationApproved fields) are not explained. The description adds no transparency beyond the schema defaults.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but fails to convey essential information. Conciseness is not beneficial when critical details are omitted. The single sentence does not front-load actionable content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero schema coverage, no output schema, and the presence of many related sibling tools, the description is wholly insufficient. The agent cannot determine the tool's purpose, input requirements, or output behavior. Complete improvement is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not explain any parameter. The payload object (likely containing status or filter criteria), confirmToken, responseMode, and mutationApproved are completely undocumented, leaving the agent without guidance on how to correctly construct the input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description merely restates the tool name as 'Remnawave users.bulk_delete_by_status (mutation).' It indicates a mutation operation but does not clarify what 'status' means (e.g., active, expired) or what the tool actually does beyond deleting users by some status. This is barely above a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool compared to sibling tools like remnawave_users_bulk_delete, remnawave_users_bulk_disable, or other status-based operations. No prerequisites or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It labels it 'sensitive-read' but does not explain if it's destructive, idempotent, or requires special authentication. The presence of mutationApproved parameter contradicts the read hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely short but uninformative. A single phrase sacrifices substance for brevity; it does not earn its space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 params, no output schema, many sibling tools), the description is grossly insufficient. It fails to explain input, output, or context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to the 4 parameters. The 'payload' object is a black box; no indication of what fields to include (e.g., user ID).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description merely restates the tool name as 'Remnawave users.get_by_id' and adds 'sensitive-read', which is a hint but does not explicitly state that it retrieves a user by ID. It lacks a clear verb-resource statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like remnawave_users_get_by_email or remnawave_users_get_by_username. The description implies a lookup operation but provides no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Only mentions 'read', implying non-destructive, but lacks details on what data is returned, side effects, or authorization needs. No annotations are provided to compensate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only one sentence, but it is under-specified rather than efficiently informative; important context is missing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and 4 parameters undefined, the description fails to explain what the tool does, what parameters mean, or what the response looks like. Completely inadequate for a tool with this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no information about the four parameters (payload, confirmToken, responseMode, mutationApproved) and the schema has 0% description coverage, so the agent receives no guidance on how to use them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it is a read operation for 'hwid.get_stats', but does not specify what 'stats' entails, making it ambiguous compared to sibling hwid tools like 'remnawave_hwid_get_top_users' or 'remnawave_hwid_get_user_devices'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, no context about prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It only states 'sensitive-read', hinting at read access to sensitive data, but does not specify 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but at the expense of informativeness. It is under-specified rather than concise, failing to earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no output schema, and no annotations, the description is woefully incomplete. It does not explain what the tool does, how to use it, or what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description adds no explanation of the four parameters (payload, confirmToken, responseMode, mutationApproved). Their purpose is completely unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description mentions 'hwid.get_top_users' and labels it as 'sensitive-read', but does not explain what 'top users' means or what the tool actually retrieves. It is vague and lacks a specific verb-resource clarification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool compared to many sibling user-related tools. No context on prerequisites or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool is a mutation, but no annotations are provided. It lacks details on side effects, authorization requirements, or effects on other data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but under-specified. It is not concise; it is incomplete. The two fragments provide minimal value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters with no schema coverage and no output schema, the description provides no context on how to use the tool, what the payload expects, or what happens on success.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the tool description adds nothing about parameters. The 'payload' parameter is a vague object with no guidance on its structure or purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description merely restates the tool name and notes it is a mutation, adding little beyond the title. It does not specify what 'reorder' means or what action is performed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like remnawave_external_squads_reorder. The context is completely missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description marks it as a read operation, implying no mutations, but provides no further behavioral details such as idempotency, authentication requirements, or whether it retrieves a single profile or multiple. Without annotations, more context is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, which is concise, but at the cost of omitting essential information needed for correct tool usage. It does not front-load key details; it simply restates the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters including nested objects, no output schema, and 0% schema coverage), the description is woefully incomplete. It fails to provide necessary context for an agent to correctly select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema includes four parameters (payload, confirmToken, responseMode, mutationApproved) with 0% description coverage. The description adds no explanation of what these parameters do, their defaults, or their intended use.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remnawave profiles.get (read)' indicates a read operation for profiles but is essentially a tautology of the tool name. It does not specify what profiles are or what the tool retrieves, offering no additional clarity beyond the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like remnawave_profiles_list or remnawave_profiles_get_computed. The description lacks any context for distinguishing usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only says 'read', which hints at non-destructive behavior, but no annotations are provided. It lacks details about authorization requirements, side effects (if any), pagination, or rate limits. With zero annotations, the description should compensate, but it barely does.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (5 words), but it sacrifices essential information for brevity. True conciseness would pack useful guidance without fluff; here, the under-specification makes it ineffective, not efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 params including a nested object, no output schema, 0% coverage), the description is woefully incomplete. There is no mention of what the list contains, how to filter, response format, or usage patterns. For a list operation, this leaves the agent with insufficient context to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has four parameters (payload, confirmToken, responseMode, mutationApproved) with 0% coverage (no descriptions). The description adds nothing about these parameters, leaving the agent unable to understand what payload means, why a confirmToken is needed, or how responseMode affects output. This is a critical gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remnawave snippets.list (read)' essentially restates the tool name and indicates it's a read operation. It does not specify what snippets are listed, what is returned, or any scope. This is a tautology with minimal added value, barely distinguishing it from siblings like remnawave_snippets_create.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. alternatives. Among siblings, there are multiple snippets tools (create, delete, update, list), but the description offers no context about use cases, prerequisites, or when listing is appropriate. The agent is left to guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The '(sensitive-read)' tag hints at a read operation accessing sensitive data, but no details are given about side effects, authentication needs, or data sensitivity. With no annotations, the description should provide more behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While very concise, the description is too minimal to be helpful. It does not earn its place because it adds no substantive information beyond the name. A good description would be longer and more informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has four parameters, no output schema, and no annotations, the description is gravely incomplete. It does not explain the function, expected input, or return value, leaving the agent unable to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention any of the four parameters (payload, confirmToken, responseMode, mutationApproved). With 0% schema coverage, the description fails to explain what these parameters mean or how to use them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a restatement of the tool name, adding only '(sensitive-read)'. It does not clarify what 'connection keys' are or the tool's specific action beyond the implicit 'get' from the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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 the many sibling subscription tools. There is no information about prerequisites, alternatives, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist. The description only says '(mutation)', implying state change, but fails to disclose whether keypairs are stored, returned, or if the operation is idempotent. No information about authorization, side effects, or safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is overly concise—one short sentence—but at the cost of required information. It is not well-structured for agent use.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 undocumented parameters, no output schema, and zero behavioral context, the description leaves agents unable to use the tool correctly. It is severely incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%. The description does not explain any of the four parameters (payload, confirmToken, responseMode, mutationApproved). Agents cannot infer their meaning or defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'generate keypairs', which indicates the verb and resource. However, it does not explain what X25519 keypairs are used for or what the tool returns. It is minimally clear but lacks context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The sibling list includes many other tools, but the description gives no context about prerequisites or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description labels the tool as '(read)', but the input schema includes 'mutationApproved' and 'confirmToken' parameters typical of mutation operations, creating a potential contradiction. No further behavioral traits are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (one line) but fails to adequately explain the tool's functionality. It is concise at the expense of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no parameter descriptions, and no annotations, the description is critically incomplete. The tool appears to accept a complex payload, yet no hints are provided about its structure or usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds no meaning to the four parameters (payload, confirmToken, responseMode, mutationApproved). The agent cannot infer how to use the payload object or the purpose of confirmToken.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description merely restates the tool name as 'Remnawave system.get_bandwidth_stats (read)' without specifying what bandwidth stats are retrieved (e.g., system-wide, aggregated). It does not differentiate from sibling tools like remnawave_bandwidth_stats_list_nodes_usage or remnawave_system_get_stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The '(read)' label hints at non-destructive behavior, but no annotations exist to confirm. The description does not disclose authentication needs, rate limits, or any other behavioral traits beyond the read hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief but lacks substantive content. It is under-specified rather than concise, failing to provide meaningful information in its single sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and 4 parameters including a nested object, the description is severely incomplete. It does not explain return values, error cases, or how the tool fits into the broader system.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds no explanations for the 4 parameters (payload, confirmToken, responseMode, mutationApproved). The 'payload' object and 'responseMode' enum remain undefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only repeats the tool name and adds '(read)', but does not specify what metrics are included (e.g., CPU, memory, traffic). It fails to differentiate from siblings like 'get_bandwidth_stats' or 'get_node_statistics'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'get_node_statistics' or 'get_health'. The description is silent on context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It only states 'read', implying non-destructive operation, but fails to disclose authorization needs, rate limits, response structure, or potential side effects. This is insufficient for an agent to understand the tool'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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief but fails to provide necessary information. It is under-specified rather than concisely informative. While short, it does not earn its place by adding value beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (four parameters, nested objects, no output schema) and lack of annotations, the description is completely inadequate. It provides no context about returns, parameters, or invariants, making it nearly unusable for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the four parameters (payload, confirmToken, responseMode, mutationApproved). The agent is left with no guidance on how to use these fields, especially since mutationApproved and confirmToken seem contradictory for a read operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description simply repeats the tool name and adds '(read)', which only indicates it's a read operation. It does not explain what a 'recap' is, leaving the purpose vague. Compared to siblings with clearer names like 'get_health' or 'get_stats', this tool's description provides no differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. There is no mention of context, prerequisites, or exclusions. The agent receives no hints about appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says 'mutation', which implies state change, but provides no details on what the mutation entails (e.g., required fields, side effects, idempotency). This is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief (one sentence) but fails to provide useful information. It is under-specified rather than conciseness; it wastes the opportunity to add value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has four parameters (including a flexible nested object), no output schema, and no annotations, the description is completely inadequate. It does not explain how to use the tool or what the result is.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does not mention any of the four parameters (payload, confirmToken, responseMode, mutationApproved) or their semantics. The payload object with additionalProperties is left completely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Remnawave users.create (mutation)', which indicates it creates a user. This is clear but lacks any specifics about the resource or operation. Among siblings, it is the only create tool, so it distinguishes itself, but barely.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives, or any prerequisites or exclusions. There are many sibling tools but the description does not differentiate usage contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must convey behavioral traits. It only notes 'sensitive-read', hinting at sensitivity but not explaining the role of confirmToken or mutationApproved for a read operation. Significant gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (one phrase) but lacks essential details. It is under-specification, not genuine conciseness, and provides no structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no output schema, and no annotations, the description fails to cover input or output semantics. It is wholly inadequate for an AI agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It does not: payload, confirmToken, responseMode, and mutationApproved are all unexplained, leaving the agent guessing their purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remnawave users.get (sensitive-read)' is nearly a tautology, restating the tool name. It does not differentiate this 'get' from sibling user getters like get_by_email, get_by_id, etc., leaving ambiguity about what identifier is expected.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description lacks any context for use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral traits. It hints at a sensitive read operation but does not disclose authentication needs, rate limits, side effects, or what data is returned. This is insufficient for an AI agent to understand the tool'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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but not concise—it lacks critical information. Conciseness should not sacrifice clarity; here it sacrifices everything.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 params, nested object, no output schema) and many siblings, the description fails to provide any contextual completeness. It does not explain return values, parameter usage, or prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description provides no explanation for any of the 4 parameters (payload, confirmToken, responseMode, mutationApproved). The payload object likely expects the short UUID but this is not clarified, leaving the agent confused.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remnawave users.get_by_short_uuid (sensitive-read)' is nearly a tautology of the tool name. It adds minimal context by labeling it 'sensitive-read' but fails to clearly state that the tool retrieves a user by their short UUID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool over sibling tools like remnawave_users_get_by_email, remnawave_users_get_by_id, etc. The description does not explain scenarios where short UUID lookup is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It only notes '(read)' implying a safe read, but lacks details on side effects, permissions, rate limits, or output format. This minimal disclosure is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but at the cost of under-specification. It does not earn its place by adding value; instead it omits critical information, making it insufficiently helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without output schema, annotations, or parameter details, the description leaves the tool's functionality largely undefined. It fails to cover basic aspects like what tags are returned or how the payload affects results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 4 parameters (including a nested object) with 0% description coverage. The description provides no additional meaning for any parameter, leaving the agent without guidance on how to use them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remnawave users.list_tags (read)' barely adds meaning beyond the tool name. It indicates a read operation but does not specify what tags are being listed or for which users, nor does it differentiate from siblings like 'remnawave_users_list' or 'remnawave_users_get_by_tag'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present. The description labels it as 'sensitive-read', hinting at read-only behavior and possible permissions, but provides no further details about side effects, return values, or authorization requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, which is concise, but it lacks structure and fails to front-load useful information. It is a single fragment that does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (4 parameters, enum, nested object) and the absence of annotations and output schema, the description is critically incomplete. It provides almost no context for successful invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not explain any of the four parameters (payload, confirmToken, responseMode, mutationApproved). The description adds no semantic value beyond the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description includes the API method name and labels it 'sensitive-read', but does not clearly state that it retrieves public subscriptions filtered by client type. It fails to differentiate from sibling tools like remnawave_public_subscriptions_get and remnawave_public_subscriptions_get_info, which are closely related.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, context, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description includes '(read)' suggesting a safe, read-only operation, but provides no further behavioral details such as authentication requirements, response format, or side effects. With no annotations, the description carries the full burden and falls short.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at one short line, but it sacrifices informativeness for brevity. While there is no wasted text, the lack of structure and essential information makes it only minimally acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and four undocumented parameters, the description is grossly incomplete. It fails to explain what the tool returns, how the payload should be structured, or any behavioral context, making it inadequate for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description offers no explanation of the four parameters (payload, confirmToken, responseMode, mutationApproved). The agent has no clue what these parameters do, severely hampering correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description essentially restates the tool name ('Remnawave system.get_metadata (read)') without clarifying what metadata is retrieved. It adds only the label '(read)' to indicate a read operation, but fails to distinguish this tool from other 'get' tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description does not mention any context, prerequisites, or exclusions, leaving the agent with no basis for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The only behavioral hint is '(read)', which is helpful but insufficient. Without annotations, the description should disclose more, such as whether the tool requires authentication, returns aggregated or raw data, or has side effects. It does not.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification, not conciseness. It fails to provide essential information and thus does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, nested payload object, no output schema), the description is completely inadequate. It does not explain what the tool returns, how to set parameters, or how it differs from siblings. It leaves the agent with almost no usable context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, meaning no parameter descriptions exist. The description adds no explanation for 'payload', 'confirmToken', 'responseMode', or 'mutationApproved'. The agent has no guidance on how to construct the payload or what the responseMode enum values mean.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a tautology: 'Remnawave bandwidth_stats.get_user_usage (read).' It states the tool's name and hints at a read operation but does not specify what data is retrieved (e.g., bandwidth usage for a specific user) or differentiate from similar siblings like get_node_users_usage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus sibling tools like remnawave_bandwidth_stats_get_node_users_usage or legacy variants. There is no context about prerequisites, filters, or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says '(read)', which hints at non-destructive operation, but doesn't explain the presence of 'confirmToken' and 'mutationApproved' parameters that typically imply write operations. No details on authentication, rate limits, or return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one sentence), but it is under-specified to the point of being unhelpful. Conciseness without substance is not effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no output schema, no annotations, and is part of a family of similar tools, the description fails completely to provide sufficient context for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides zero explanation of the four parameters (payload, confirmToken, responseMode, mutationApproved). An agent cannot understand their purpose or how to use them correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remnawave bandwidth_stats.list_nodes_usage (read)' is essentially a restatement of the tool name with '(read)' appended. It does not clarify what exactly is listed or how it differs from sibling tools like 'get_node_users_usage'. It lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus other bandwidth stats tools. An agent has no context to choose between 'list_nodes_usage' and 'get_node_users_usage' or other variants.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It only says 'mutation', which hints at destructive action, but fails to disclose reversible effects, authorization needs, or confirmation steps (despite schema fields like confirmToken and mutationApproved).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (single phrase), but it is under-specified and does not earn its place by providing useful information. It is not appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no annotations, no output schema, and a complex payload, the description is far from complete. An agent would lack essential guidance to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to the parameters. The agent gets no help understanding what to put in payload, confirmToken, responseMode, or mutationApproved.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies it as a delete operation for external squads, but does not specify what is being deleted (e.g., by ID). This is vague but not a tautology, and it distinguishes from other external_squads tools by stating 'delete'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus related tools like remnawave_external_squads_remove_users or when not to use it. The description lacks context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only notes '(read)', implying a non-destructive operation, but no annotations exist to confirm this. It provides no details about permissions, side effects, or required setup. Given the lack of annotations, the description carries the full burden and fails to inform adequately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, but its brevity comes at the cost of essential information. It is underspecified rather than concise, providing no value beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 undocumented parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain how to use the tool, what it returns, or any constraints, making it virtually unusable for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 4 parameters but the description explains none. With 0% schema description coverage, the agent lacks any guidance on what to pass, especially the 'payload' object which likely contains critical identifiers. The 'mutationApproved' field is confusing for a read operation and is not explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remnawave external_squads.get (read)' is a near-tautology of the tool name. While it adds the '(read)' hint, it does not specify what the tool retrieves or how it differs from siblings like 'list' or 'create'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'remnawave_external_squads_list' or other read tools. The agent has no context to choose appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must reveal behavioral traits. It only mentions 'mutation', but does not disclose side effects, required permissions, or whether changes are reversible. Fails to provide sufficient behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely short, but under-specified. It uses only 6 words, which is too little to convey necessary information. Conciseness should not come at the cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, one nested object, no output schema, and no annotations, the description is completely inadequate. It fails to provide essential context for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and description provides no information about parameters (payload, confirmToken, responseMode, mutationApproved). The description does not compensate for the missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description says 'Remnawave external_squads.reorder (mutation).' It identifies the resource and action as a mutation, but it fails to specify what reordering means (e.g., changing order of squads or users within squads). It barely adds value beyond the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. For example, it doesn't distinguish from external_squads_update or internal_squads_reorder. No context about prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only says 'mutation'. It does not disclose destructive behavior, confirmation requirements (confirmToken, mutationApproved), or any other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, but it lacks substantive content. Conciseness is sacrificed for completeness; it is too terse for a tool with 4 parameters and no schema descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters, nested objects, enum, no output schema), the description is utterly incomplete. It fails to explain the payload structure, confirmation flow, or response modes, making it insufficient for correct agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description adds zero parameter information. The 4 parameters (payload, confirmToken, responseMode, mutationApproved) are not explained, leaving the agent without guidance on how to use them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remnawave hosts.bulk_delete (mutation)' indicates a bulk delete operation on hosts, which is somewhat clear but not specific. It does not differentiate from the singular delete tool (remnawave_hosts_delete) or explain what exactly is deleted.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage context is provided. The description does not specify when to use this tool versus alternatives like remnawave_hosts_delete or other bulk operation tools, nor does it mention prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden but only states 'mutation'. It does not disclose whether the action is destructive, requires confirmation, or any side effects. The presence of confirmToken and mutationApproved in the schema hints at a confirmation step, but this is not explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is short, it is underspecified. It fails to convey essential information, making it ineffective rather than concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has four parameters, no output schema, and no annotations, the description is completely inadequate. It lacks any context on how to identify which device to delete or what the result of the mutation is.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no clarification for any of the four parameters. Critical details about payload, confirmToken, responseMode, and mutationApproved are missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description is nearly tautological, restating the tool name and noting it's a mutation. It does not clarify what 'hwid' means or distinguish this tool from siblings like remnawave_hwid_delete_all_devices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description only labels it as a mutation, leaving the agent to infer usage 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only labels the operation as 'sensitive-read' without explaining what is read, side effects, or constraints. This is insufficient for an agent to understand the tool'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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one line), but it sacrifices clarity for brevity. It fails to communicate essential information that justifies its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters, no annotations, no output schema), the description provides almost no contextual completeness. An agent cannot determine what the tool does, what inputs are needed, or what output to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema itself provides no parameter documentation. The description adds no information about the four parameters (payload, confirmToken, responseMode, mutationApproved), leaving the agent without any semantic guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is just the method name plus 'sensitive-read' label. It does not explicitly state what the tool does (retrieve user devices) and fails to distinguish it from siblings like remnawave_hwid_list_users or remnawave_hwid_get_top_users.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The 'sensitive-read' tag hints at authorization requirements but provides no explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It labels the tool as a mutation but does not disclose required permissions, side effects, or the confirmation process implied by confirmToken and mutationApproved parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but under-specified; it lacks essential details, so it is not effectively concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no output schema, and no annotations, the description is severely incomplete. It fails to explain the tool's purpose, input structure, or behavior, making it nearly unusable for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must explain parameters, but it says nothing about payload, confirmToken, responseMode, or mutationApproved, leaving the agent completely uninformed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description mentions 'infra_billing.create_node (mutation)', giving a verb and resource, but does not explain what a 'node' is in this context or how it differs from other billing operations, making it vague for an agent unfamiliar with Remnawave.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool over siblings like update_node or delete_node; no prerequisites or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says 'mutation', omitting important details like the need for confirmation tokens (confirmToken), mutation approval flags, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
At one sentence, the description is extremely short but lacks substance. It is under-specified rather than concisely informative, providing only the API path and type.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters, nested objects, no output schema, no annotations), the description is severely incomplete. It does not explain return values, parameter usage, or workflow requirements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not clarify any of the 4 parameters, including the crucial 'payload' object and 'confirmToken'. The agent receives no help beyond the schema structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remnawave infra_billing.update_node (mutation)' adds minimal context beyond the tool name. It indicates a mutation but does not specify what aspects of a billing node are updated or distinguish it from sibling tools like remnawave_nodes_update or remnawave_infra_billing_create_node.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, context, or any hints about selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present. The description only labels the tool as a mutation, implying state change, but does not disclose side effects, permissions, or what occurs on invocation. Minimal behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence) but under-specified. It sacrifices informativeness for brevity, making it insufficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 0% schema coverage, no annotations, and no output schema, the description completely fails to provide necessary context. The tool's behavior, parameters, and expected outcomes are entirely unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%; none of the 4 parameters (payload, confirmToken, responseMode, mutationApproved) are explained in the description. The agent has no guidance on what these parameters mean or their formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is minimal: 'Remnawave keygen.generate_node_secret (mutation).' It indicates it's a mutation but does not clearly state what the tool does beyond the name. It fails to specify that it generates a node secret, leaving purpose vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines provided. The description gives no context on when to use this tool versus other siblings, and no exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The only behavioral hint is '(mutation)', indicating state change. However, no details are given about side effects, destructive potential, or required permissions. With no annotations, the description fails to disclose crucial behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but lacks necessary detail, making it under-specified rather than concise. It does not earn its place as it provides almost no utility.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a bulk action tool with a nested payload, no output schema, and many sibling tools, the description is grossly incomplete. The agent cannot determine how to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description adds no explanation for any parameter (payload, confirmToken, responseMode, mutationApproved). The agent receives no help understanding what these parameters do.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only states 'Remnawave nodes.bulk_actions (mutation)', which vaguely indicates it performs bulk actions on nodes but lacks specificity about which actions (e.g., delete, disable, update). It barely distinguishes from sibling tools like nodes_bulk_update or nodes_disable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus individual node operations or other bulk tools. The description does not mention alternatives or conditions for use, forcing the agent to guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only labels the tool as a mutation, but without annotations, it fails to disclose critical behaviors such as irreversibility, required permissions, or side effects. The schema hints at confirmation tokens, but the description ignores these.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While very short, the description is under-specified rather than concise. It sacrifices necessary information, making it less useful than a slightly longer but informative description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 4 parameters, no output schema, and no annotations, the description fails almost entirely to explain what the tool does, how to use it, or what the outcome will be.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and no parameter descriptions in the tool description, the agent gains no understanding of what the 'payload', 'confirmToken', 'responseMode', or 'mutationApproved' parameters mean or how to use them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remnawave nodes.delete (mutation)' essentially restates the tool name, adding minimal clarity. It does not specify what a node is or what deletion entails, leaving the purpose vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like remnawave_nodes_disable or remnawave_nodes_bulk_actions. The description lacks any context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It only labels the operation as a mutation but provides no details on side effects, reversibility, required permissions, or response behavior. This is critically insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (one sentence fragment), which may appear concise but is actually underspecified. It fails to earn its place by omitting essential context, making it more detrimental than helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, nested objects, no output schema, and no annotations), the description is wholly inadequate. It does not explain the tool's purpose, behavior, or parameter semantics, leaving a significant gap for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description gives no information about the four parameters (payload, confirmToken, responseMode, mutationApproved). The agent has no understanding of what payload expects, confirming tokens, or response modes. This severely hinders correct parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as a mutation for reordering nodes, which distinguishes it from other node actions. However, it does not specify what 'reorder' entails (e.g., ordering priorities, sorting criteria, or context). It is minimally clear but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not indicate when to use this tool, what prerequisites exist, or how it differs from other reorder tools (e.g., remnawave_hosts_reorder). The agent has no context for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Only states it's a mutation; does not disclose destructive behavior, auth needs, or the confirmation mechanism implied by confirmToken and mutationApproved parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely brief but omits essential information; under-specification rather than concise completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Fails to cover a complex tool with 4 params, a confirmation mechanism, and no output schema; description is wholly inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and description adds no meaning to the 4 parameters; payload, confirmToken, responseMode, mutationApproved are entirely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description restates the tool name ('Remnawave profiles.delete (mutation)') without adding any new information or distinguishing from sibling tools like remnawave_profiles_create or remnawave_profiles_update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this mutation versus alternatives; no mention of prerequisites or confirmation requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states it is a 'read' operation, implying no side effects. However, with no annotations, it fails to disclose any other behavioral traits such as authentication requirements, rate limits, or response characteristics. The single word 'read' is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is due to underspecification rather than effective conciseness. It lacks structure and fails to convey essential information, making it unhelpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, annotations, and parameter descriptions, the description is completely inadequate. A tool with 4 parameters (including a nested object) and many siblings requires far more detail to be usable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the four parameters (payload, confirmToken, responseMode, mutationApproved). The agent has no guidance on how to use the payload object or the meaning of the enums.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description merely restates the tool name with the suffix '(read)', providing no additional context. It does not clarify what 'inbounds' are or how this tool differs from the sibling 'remnawave_profiles_list_inbounds', leaving purpose ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives (e.g., 'remnawave_profiles_list_inbounds' or other profile tools). There is no mention of context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral disclosure. It only states '(read)', implying a safe read operation, but fails to disclose any traits like required permissions, idempotency, or side effects. The minimal hint is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is short, it is under-specified rather than concise. Every word is present but adds little value. The parenthetical '(read)' is a minimal hint, but overall the description fails to convey essential information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, including a nested object and an enum, and no output schema, the description is severely incomplete. It does not explain the tool's purpose, parameter semantics, or expected behavior, leaving the agent with insufficient context to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description adds no explanation for the 4 parameters (payload, confirmToken, responseMode, mutationApproved). It does not clarify what values the 'payload' object expects, the role of 'confirmToken', or the effect of 'responseMode'. The agent is left guessing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remnawave profiles.list_inbounds (read)' essentially restates the tool name with a parenthetical hint. It does not specify what 'inbounds' are or the tool's scope (e.g., lists all inbounds globally or for a profile). This is vague and borders on tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The sibling tool 'remnawave_profiles_list_all_inbounds' suggests a different scope, but the description does not differentiate when to use one vs. the other. There are no cues about prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description only labels the tool as a mutation, but fails to disclose any behavioral traits such as required permissions, side effects, or action details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but lacks essential details, making it under-specified rather than appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 0% parameter coverage, the description fails to provide sufficient context for the tool's operation, inputs, or expected outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 4 parameters with 0% description coverage, and the description adds no information about the parameters or their purpose, leaving the agent completely in the dark.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remnawave profiles.reorder (mutation)' essentially restates the tool name and marks it as a mutation, but does not clarify what reordering entails (e.g., reordering a list of profiles). It barely adds value beyond the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like node reorder or squad reorder. The description offers no context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only labels the operation as 'sensitive-read,' which hints at permissions but does not explain side effects, rate limits, or whether a mutationApproved parameter indicates potential write behavior in certain modes. This is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence, 13 words), which is typically a positive for conciseness, but it lacks essential information. It cannot be considered well-structured when it communicates almost nothing about the tool's purpose or usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations, output schema, and schema descriptions, the description is severely incomplete. It fails to explain return values, parameter semantics, or behavior details. The tool's complexity (4 parameters, one with enum, sensitive-read context) demands much more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the four parameters (payload, confirmToken, responseMode, mutationApproved). The presence of mutationApproved is confusing for a 'get' operation and requires clarification. The description adds no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool is for 'public_subscriptions.get' and labels it as 'sensitive-read,' but it does not specify what the tool actually retrieves or how it differs from closely related siblings like remnawave_public_subscriptions_get_by_client_type and remnawave_public_subscriptions_get_info. The purpose remains vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There are no exclusions, prerequisites, or comparisons to sibling tools. The description offers no context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description only labels it as a mutation, implying it changes data, but lacks details on what changes, required permissions, side effects, or return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one sentence), but it is under-specified and fails to convey useful information. Conciseness without substance is not effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, high parameter count (4), nested objects, and many sibling tools, the description is severely incomplete. It does not help the agent understand the tool's role or how to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description provides no information about the four parameters (payload, confirmToken, responseMode, mutationApproved). The schema itself lacks descriptions, so the agent has no guidance on parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says "subscription_settings.update (mutation)", which indicates a mutation to update subscription settings. However, it doesn't specify what subscription settings are or what exactly gets updated, leaving ambiguity. It's slightly more than a tautology but still vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Sibling tools include 'remnawave_subscription_settings_get' and many subscription-related tools, but no when-to-use or when-not instructions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. '(sensitive-read)' hints at read-only sensitivity but provides no details on error behavior, data scope, or side effects. Bare minimum.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely brief but at the cost of useful information. Every word should add value; here, the description is a mere restatement of the name with a one-word qualifier.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and a 0% schema description coverage, the description is critically incomplete. It fails to clarify what the tool returns, how to use the payload, or the role of confirmToken and responseMode.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description does not explain any of the 4 parameters (payload, confirmToken, responseMode, mutationApproved). Agents receive zero guidance on how to populate these fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description almost tautologically restates the tool name with '(sensitive-read)' added. It does not explicitly state that it retrieves subscription info by username, nor what specific data is returned. Sibling tools like get_by_uuid and get_by_short_uuid are not distinguished.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternative subscription retrieval tools (e.g., by UUID). No prerequisites or context for invoking are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It labels the operation as a mutation, but does not disclose side effects, authorization needs, rate limits, or what data is affected. This is insufficient for safe agent decision-making.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it is under-specified rather than concisely informative. Every sentence should earn its place; this one adds negligible value beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, nested object payload, no output schema), the description is completely inadequate. It fails to explain return values, required nesting, or the overall workflow, leaving the agent severely underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to the four parameters. The agent receives no hints about 'payload' content, 'confirmToken' purpose, or how 'responseMode' and 'mutationApproved' behave. This severely hampers correct parameter filling.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a tautology: it restates the tool name and notes it's a mutation, but does not specify what 'templates' are or what 'create' accomplishes. It fails to distinguish from sibling template tools like remnawave_templates_delete or remnawave_templates_update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any prerequisites or context. The agent is left without direction for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description labels the tool as a 'mutation', indicating state change, but provides no further behavioral details such as required permissions, side effects, or implications of parameters like confirmToken and mutationApproved. With no annotations, the description carries the full disclosure burden but fails to deliver.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is very short (6 words), it is under-specified rather than concise. It lacks essential details about the tool's operation, making it insufficient for an agent to select or invoke correctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters including a nested payload object, no output schema) and the absence of annotations, the description is drastically incomplete. It does not explain what templates are, how to construct the payload, or how to use the safety parameters, leaving critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds no meaning to any of the 4 parameters. The payload object, confirmToken, responseMode, and mutationApproved are entirely unexplained, leaving the agent to guess their roles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remnawave templates.update (mutation)' merely restates the tool name with a parenthetical 'mutation'. It does not specify what templates are, what updating entails, or distinguish this from sibling tools like remnawave_templates_create or remnawave_templates_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. Sibling tools include create, delete, list, get, and reorder, but the description offers no context for choosing update over them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent; the description only labels it a 'mutation' but fails to disclose destructive behavior, safety mechanisms (confirmToken, mutationApproved), or consequences. Critical transparency is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While extremely brief, the description is under-specified—it sacrifices essential content for brevity. A single sentence that adds no functional value is not effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a bulk deletion tool (with safety parameters and no output schema), the description provides virtually no context. Return values, prerequisites, and behavior are entirely absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and no parameter descriptions in the description, the agent receives no meaning for payload, confirmToken, responseMode, or mutationApproved. Entirely reliant on schema structure alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remnawave users.bulk_delete (mutation)' essentially restates the tool name with 'mutation' clarification. It does not specify what users are deleted or provide any actionable purpose 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. alternatives like remnawave_users_delete or remnawave_users_bulk_delete_by_status. The description lacks any context about intended use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. The tag '(sensitive-read)' hints at a read operation with sensitive data but lacks details on authentication, permissions, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While concise, the description is under-specified for a tool with nested objects and multiple parameters. It fails to earn its place by providing necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters including nested object and enum, no output schema, no annotations), the description is completely inadequate for correct agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description does not explain any of the four parameters (payload, confirmToken, responseMode, mutationApproved), leaving the agent without guidance on how to use them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is almost a tautology, restating the tool name with a vague tag '(sensitive-read)'. It does not explain what nodes are being retrieved or what 'accessible' means, offering minimal clarity beyond the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Among many sibling 'get' tools, there is no differentiation or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only says 'sensitive-read', which is a broad hint but lacks details on side effects, return format, authorization level, or rate limits. For a tool with 4 parameters and no output schema, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise but at the expense of essential information. It is one sentence that adds no value beyond the name, making it under-specified rather than efficiently informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters, nested object, no output schema) and lack of annotations, the description is severely incomplete. It fails to explain the tool's purpose, how to use parameters, or what defines 'sensitive-read'. The agent cannot confidently invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the tool description offers zero explanation of the parameters (payload, confirmToken, responseMode, mutationApproved). The agent has no way to understand what 'payload' expects or how 'mutationApproved' relates to a read operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remnawave users.get_subscription_request_history (sensitive-read)' essentially restates the tool name and adds a vague label. It does not specify what the tool retrieves (e.g., history for which user, scope of data) or differentiate it from sibling tools like 'remnawave_subscription_request_history_list' or 'remnawave_subscription_request_history_get_stats'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 vs alternatives, no prerequisites or context provided. The 'sensitive-read' label hints at authorization but is not explicit about usage constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only labels the tool as a 'mutation' but fails to disclose side effects like whether the subscription link is invalidated, if it affects user status, or if it is reversible. The presence of confirmToken and mutationApproved parameters hints at required approval, but this is not explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one line), but it sacrifices essential information. It is not well-structured; a tool description should be concise yet informative. This is under-specification, not effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and zero parameter descriptions, the tool description is critically incomplete. An AI agent lacks sufficient context to select or correctly invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about any of the four parameters (payload, confirmToken, responseMode, mutationApproved). The agent cannot infer their meaning or usage from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it is a 'mutation' and the name suggests revoking a subscription, but it does not specify what revoking entails (e.g., disabling access, removing subscription URL). Compared to siblings like remnawave_users_disable, the purpose is ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as remnawave_users_bulk_revoke_subscription or remnawave_users_disable. There is no context on prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only labels the tool as a 'mutation', but without annotations, it fails to disclose important behaviors such as whether updates are destructive, if confirmation is required, or what the scope of changes is.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but at the expense of being useless. It fails to convey necessary information, making it an under-specification rather than a concise summary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters including a loosely-typed payload, no output schema, and zero documentation), the description is woefully incomplete. An agent cannot determine how to construct a valid request or what to expect in return.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of the parameters. The payload object's structure is undefined, and none of the four parameters are described, leaving the agent without guidance on how to invoke the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'hosts.update (mutation)', which identifies the verb (update) and resource (hosts), but it lacks specificity about what aspects of hosts are updated and how it differs from sibling tools like remnawave_hosts_bulk_update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not indicate when to use this tool versus its siblings, nor does it mention any prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states 'mutation', which hints at state change but does not disclose potential impacts like service disruption, required permissions, rate limits, or whether the operation is reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (6 words), which is concise but severely under-specified. It lacks substance to be considered efficient; it is incomplete rather than concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters, nested object, no output schema) and lack of annotations, the description is far from complete. It does not explain the purpose of parameters or the effect of the mutation, leaving the agent without enough context to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (none of the 4 parameters have descriptions in the schema). The description provides zero information about parameters. It does not explain 'payload', 'confirmToken', 'responseMode', or 'mutationApproved', which are critical for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remnawave nodes.restart_all (mutation)' is essentially a tautology of the tool name, adding only the label 'mutation'. It lacks a clear verb+resource statement like 'Restarts all nodes'. It minimally distinguishes from siblings like 'remnawave_nodes_restart' by implying 'all', but does not explicitly state the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No information on when to use this tool versus alternatives like 'remnawave_nodes_restart' (single node) or 'remnawave_nodes_disable'/'remnawave_nodes_enable'. No exclusions, prerequisites, or context about when this operation is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description offers a hint about sensitivity and read-only nature via '(sensitive-read)', but with no annotations, it fails to disclose behavior such as authentication requirements, idempotency, or side effects. The payload and confirmToken parameters are unexplained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one line), which is concise but sacrifices meaningful content. It does not earn its place by adding value beyond the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool complexity (4 parameters, no schema descriptions, no output schema, many sibling tools), the description is woefully incomplete. It lacks essential information for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no explanation for the four parameters (payload, confirmToken, responseMode, mutationApproved). The agent cannot infer how to specify the Telegram ID or interpret the other fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only repeats the function name and adds '(sensitive-read)', which hints at a read operation but does not explicitly state that this tool retrieves a user by Telegram ID. It distinguishes minimally from siblings but lacks a clear verb+resource statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like get_by_email, get_by_username, etc. The agent must infer usage solely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states '(read)', implying no side effects, but offers no details on behavior such as pagination, filtering, or response structure. Without annotations, this is insufficient for an agent to understand the tool's effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, but conciseness sacrifices necessary detail. It is under-specified rather than efficiently informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and minimal description, the tool definition is incomplete. An agent would lack critical information to use it correctly, such as what the tool returns and how to structure requests.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description provides no explanation of parameters. Schema coverage is 0%, so the agent must infer meaning solely from parameter names and types, which is insufficient for parameters like 'payload' and 'confirmToken'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description indicates it's a read operation for node users usage, which gives a basic sense of purpose. However, it largely repeats the tool name and lacks specificity on what data is retrieved, making it only marginally clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 siblings like 'get_node_user_usage_legacy' or 'get_user_usage'. The description provides no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only labels it as a 'mutation' but does not disclose behavioral traits like required permissions, reversibility, side effects, or what the mutationApproved parameter implies. With no annotations, the description fails to provide sufficient behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is short (one sentence), it is under-specified and sacrifices informative content for brevity. It does not earn its place as it repeats the tool name without adding value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters including a nested payload, no annotations, and no output schema, the description is severely incomplete. It fails to explain what external squads are, what the update does, or how to use the parameters correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no information about the parameters. With 0% schema description coverage, the agent has no guidance on what the payload, confirmToken, responseMode, or mutationApproved fields mean beyond their types and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it is a mutation (update) on external squads, which distinguishes it from create, delete, get, etc. However, it does not explain what external squads are or what updating entails beyond the verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like create or delete. There is no context about prerequisites or scenarios for updating external squads.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full behavioral disclosure. It only states 'read' but does not explain if it requires an identifier, any side effects, authentication needs, or rate limits. Insufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely short but under-specified. Every word is present but it does not earn its place; key information is missing. Not a model of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, nested objects, no output schema, and 0% schema description coverage, the description provides zero contextual completeness. The agent has no idea what the tool does beyond a vague 'read', what it returns, or how to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% with 4 parameters, including 'mutationApproved' and 'confirmToken' which imply mutation despite 'read' claim. Description adds no meaning to any parameter, leaving the agent blind to required inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remnawave hosts.get (read)' indicates a read operation for hosts, but does not specify what a host is or differentiate from sibling tools like list. It is minimally clear but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., remnawave_hosts_list, remnawave_hosts_list_tags). The description provides no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Only labels the tool as 'mutation' but does not describe side effects, permissions, or what reordering actually changes. Annotations are absent, so the description fails to compensate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but sacrifices necessary information. While front-loaded, it is under-specified for a mutation tool with 4 parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Highly incomplete: does not explain how to reorder, what the payload should contain, the role of confirmToken and mutationApproved, or the return value. No output schema provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description provides no information about parameters (payload, confirmToken, responseMode, mutationApproved). The description adds no value beyond the schema's empty definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'hosts.reorder (mutation)', which indicates it reorders hosts, but does not clarify what 'reorder' entails or how it differs from other reorder tools like remnawave_nodes_reorder. The verb and resource are present but vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., remnawave_hosts_update). No mention of prerequisites or context for reordering hosts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only adds '(read)' hinting it is safe. It does not disclose behavior on missing provider, authentication needs, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief but under-informative. It fails to provide necessary context, making it more of a placeholder than a useful description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, nested objects, and no output schema, this description is critically incomplete. An agent has virtually no understanding of how to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no information about the 4 parameters, including the confusing 'mutationApproved' for a read operation. An agent cannot infer parameter purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it is a read operation for getting a provider, but does not specify if it retrieves a single provider by ID or any other scope. It distinguishes from siblings only by the verb 'get' versus 'list', 'create', etc., but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like list_providers, or prerequisites. The description is purely a label with no contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a '(read)' hint but fails to disclose pagination, filtering, permissions, or other behavioral traits. No annotations are provided to compensate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely brief (7 words) but at the expense of substance. The description under-informs for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, nested objects, no output schema, and no annotations, the description is grossly incomplete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 4 parameters including nested objects, the description provides no explanation of any parameter, leaving all semantics to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it lists providers and is a read operation, but it essentially restates the tool name with minimal addition. It does not differentiate from sibling billing tools like list_history or list_nodes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives or prerequisites. The description offers no context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only notes 'mutation', implying write operations, but provides no details on side effects, required permissions, or whether the action is reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but sacrifices necessary detail. It is under-specified, not meaningfully concise, and fails to front-load essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 4 parameters including a nested payload, no output schema, and no annotations, the description is grossly incomplete. It provides no information about expected inputs or results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description adds no meaning for any of the four parameters (payload, confirmToken, responseMode, mutationApproved), which are left entirely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'add_users' and labels it as a mutation, which gives a basic verb+resource but lacks specificity about which entity is being added to (implied squads). The description does not differentiate from sibling tools like remnawave_internal_squads_remove_users.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 remnawave_external_squads_add_users or other squad-related mutations. No prerequisites or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only labels the tool as a 'mutation', hinting at a write operation but omitting details like authentication needs, side effects, or status of the created squad. The minimal label is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
At one sentence, the description is too brief given the tool has 4 parameters, including a nested object. It under-specifies key details and does not earn its place; conciseness should not come at the expense of necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, 4 parameters (one complex object), and zero annotations. The description provides no information about return values, payload structure, or the effect of parameters, making the description completely inadequate for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description offers no explanation of any parameter (payload, confirmToken, responseMode, mutationApproved). It fails to add meaning beyond the schema, leaving the agent without guidance on parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'internal_squads.create (mutation)', which identifies the verb (create) and resource (internal_squads). It distinguishes from sibling tools by name, but lacks any detail on what an internal squad is or what creation entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like remnawave_internal_squads_add_users or external_squads_create. The description does not offer any context on prerequisites or use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description does not disclose behavioral traits beyond labeling it a 'mutation'. It omits details like whether deletion is permanent, if confirmation is required, or what happens to related data. The term 'mutation' is generic and insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief but under-specifies critical information. It does not earn its place; it essentially repeats the tool name with added '(mutation)'. A longer description with essential details would improve usability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, including a nested 'payload' object and boolean flags, and no output schema, the description is completely inadequate. An agent cannot understand how to construct a valid request or what to expect in response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 4 parameters with 0% description coverage, yet the description adds no meaning to any parameter. Parameters like payload, confirmToken, and mutationApproved remain unexplained, leaving the agent unable to determine how to invoke the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it is a mutation for deleting internal squads, which aligns with the tool name and distinguishes it from external squads. However, it does not specify what identifier is used to select which squad to delete (e.g., by ID or name), leaving purpose slightly vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like remnawave_internal_squads_list, remnawave_internal_squads_create, or the external squad deletion tool. The description fails to provide any context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Only mentions 'read', implying non-destructive behavior, but no annotations provided. No details on permissions, side effects, or return behavior. For a tool with no annotations, the description should offer more transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise but under-specified. A single line does not provide sufficient information to be useful. Not a model of efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, 4 parameters none described, and a vague purpose, the description is highly incomplete for a tool with this complexity and sibling count.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the 4 parameters (payload, confirmToken, responseMode, mutationApproved). The description adds no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it is a 'read' operation for 'internal_squads.get', which implies retrieving a specific squad. However, it does not clarify what an internal squad is, and the description is minimal. It distinguishes from sibling list and create tools, but could be more specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like list or create. The description does not specify the purpose or context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It only says '(read)', implying no modifications. It does not explain unusual parameters like confirmToken and mutationApproved, nor does it mention authorization, pagination, or output format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence), but it is under-specified. Conciseness should not come at the cost of completeness; vital information about parameters and behavior is missing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters (one nested object), no output schema, and no annotations, the description is completely inadequate. It does not describe return values, prerequisites, or how to construct the payload, leaving the agent unable to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention any parameters. The four parameters (payload, confirmToken, responseMode, mutationApproved) are left entirely unexplained, leaving the agent without critical guidance on their meaning or usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Remnawave internal_squads.list (read)', indicating it is a read operation to list internal squads. However, it lacks context about what internal squads are and does not differentiate clearly from sibling tools like remnawave_internal_squads_get or remnawave_external_squads_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. Sibling tools include both list and get operations for internal and external squads, but there is no mention of use cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description only labels it a mutation, with no details on side effects, required permissions, or whether it is destructive beyond the mutation label.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise but at the cost of informativeness. The description is minimal and fails to provide value beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation with 4 parameters including a nested object and no output schema or annotations, the description is severely incomplete. Agent has no information to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not explain any of the 4 parameters, including the crucial 'payload' object. No guidance on what fields or structure payload expects.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'create (mutation)', which identifies the operation and resource, but lacks specifics about what creating a node entails. It does not differentiate from sibling tools like update or delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like nodes_update or nodes_delete. No context on prerequisites or typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description only labels the tool as a 'mutation'. It fails to disclose required permissions, side effects, or what the response will be.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but under-specified. It fails to convey necessary information, making it insufficient rather than concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with multiple parameters and no output schema, the description is severely incomplete. It omits essential context such as prerequisites, effects, and parameter usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no explanation for any of the 4 parameters, including the nested 'payload' object and others.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'enable' and resource 'nodes', making the basic purpose clear. However, it does not provide scope or differentiate from sibling tools like 'remnawave_nodes_disable'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The agent must infer from the name alone, which is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Only states 'read' implying non-destructive, but no details on authentication requirements, error behavior, or side effects. With no annotations, the description fails to provide adequate behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise but to the point of being unhelpful. A single sentence that adds little value beyond the tool name and a vague 'read' indicator.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no output schema, 0% schema coverage, and many siblings, the description is grossly incomplete. It does not explain what the tool returns, how to specify which node, or how parameters work.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no clarification for any of the 4 parameters (payload, confirmToken, responseMode, mutationApproved). The presence of mutationApproved with default false for a read operation is confusing and unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description says 'nodes.get (read)' which indicates it's a read operation for nodes, but does not specify if it retrieves a single node by identifier or all nodes. It is somewhat vague and does not clearly differentiate from remnawave_nodes_list, which likely lists all nodes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance provided. There is no mention of when to use this tool versus sibling tools like remnawave_nodes_list, remnawave_nodes_create, etc.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description only labels the tool as a mutation, but does not disclose side effects, required permissions, or confirmation steps, despite the schema having parameters for confirmation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one sentence), but it is too sparse to be effective. Conciseness should not come at the expense of clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, no annotations, and four undocumented parameters, the description is woefully incomplete. The agent cannot safely or effectively invoke this tool without external documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, yet the description offers no explanation for the four parameters (payload, confirmToken, responseMode, mutationApproved). The agent receives no help understanding what each parameter does.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as a mutation to reset traffic for nodes, but it is vague about what exactly is reset (e.g., traffic counters) and lacks specifics to distinguish it from sibling tools like 'remnawave_users_reset_traffic'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like node disabling or deleting. The description does not mention prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states 'mutation', but does not describe side effects, permissions required, idempotency, or return behavior. This is insufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one short sentence), but it sacrifices clarity and completeness. While efficient, it does not earn its place because it omits essential information that the agent needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, nested object, enum, no output schema), the description is wholly inadequate. It does not explain the payload structure, the purpose of confirmToken, or the effect of mutationApproved, making it impossible for an agent to use correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds zero parameter information. The four parameters (payload, confirmToken, responseMode, mutationApproved) are completely undocumented in the description, leaving the agent without guidance on how to use them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remnawave nodes.update (mutation)' indicates the tool updates nodes and is a mutation, which is more than a tautology. However, it lacks specificity about what a node is or what updating entails, and does not clearly distinguish it from sibling tools like create or delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Neither prerequisites, nor conditions for use, nor exclusions are provided. The label '(mutation)' hints that it's a write operation, but that's insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavioral traits. It only notes it's a 'mutation' but fails to describe side effects, permissions, or what gets modified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is short (one sentence), it is under-specified and provides nearly no useful information, making it a case of under-specification rather than effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters, no output schema, no annotations, and the description offers no completeness. It fails to convey how the tool should be invoked or what happens afterward.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 4 parameters with 0% description coverage. The description adds no meaning beyond the schema, leaving the AI agent without guidance on how to use 'payload', 'confirmToken', 'responseMode', or 'mutationApproved'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Remnawave profiles.update (mutation)', identifying the resource (profiles) and action (update), but it is extremely terse and does not distinguish from sibling tools like create, delete, or reorder.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, conditions, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The 'sensitive-read' label hints at special permissions but does not explain further. No annotations are present, so the description carries the full burden of behavioral disclosure, which it fails to meet.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, which sacrifices necessary detail. It is under-specified rather than appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With four undocumented parameters, no annotations, and no output schema, the description is entirely insufficient for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description provides no explanation for any of the four parameters (payload, confirmToken, responseMode, mutationApproved). The agent cannot determine how to use these parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as getting info on public subscriptions, and notes it is a sensitive read. However, it does not specify what information is returned or how it differs from sibling tools like remnawave_public_subscriptions_get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus its siblings. The description lacks context about when it is appropriate to use or any alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only says 'mutation' but provides no details on behavioral traits like required permissions, side effects, or what happens on update. With no annotations, the description carries full burden and is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While short, the description is under-specified and fails to provide useful information. It is not concise in an informative sense; it is simply minimal and vague.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters including a nested object and no output schema, the description is severely incomplete. An agent cannot correctly determine how to call this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no information about parameters. The agent gets no help understanding what 'payload', 'confirmToken', 'responseMode', or 'mutationApproved' mean or how to use them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it is an update mutation for snippets, but it is generic and does not specify what aspects of snippets are updated nor distinguish from sibling tools like create or delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as remnawave_snippets_create or remnawave_snippets_delete. No prerequisites or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description labels the operation as a 'mutation' but offers no further disclosure about side effects, required permissions, or what gets cloned. With no annotations, the description carries the full burden, but it fails to specify behavioral traits beyond the label.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise but at the expense of informativeness. It is a single sentence that adds minimal value, lacking necessary details. True conciseness would include essential information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, a complex payload, no output schema, and no annotations, the description is severely incomplete. It fails to provide enough information for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of the four parameters (payload, confirmToken, responseMode, mutationApproved). The payload is a complex object with no guidance, and the other parameters' semantics are entirely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it is a clone operation on subscription page configs, identifying the specific action and resource. However, it does not explain what 'clone' entails (e.g., duplicating an existing config, creating a new config based on a template), which is vague and barely distinct from sibling tools like 'create'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, typical use cases, or when not to use it, leaving the agent without context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description minimally states it's a read operation, implying no state changes. However, it fails to describe any other behavioral traits such as required permissions, return format, or side effects. The term 'read' is the only transparency provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one sentence), but it is under-specified. For a tool with four parameters and no schema descriptions, it lacks essential information to be considered concise yet complete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, no annotations, and no parameter explanations. Given the complexity of the sibling toolset and the tool's own parameters, the description is insufficient for an agent to understand how to correctly invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the four parameters (payload, confirmToken, responseMode, mutationApproved). The agent receives no semantic help beyond the schema field names and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description indicates it is a read operation for subscription page configs, which is clear but minimal. It essentially restates the name with '(read)', providing basic purpose but lacking specific detail like what is retrieved or how it differs from list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. alternatives like list, create, update, or delete. The description does not mention prerequisites, context, or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description notes the tool is read-only, which is the only behavioral cue. Without annotations, this is insufficient: no information on authentication requirements, rate limits, side effects, or scope of the returned data. The agent is left to infer behavior from the tool name and parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but at the expense of necessary detail. It lacks structure and fails to convey critical information that would fit in a few more sentences. Conciseness should not come at the cost of utility.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters, nested object, no output schema), the description is woefully incomplete. It provides no return format, behavior details, or parameter explanations. The agent would struggle to use this tool correctly without external documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about the four parameters: payload, confirmToken, responseMode, mutationApproved. The agent cannot correctly set these without additional knowledge. The parameter names hint at functionality but are not explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'list' and '(read)', clearly indicating a read operation to list subscription request history. However, it does not specify the scope (e.g., global, per user, per subscription), and it is almost redundant with the tool name. This provides basic clarity but lacks precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'remnawave_subscription_request_history_get_stats' or 'remnawave_users_get_subscription_request_history'. The description omits context for when-not-to-use and does not mention prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description includes the word 'read' implying no side effects, but with no annotations, the description should disclose more behavioral details. It does not mention whether authentication is required, rate limits, or any other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one line) but at the expense of necessary detail. It is under-specification rather than efficient conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given four parameters, no output schema, and many sibling tools, the description is entirely inadequate. It provides no information about return values, parameter usage, or the nature of subscription settings, leaving a significant gap for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to any of the four parameters (payload, confirmToken, responseMode, mutationApproved). The schema itself lacks descriptions; the description does not compensate, leaving an agent with no guidance on how to fill the input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool retrieves subscription settings (subscription_settings.get) and notes it is a read operation, but does not specify what constitutes subscription settings or differentiate it from other 'get' tools for subscription or other resources. The name is clearer than the description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as the sibling tool 'remnawave_subscription_settings_update' or other subscription-related get tools. The description does not mention prerequisites or context of use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It adds "sensitive-read" suggesting sensitivity and read-only nature, but does not disclose required permissions, rate limits, or what exactly is sensitive (e.g., user data exposure). The behavioral traits are insufficiently described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but it is under-specified rather than concise. It lacks necessary detail, making it unhelpful for an AI agent. Front-loading is irrelevant because there is almost no content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, 4 undocumented parameters, no annotations, and a complex context with many sibling tools, the description is severely incomplete. It fails to provide sufficient information for correct tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema provides no parameter descriptions. The description also fails to explain any of the 4 parameters (payload, confirmToken, responseMode, mutationApproved). The agent has no way to know what each parameter does or what values to provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states "subscriptions.get_by_short_uuid" which implies retrieving a subscription by short UUID, but it doesn't explicitly state what information is returned. The parenthetical "sensitive-read" adds some context but is still vague. It distinguishes from siblings like get_by_username or get_by_uuid by identifier, but lacks detailed purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Siblings include other subscription retrieval methods (by username, UUID, raw, subpage config), but the description provides no comparison or usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The label '(sensitive-read)' suggests caution but does not elaborate on required permissions, data returned, or side effects. With zero annotations, the description should disclose more about the sensitivity and scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief but not effectively concise; it omits crucial information. It should be expanded to cover essential usage details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no output schema, and complex sibling tools, the description fails to provide adequate context. The agent lacks guidance on how to construct requests and interpret responses.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description provides no explanation for parameters like payload, confirmToken, responseMode, or mutationApproved. The presence of confirmToken and mutationApproved on a list operation is unexplained and potentially confusing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'subscriptions.list (sensitive-read)', indicating a listing action on subscriptions and hints at safety level. However, it lacks specificity on what is being listed (e.g., all subscriptions, filtered by criteria) and does not differentiate from 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_by_* or list from different contexts (users, profiles). The description does not mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates it is a read operation, but with no annotations, it fails to disclose other behavioral traits such as authentication requirements, rate limits, or potential side effects. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely brief, but the brevity omits essential details. A longer description is needed for a tool with 4 parameters and no output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no description of return values, the agent cannot understand what the tool provides. The description is inadequate for this 4-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no information about parameters like 'payload', 'confirmToken', or 'responseMode'. The tool's purpose is unclear regarding how parameters affect behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as retrieving node statistics (read), which is a clear verb-resource pair. However, it does not specify which nodes or what type of statistics, making it less specific than optimal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 siblings like 'remnawave_system_get_stats' or 'remnawave_system_get_nodes_metrics'. The description provides no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only states '(read)', implying read-only behavior, but lacks details on authentication, rate limits, or any side effects. Does not disclose that the tool may not be purely read-only given the mutationApproved parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely short but under-specified. The single sentence does not earn its place; it lacks essential details for a 4-parameter tool. Not concise in a helpful sense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and 4 parameters with 0% schema coverage, the description is severely incomplete. It does not explain what the tool returns or the role of the parameters, leaving an agent with insufficient context to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and description provides no information on parameters. The parameters 'payload', 'confirmToken', 'responseMode', and 'mutationApproved' are unexplained. The presence of 'mutationApproved' contradicts the read-only hint, causing confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description mentions verb 'get' and resource 'stats', but 'stats' is vague and does not specify what system statistics are retrieved. It distinguishes from siblings only by being a 'system' tool, but there are other system tools like get_bandwidth_stats, get_health, etc., so purpose is not clearly differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. Only '(read)' hints at non-mutating use, but no context on prerequisites, scenarios, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It only hints at sensitivity with '(sensitive-read)' but does not disclose side effects, rate limits, pagination, or result format. This is insufficient for safe and effective use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise but at the cost of completeness. A single fragment 'Remnawave users.list (sensitive-read)' is insufficient to convey purpose, usage, or parameters. It is under-specified, not efficiently concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and the tool's complexity (4 parameters, one nested object), the description is wholly inadequate. It does not explain the return value, required parameters, or behavior, making it nearly useless for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds no meaning to any of the four parameters (payload, confirmToken, responseMode, mutationApproved). The payload object is especially cryptic. The agent cannot infer valid inputs from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'users.list (sensitive-read)' indicates a list operation but is vague. It doesn't specify what entities are listed or any scope, though it distinguishes from individual retrieval tools. Sibling tools like remnawave_users_get_by_* clarify it's a bulk list, but the description lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. There are many specific retrieval tools (by email, id, etc.) and bulk operations, but the description provides no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description alone must disclose behavioral traits. 'Sensitive-read' hints at read-only and security implications but does not explain what the payload, confirmToken, or mutationApproved do, nor whether the tool has side effects or requires authentication.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one sentence) but is under-specified. Conciseness should come without sacrificing essential information; here, vital details are missing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters, nested object, no output schema, no annotations), the description is far from complete. It does not mention return value, error handling, or how the tool processes the payload.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no information about the four parameters (payload, confirmToken, responseMode, mutationApproved). Since schema description coverage is 0%, the agent has no clues about parameter usage or valid values beyond the limited enum.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remnawave users.resolve (sensitive-read)' identifies the tool as a user resolution operation and flags it as sensitive and read-only, but does not specify what exactly is being resolved (conflicts? tokens? IDs?). This vagueness does not distinguish it well from sibling tools like users_get or users_get_by_id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this vs. alternatives. The description lacks any 'when to use', 'when not to use', or references to sibling tools, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as idempotency, side effects, authentication needs, or rate limits. The user is left unaware of whether the operation is read-only or has other implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but fails to provide adequate information. It sacrifices clarity for brevity, as the sentence does not explain the behavior or constraints sufficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only two parameters and no output schema, the description is incomplete. It does not describe the expected output format, error conditions, or typical usage scenarios, making it insufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only mentions 'for a domain and operation' without explaining what values these parameters accept (e.g., format, restrictions, examples). No enums or additional context are provided, leaving the agent to guess.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns upstream remnawave_api schema/details for a domain and operation. It provides a specific verb ('Return') and resource ('schema/details'). However, it does not differentiate from similar tools like 'remnawave_discover' which may also return API details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. There is no mention of prerequisites, context, or exclusions. The description is a simple statement without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description labels it as a 'mutation', but provides no details on side effects, required permissions, reversibility, or the two-step confirmation process implied by 'confirmToken' and 'mutationApproved' parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, but it sacrifices all meaningful content. It is a single phrase that adds no value, making it under-specified rather than efficiently informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, a nested payload object, and no output schema, the description is wholly inadequate. It fails to explain the return value, usage context, or any details beyond the name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It adds nothing about the payload structure, confirmToken purpose, responseMode options, or mutationApproved usage. Completely unhelpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'create' and resource 'provider', which conveys a basic creation action. However, it does not define what a provider is in this billing context, so the purpose is vague and only marginally better than the tool name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'remnawave_infra_billing_update_provider' or 'remnawave_infra_billing_get_provider'. No context on prerequisites or appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims 'read', but the input schema includes parameters like mutationApproved and confirmToken typically associated with mutations, not reads. This contradiction undermines transparency. No annotations are provided to clarify safety or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is short, it sacrifices critical information. It fails to earn its place by omitting necessary details about behavior, parameters, or return values. A single vague sentence is not effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should explain the return format or at least the scope of nodes listed. It does not. With many sibling list tools, the description should differentiate, but it does not. The tool is incomplete for its purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no information about parameters. The four parameters (payload, confirmToken, responseMode, mutationApproved) remain unexplained, forcing the agent to guess their meaning and usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Remnawave infra_billing.list_nodes (read)', clearly indicating a list operation for nodes in the infra_billing context. It uses a specific verb and resource, but lacks differentiation from sibling list tools like list_providers or list_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. The agent must rely on the tool name alone, which is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden but only says 'mutation'. It does not disclose whether deletion is irreversible, if confirmation is needed, or what side effects occur (e.g., cascading deletions). This is insufficient for safe use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one line) but lacks structure and substance. While concise, it sacrifices critical information, making it minimally helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters, nested payload, no output schema), the description is severely incomplete. It fails to specify what gets deleted, how to identify the target, or what the response looks like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description fails to explain any of the 4 parameters. The payload object is left completely undefined, and confirmToken, responseMode, mutationApproved are not described, leaving the agent without essential usage context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'subscription_page_configs.delete (mutation)' which clearly indicates it deletes subscription page configs. The name reinforces this purpose, making it distinct from siblings like create, update, and get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., update or disable). There is no mention of prerequisites, such as requiring a confirmToken or ensuring a config exists before deletion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description labels the tool as 'sensitive-read', but the input schema includes parameters like 'confirmToken' and 'mutationApproved', which are atypical for a read operation and suggest possible mutation or confirmation flow. No explanation is given for these parameters or the behavioral characteristics beyond the label. Annotations are missing, so the description carries full burden but fails to provide adequate transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a single line. However, it is too terse and omits critical details, making it under-specification rather than efficient conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters with no descriptions, no output schema, and many sibling tools for subscription retrieval, the description is grossly incomplete. It provides no information on how to use the tool, what the response contains, or how it differs from similar tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 4 parameters with 0% schema description coverage. The description does not explain any of the parameters (payload, confirmToken, responseMode, mutationApproved), leaving their purpose and usage entirely unspecified. This severely hinders the agent's ability to correctly invoke the tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'subscriptions.get_by_uuid (sensitive-read)', which indicates it retrieves a subscription by UUID and is a sensitive operation. However, it does not explain what a subscription is or what the UUID represents. It minimally distinguishes from siblings via the name but lacks clarity on the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this tool versus siblings like remnawave_subscriptions_get_by_short_uuid or remnawave_subscriptions_get_by_username. The description does not specify prerequisites or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description includes '(sensitive-read)' which hints at permissions or data sensitivity, but no annotations exist. It fails to disclose other behavioral traits such as idempotency, side effects, or authorization requirements, which are critical given the lack of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at one sentence, but it sacrifices information density. While it is front-loaded, the lack of structure and detail makes it minimally adequate for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, no output schema, sensitive-read category), the description is severely incomplete. It does not explain return values, parameter usage, or how to invoke the tool, leaving the agent without essential context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description adds no information about any of the four parameters. The agent cannot understand the role of 'payload,' 'confirmToken,' 'responseMode,' or 'mutationApproved' from the description alone, leaving a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'users.get_by_tag (sensitive-read),' indicating a read operation by tag and marking sensitivity. However, it does not explain what 'by tag' means or what the tool retrieves, making the purpose somewhat vague. It distinguishes from siblings like get_by_email but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With many sibling user retrieval tools (e.g., get_by_email, get_by_username), the absence of selection criteria leaves the agent without direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description only labels it as a 'mutation', implying change, but does not disclose behavioral traits like destructiveness, idempotency, or the need for confirmation. The schema parameters suggest a two-step confirmation, which is unmentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely short (one sentence), but lacks structure. No separation of purpose, usage, or parameter details. It is under-specified, not concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters (including a nested object), no output schema, and no parameter descriptions, the single-sentence description is grossly inadequate for an agent to correctly invoke the tool. Missing explanation of confirmation flow and payload structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 4 parameters with 0% description coverage. Description adds no information about parameters: payload, confirmToken, responseMode, mutationApproved. Agent gets no guidance on what payload should contain or how confirmation works.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'snippets.delete (mutation)', clearly indicating a delete operation for snippets. However, it is vague; does not specify what is deleted (e.g., snippet ID) or how deletion is identified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. Does not mention prerequisites, safety, or that it requires confirmation parameters (confirmToken, mutationApproved).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description only adds 'sensitive-read', which hints at permissions but does not disclose concrete behavior (e.g., whether it is idempotent, what happens if config doesn't exist). The burden is on the description, and it falls short.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (18 words), but brevity does not compensate for lack of substance. It is not well-structured for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no output schema, and many sibling tools, the description fails to provide sufficient context. The agent lacks understanding of the tool's purpose, inputs, and expected output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description provides zero explanation of any of the 4 parameters (payload, confirmToken, responseMode, mutationApproved). The agent cannot infer how to use them correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description repeats the tool name and adds '(sensitive-read)' but does not clarify what a 'subpage config' is or what the tool retrieves. It is marginally better than a tautology but still vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. siblings like get_by_short_uuid, get_raw_by_short_uuid, or other subscription config tools. The agent is left to guess the distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description only says '(read)', hinting at idempotence, but does not explain other behavioral traits like authentication needs or the role of parameters like mutationApproved.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely short (5 words) but under-specified. It lacks essential information that should be present for a tool with 4 parameters and no schema descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 4 parameters and no output schema, the description provides no explanation of inputs or return values. The tool is not usable based on description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description adds no meaning to any of the 4 parameters (payload, confirmToken, responseMode, mutationApproved). The description fails to clarify their purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists external squads (read operation), distinguishing from sibling create/delete/update tools. However, it lacks specificity on what exactly is listed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this vs alternative sibling tools like remnawave_external_squads_get. Does not mention context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It indicates the tool is read-only, which is good. However, it fails to explain why parameters like 'confirmToken' and 'mutationApproved' exist, which could confuse an agent. No details about pagination, sorting, or side effects are given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (5 words) and lacks structure. While brevity can be a virtue, here it omits critical information, making it under-specified rather than concise. Important details about parameters and usage are missing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of 4 parameters, no output schema, and many sibling tools, the description is severely incomplete. It does not explain the return format, any prerequisites, or how the parameters affect the listing. The agent cannot safely use this tool based solely on the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage and 4 parameters with unclear roles (payload, confirmToken, responseMode, mutationApproved). The description adds no semantic information about these parameters, leaving the agent without any guidance on how to use them correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a list operation ('hosts.list') and specifies it is a read operation. This sufficiently distinguishes it from write operations like create or update. However, it does not elaborate on what exactly is listed (all hosts, filtered?) or differentiate from other list tools like 'list_tags'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus siblings such as 'remnawave_hosts_get' (single host) or 'remnawave_hosts_list_tags'. There are no explicit context cues, alternative recommendations, or exclusions, leaving the agent to guess the appropriate use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It only states 'read', implying no destructive effects, but does not disclose any behavioral traits such as required permissions, rate limits, or side effects. The description is insufficient for the agent to understand the tool'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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence) but lacks structure and essential details. It is under-specified, not truly concise in the sense of efficient communication of necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no output schema, and no annotations, the description is severely incomplete. It fails to explain the parameter payload, the difference between normalized and raw responseMode, the purpose of confirmToken and mutationApproved, or what the output contains. The agent cannot reliably use this tool based solely on the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no information about the 4 parameters (payload, confirmToken, responseMode, mutationApproved). The agent must infer meaning from parameter names defaults, which is insufficient. For example, 'mutationApproved' on a read tool is misleading without explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action 'list_tags' on resource 'hosts' and indicates it is a read operation. This clearly distinguishes it from sibling tools like remnawave_hosts_list (list hosts) and remnawave_nodes_list_tags (list tags for nodes). However, it does not specify what tags are or the output format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description only mentions it is a read operation, with no context on prerequisites, typical use cases, or when it should be avoided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only indicates a read operation, but lacks details on behavior such as pagination, limits, sorting, or what data is returned. For a list tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but it is under-specified. It sacrifices necessary information for brevity, making it less helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of 4 parameters (including a nested object) and no output schema, the description fails to provide essential context about how to use the tool, what it returns, or its role among sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain any of the 4 parameters (payload, confirmToken, responseMode, mutationApproved). With 0% schema description coverage, the description entirely fails to add meaning beyond the schema fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a list operation on profiles (verb 'list', resource 'profiles') and specifies it is a read-only action. However, it does not differentiate from sibling tools like get or list_all_inbounds.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., get, create, delete). No context about filtering, pagination, or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only indicates it is a mutation, which implies modifications occur. No annotations are provided, and the description does not elaborate on behavioral traits such as prerequisites, side effects, or required permissions. For a mutation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one line), which could be considered concise, but it is under-specified to the point of being uninformative. It does not earn its place as it provides almost no useful information beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, no output schema, no annotations), the description is completely inadequate. It leaves the agent without essential information about what the payload should contain, the purpose of confirmToken, responseMode options, or mutation approval logic.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention any of the four parameters (payload, confirmToken, responseMode, mutationApproved). It adds no meaning beyond what the schema provides, failing to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'update (mutation)' which clearly indicates the tool performs an update operation on subscription page configs, providing a specific verb and resource. However, it does not differentiate from sibling tools like create, delete, clone, or reorder, so it is not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There are many sibling tools for subscription page configs (create, delete, clone, reorder), but the description offers no context on when an update is appropriate or how it differs from those.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The only behavioral trait mentioned is 'read', which implies no side effects. With no annotations, the description should disclose more, such as required permissions, whether payload is needed for identifying a template, or response format. It fails to do so.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but lacks substantive information. It is under-specific rather than concise, failing to earn its place with useful details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 0% schema coverage, no annotations, no output schema, and four parameters, the description is severely incomplete. It does not explain what 'templates' are, how to specify which template to get, or what the tool returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the four parameters (payload, confirmToken, responseMode, mutationApproved). Their purpose and usage remain entirely unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Remnawave templates.get (read)', clearly identifying the action (get) and resource (templates), and indicating read-only behavior. It distinguishes from sibling tools like create/delete/list by implying retrieval of a single template, though not explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as remnawave_templates_list or remnawave_templates_get (if other get variants exist). There are no prerequisites or context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only notes this is a read operation, but does not explain the presence of mutationApproved or responseMode parameters, pagination, filtering, or security requirements. The inclusion of a mutation-related parameter in a read tool is confusing and not clarified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is very concise, it is under-specified. It fails to include necessary details about parameters, usage, or output, making it insufficient for an agent to use correctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 4 parameters with 0% schema coverage, no output schema, and no annotations, the description is grossly incomplete. It does not explain what the tool returns, how to customize the request, or any usage context, leaving the agent with almost no useful information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameters. It does not mention payload, confirmToken, responseMode, or mutationApproved, leaving their purpose entirely unclear for a list operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remnawave templates.list (read)' clearly states the verb 'list' and the resource 'templates', and indicates a read operation. This distinguishes it from sibling tools like create, delete, and get. However, the phrasing 'templates.list' is somewhat unusual, preventing a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as remnawave_templates_get or other list tools. There is no context for when listing is appropriate or what distinguishes this from similar operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The tag 'sensitive-read' hints at special access requirements but does not elaborate on security implications, side effects, or other behavioral traits. With no annotations, the description fails to provide sufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (one sentence) but lacks necessary information, making it under-specified rather than appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (four parameters, no output schema, many siblings), the description is dramatically incomplete. It does not explain input structure, return values, or how to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description omits any explanation of the four input parameters, including the opaque payload object. The agent cannot determine how to specify the username or use other fields like confirmToken or responseMode.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'users.get_by_username (sensitive-read)', which clearly identifies the tool as retrieving a user by username. Among siblings with multiple get-by-identifier tools, this distinguishes itself by indicating the lookup key.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like users_get_by_email or users_get_by_id. The description lacks any context on preferred use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavior. It only labels the tool as a 'mutation,' indicating state change, but provides no details on required permissions, side effects, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence), but severely under-specified for a tool with four parameters and no schema descriptions. This is not effective conciseness; it is minimalism that harms usability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (mutation with a free-form `payload` object and approval mechanism) and the lack of annotations and output schema, the description is wholly inadequate. It fails to explain how to construct inputs, what the tool returns, or how it integrates with other tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, meaning no parameter descriptions exist, and the description adds no information about the four parameters (`payload`, `confirmToken`, `responseMode`, `mutationApproved`). The agent has no guidance on how to use these parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Remnawave users.update (mutation)', clearly indicating it updates users. This distinguishes it from read-only tools, but it does not differentiate from sibling tools like `remnawave_users_bulk_update` without additional context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines provided. The description does not specify when to use this tool versus alternatives like `remnawave_users_bulk_update` or `remnawave_users_create`, nor does it mention prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates the tool is read-only via '(read)' but lacks other behavioral details such as pagination, authentication requirements, or potential side effects. With no annotations, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence) and front-loaded, but it sacrifices substance. While brevity is appreciated, it fails to provide necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, incomplete schema descriptions, and no output schema, the description is severely lacking. It does not explain what the tool returns, how to construct a proper request, or any constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning to any of the 4 parameters, despite 0% schema description coverage. Parameters like 'payload' and 'confirmToken' remain unexplained, leaving the agent without guidance on how to use them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remnawave infra_billing.list_history (read)' clearly identifies the tool as a read operation to list history records. It distinguishes it from sibling tools that perform create, delete, or update operations on billing entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus other listing tools (e.g., list_nodes, list_providers). There is no mention of prerequisites, context, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It only states '(read)', implying non-destructiveness, but omits details like authentication needs, error handling, or what happens if the user does not exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one sentence) and front-loaded with the tool's name and read nature. However, it sacrifices necessary detail for conciseness, leaving critical gaps.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and 4 parameters with nested objects and enums, the description is severely incomplete. It does not address return values, payload structure, or usage context, leaving the agent without essential information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description provides no explanation of parameters like 'payload', 'confirmToken', 'responseMode', or 'mutationApproved'. The agent lacks any semantic guidance for these fields, making correct invocation unlikely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Describes tool as 'metadata.get_user' with '(read)' indication, clearly specifying it retrieves user metadata. However, it does not differentiate from sibling tools like remnawave_users_get or remnawave_metadata_get_node, missing explicit distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as remnawave_users_get or remnawave_metadata_get_node. The description lacks context on prerequisites or scenarios, providing no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. Only '(read)' is stated, implying safety but offering no details about side effects, rate limits, permissions, or what the response contains. The 'read' label is insufficient for a complete behavioral profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one sentence), which is concise but lacks important details. It earns a mid score because while it is not verbose, it fails to provide enough information to be useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has four parameters, no output schema, no annotations, and many sibling tools, the description is severely incomplete. It does not explain what subscription page configs are, what the list returns, how to use the parameters, or how this tool relates to other subscription_page_configs tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description adds no meaning to the four parameters (payload, confirmToken, responseMode, mutationApproved). Without any explanation of their purpose or valid values (except responseMode's enum), the agent cannot infer proper usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'list (read)', clearly indicating it is a read operation to list subscription page configs. This distinguishes it from siblings like 'get' (single retrieval) and 'create'/'delete'/'update' (mutations). However, it does not specify the scope (e.g., all configs or filtered) or provide any additional context, so it is clear but minimal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, there is no mention of when to list all configs versus getting a specific one, or any prerequisites or context. The description solely repeats the tool name and action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states '(read)', implying no side effects, but fails to disclose auth needs, rate limits, or any behavioral details. The presence of mutation-related parameters (mutationApproved, confirmToken) is unexplained, creating ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence), which is concise but sacrifices completeness. It front-loads the resource name, but the single sentence does not earn its place due to lack of useful detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, no schema descriptions, no annotations, no output schema), the description is severely incomplete. It fails to explain the purpose of any parameter, the output format, or how to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no information about the four parameters (payload, confirmToken, responseMode, mutationApproved). Without explanation, the agent cannot determine how to use them correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remnawave subscription_request_history.get_stats (read)' clearly identifies the resource (stats of subscription request history) and indicates a read operation. It distinguishes from the sibling 'remnawave_subscription_request_history_list' by focusing on stats, but does not specify what stats are included.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives like remnawave_subscription_request_history_list or other stats endpoints. The description lacks context for appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden of disclosing behavior. It only labels the operation 'sensitive-read' but does not explain what makes it sensitive, any required permissions, or side effects. It fails to clarify whether the tool is read-only or what the output contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single line—which is efficient but comes at the cost of missing critical information. It front-loads purpose and sensitivity but does not earn its place due to under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters, nested objects, no output schema, no annotations), the description is entirely inadequate. It does not explain how to use the tool, what the response looks like, or how it differs from numerous similar subscription tools. The agent would have insufficient context to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate but offers no explanation of the four parameters (payload, confirmToken, responseMode, mutationApproved). The short UUID input mechanism is unclear, and the meaning of 'raw' vs 'normalized' response mode is not described.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as retrieving raw subscription data by short UUID, and the 'sensitive-read' tag hints at its nature. This clearly distinguishes it from siblings that use other identifiers or return non-raw data. However, it lacks specificity about what 'raw' entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like remnawave_subscriptions_get_by_short_uuid or similar subscriptions methods. No prerequisites, context, or exclusion criteria are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral transparency. It merely states '(read)' but omits details about authentication needs, rate limits, side effects, or return format. The tool likely performs a safe read, but this is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one phrase), but this brevity sacrifices necessary detail. For a health check tool with multiple parameters and no output schema, it is under-specified. A well-structured description would add parameter guidance or expected output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of output schema, complex nested parameters, and no annotations, the description is grossly incomplete. It fails to explain the purpose of each parameter, the response structure, or any behavioral traits, leaving the agent with insufficient information for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention any of the 4 parameters (payload, confirmToken, responseMode, mutationApproved). The meaning of these parameters, especially responseMode or mutationApproved, is not explained, leaving the agent without guidance on how to invoke the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remnawave system.get_health (read)' clearly indicates this is a read-only health check tool. The verb 'get' and resource 'health' are specific, and it distinguishes from other system tools like get_bandwidth_stats or get_metadata by naming the endpoint explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. No context about prerequisites, when not to use it, or comparison to sibling tools like remnawave_system_get_stats or remnawave_system_get_recap is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the operation is a 'sensitive-read,' hinting at read-only behavior with sensitivity, but no annotations are present to confirm. It fails to explain what triggers sensitivity, authorization needs, or side effects. The parameter mutationApproved suggests possible mutation, which is not clarified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (two words plus label), which is concise but at the expense of conveying essential information. It does not waste words, but also does not earn its place by providing enough detail for an agent to use the tool correctly. A minimally adequate description would be longer.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has four parameters (including a nested object), no output schema, and no annotations, the description is far from complete. It does not explain how to construct the call, what the return data looks like, or any prerequisites. An agent cannot reliably use this tool with only the current description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no information about any of the four parameters. With 0% schema description coverage, the agent receives no guidance on payload, confirmToken, responseMode, or mutationApproved. The description entirely fails to add meaning beyond the schema field names and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool retrieves a user by email, making the purpose clear. However, it does not differentiate from sibling tools like remnawave_users_get_by_username or remnawave_users_get_by_id. The '(sensitive-read)' tag adds useful context but is insufficient for full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidelines are provided on when to use this tool versus other user retrieval tools. There are no explicit when-to-use or when-not-to-use instructions, and alternatives are not mentioned. The agent is left guessing based on the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description mentions 'mutation' but does not disclose side effects, such as whether traffic counters are zeroed, or that confirmation may be required (indicated by confirmToken and mutationApproved in schema). No annotations to supplement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, very short, not verbose. However, it is under-specified and lacks structure, making it minimally helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no output schema, and no annotations, the description is inadequate. It does not cover confirmation requirements, payload structure, or return behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 4 parameters with 0% description coverage. The description does not explain any parameter, leaving the agent to infer from names like payload, confirmToken, responseMode, mutationApproved.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'users.reset_traffic (mutation)', indicating it resets traffic for users. However, it lacks specificity about what exactly is reset and does not differentiate from sibling tools like remnawave_users_bulk_reset_traffic or remnawave_nodes_reset_traffic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. There are multiple similar tools for bulk operations, and the description provides no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly notes '(read)', indicating no side effects and safe repetition. While annotations are absent, this basic behavioral disclosure is sufficient. However, it lacks details on response format or potential errors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, which is concise, but it omits important details that could be added without significant length. It lacks structure such as parameter explanations or usage examples.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and minimal description, the tool is incomplete. The description does not explain what metadata is returned, how parameters affect behavior, or how it relates to other node-related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must explain parameters. It does not mention any of the four parameters (payload, confirmToken, responseMode, mutationApproved), leaving their purposes entirely undefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'metadata.get_node (read)' clearly indicates a read operation to get node metadata. It uses a specific verb ('get') and resource ('node metadata'), and distinguishes from siblings like 'remnawave_metadata_upsert_node' (write) and 'remnawave_metadata_get_user' (different resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'remnawave_nodes_get' or 'remnawave_metadata_upsert_node'. No context on prerequisites or when read is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description labels it a 'mutation' but provides no details on side effects, required permissions, or consequences (e.g., cascading deletions). With no annotations, the agent must infer behavior from the name alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the resource and action. Every word is necessary with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema and 0% parameter coverage, the description does not explain how to identify the provider, what the deletion returns, or whether it is reversible. This leaves significant gaps for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
None of the 4 parameters (payload, confirmToken, responseMode, mutationApproved) are described in the schema or description. The agent receives no guidance on how to populate the payload object or use the confirmation flow.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'delete' and the resource 'provider' within the infra billing context, distinguishing it from siblings like create or list. However, it does not specify what identifies the provider (e.g., ID) or the scope of deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'remnawave_infra_billing_update_provider' or 'remnawave_infra_billing_list_providers'. The description lacks any context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full weight. It explicitly states it is a list operation and returns specific fields, which is adequate for a simple read-only tool. However, it does not disclose any potential side effects or restrictions beyond what is stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-formed sentence that front-loads the verb and resource. It contains no wasted words and is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no annotations, and no output schema, the description is sufficiently complete. It fully answers what the tool does and what it returns, which is all an agent needs to decide to call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so baseline is 4. The description adds meaning by specifying the content of the list (domain, operation, local safety class), which compensates for the lack of schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List', the resource 'all Remnawave flat tools', and specifies the output fields: domain, operation, and local safety class. It distinguishes itself from sibling tools which are individual CRUD operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is a discovery tool to get an overview of available tools. It does not explicitly state when to use or not use alternatives, but the purpose is clear enough for an agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![remnawave-tools-mcp MCP server](https://glama.ai/mcp/servers/eloktev/remnawave-tools-mcp/badges/card.svg)](https://glama.ai/mcp/servers/eloktev/remnawave-tools-mcp)

Score Badge

Copy to your README.md:

[![remnawave-tools-mcp MCP server](https://glama.ai/mcp/servers/eloktev/remnawave-tools-mcp/badges/score.svg)](https://glama.ai/mcp/servers/eloktev/remnawave-tools-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/eloktev/remnawave-tools-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server