Liara MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
The tools are generally well-differentiated by resource type (app, database, VM, etc.) and action (create, get, list, delete), with clear boundaries. However, some overlap exists, such as liara_set_env_var and liara_set_env_vars for single vs. multiple variables, which could cause minor confusion. Overall, the distinct purposes are clear, but a few similar pairs might require careful selection.
Naming Consistency5/5
All tool names follow a consistent liara_verb_noun pattern, using snake_case throughout. The verbs are predictable (e.g., create, get, list, delete, update, set) and align well with the actions. This uniformity makes the tool set easy to navigate and understand at a glance.
Tool Count2/5
With 100 tools, the count is excessive for an MCP server, likely overwhelming for agents and users. While the server covers a broad domain (cloud platform management), the high number suggests over-fragmentation or redundancy, such as separate tools for single and multiple environment variables. A more consolidated approach would improve usability.
Completeness5/5
The tool set provides comprehensive coverage for managing a cloud platform, including CRUD operations for apps, databases, VMs, storage, DNS, and more. It supports full lifecycles with create, read, update, delete, list, and action tools (e.g., start, stop, restart), leaving no obvious gaps for the inferred domain.
Average 2.9/5 across 100 of 100 tools scored. Lowest: 1.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 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 provided, the description carries full burden for behavioral disclosure but offers none. It doesn't mention whether this is a safe operation, if it requires specific permissions, potential side effects (e.g., service interruption, billing implications), rate limits, or what happens on success/failure. 'Start' implies a state change but lacks crucial operational 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 technically concise with only three words, this is under-specification rather than effective brevity. The description fails to provide necessary information that would help an agent understand and use the tool correctly. Every word should earn its place, but here the description is too sparse 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?
For a tool that performs a state-changing operation (starting a service) with no annotations and no output schema, the description is completely inadequate. It doesn't explain what 'starting' means operationally, what the expected outcome is, error conditions, or how this differs from related operations. The agent lacks essential context to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage (mailId parameter is clearly documented), so the baseline is 3. The description adds no additional parameter information beyond what the schema already provides—it doesn't explain what a mail server ID represents, where to find it, or format requirements.
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 'Start a mail server' is a tautology that essentially restates the tool name 'liara_start_mail_server'. While it identifies the resource (mail server) and verb (start), it lacks specificity about what 'starting' entails operationally and doesn't differentiate from sibling tools like 'liara_restart_mail_server' or 'liara_stop_mail_server'.
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 provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites (e.g., the mail server must exist and be stopped), comparison to restart operations, or what scenarios warrant starting versus creating a new mail server. The agent receives zero contextual direction.
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 of behavioral disclosure. 'Create a new app' implies a write operation that likely mutates state, but it fails to describe critical traits: whether it requires specific permissions, what happens on success (e.g., app deployment, resource allocation), potential side effects (e.g., billing implications), or error conditions. This lack of information is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just three words, making it front-loaded and waste-free. However, this brevity borders on under-specification, as it sacrifices necessary detail for clarity and completeness. While efficient, it lacks the depth needed for effective tool use, slightly reducing its utility despite the clean structure.
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 tool's complexity (a mutation operation with 4 parameters, no annotations, and no output schema), the description is incomplete. It does not cover behavioral aspects like what the tool returns (e.g., app ID, status), error handling, or dependencies (e.g., needing a valid planID). For a creation tool in a rich sibling set, this minimal description fails to provide sufficient context for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with clear descriptions for all parameters (e.g., name format, platform enum, planID, optional region). The description adds no parameter semantics beyond what the schema provides—it does not explain relationships between parameters (e.g., how platform affects deployment) or usage tips. Given the high schema coverage, a baseline score of 3 is appropriate, as the schema handles the documentation burden adequately.
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 'Create a new app' is a tautology that merely restates the tool name 'liara_create_app'. It specifies the verb ('Create') and resource ('app'), but does not differentiate from siblings like 'liara_create_database' or 'liara_create_vm'—it lacks details on what an 'app' entails in this context (e.g., a web application, containerized service). This minimal statement fails to provide meaningful distinction or clarity beyond the obvious.
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 provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., needing a plan or platform selection), exclusions (e.g., when not to create an app), or comparisons to sibling tools like 'liara_list_apps' for checking existing apps. This absence leaves the agent without context for decision-making, risking incorrect or redundant invocations.
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 full burden but only states 'Create a DNS record', implying a write operation without details on permissions, side effects, rate limits, or response format. It lacks behavioral context like whether creation is idempotent or what happens on conflicts, making it 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It is front-loaded and appropriately sized for its minimal content, earning full marks for conciseness despite lacking depth.
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?
For a mutation tool with 6 parameters, no annotations, and no output schema, the description is incomplete. It fails to address behavioral aspects, usage context, or output expectations, leaving significant gaps that hinder the agent's ability to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented in the schema. The description adds no additional meaning beyond the schema, such as explaining parameter interactions or examples. Baseline score of 3 reflects adequate schema coverage without extra value from the description.
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 'Create a DNS record' restates the tool name with minimal elaboration, making it tautological. It specifies the verb 'Create' and resource 'DNS record', but lacks detail on scope or differentiation from siblings like liara_update_dns_record or liara_delete_dns_record, leaving purpose vague beyond the obvious.
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 does not mention prerequisites, context, or exclusions, such as needing an existing zone or how it differs from liara_update_dns_record. This absence leaves the agent 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Create a new disk', implying a write operation, but doesn't disclose critical traits like whether this requires specific permissions, if it's idempotent, what happens on failure, or if it affects app availability. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: 'Create a new disk for an app'. It's front-loaded with the core action and resource, with zero wasted words. However, it could be slightly more informative without losing conciseness, e.g., by hinting at the disk's purpose (storage).
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 of a creation tool with 4 required parameters, no annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects (e.g., side effects, error handling), usage context, or what to expect upon success (e.g., returns a disk ID). For a tool that likely modifies infrastructure, more detail is needed to guide an agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with each parameter clearly documented (e.g., 'Disk size in GB'). The description adds no additional meaning beyond the schema, such as explaining relationships between parameters (e.g., mountPath must be unique) or constraints (e.g., size limits). Given the high schema coverage, a baseline score of 3 is appropriate as the description doesn't compensate but doesn't detract either.
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 'Create a new disk for an app' states a clear verb ('Create') and resource ('disk'), but it's vague about what a 'disk' entails in this context (e.g., storage volume, virtual disk) and doesn't distinguish it from sibling tools like 'liara_create_bucket' or 'liara_create_snapshot', which might involve similar creation actions for different resources. It provides basic purpose but lacks specificity and 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 guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., app must exist), exclusions (e.g., not for modifying existing disks), or related tools like 'liara_resize_disk' or 'liara_delete_disk'. Without such context, an agent might struggle to select this tool appropriately among many creation-related siblings.
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 full burden for behavioral disclosure. 'Create a new mail server' implies a write/mutation operation, but it doesn't describe what happens after creation (e.g., does it return the server ID, is it immediately active, what permissions are needed, are there rate limits, or what happens if creation fails?). This leaves significant behavioral gaps for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just four words, which is appropriately sized for a simple creation tool. It's front-loaded with the core action and resource, though it could potentially benefit from one more clarifying phrase. There's no wasted language, making it efficient.
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?
For a creation tool with no annotations and no output schema, the description is inadequate. It doesn't explain what the tool returns, what happens on success/failure, or any behavioral context. Given the complexity of creating infrastructure resources and the lack of structured metadata, the description should provide more complete operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all four parameters (name, mode, planID, domain) with descriptions and required status. The description adds no additional parameter information beyond what's in the schema, so it meets the baseline of 3 where the schema does the heavy lifting.
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 'Create a new mail server' clearly states the action (create) and resource (mail server), but it's vague about what a 'mail server' entails in this context and doesn't distinguish it from similar creation tools like liara_create_app or liara_create_database. It provides basic purpose but lacks specificity about the type of resource being created.
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 about when to use this tool versus alternatives. The description doesn't mention prerequisites, dependencies, or how this creation differs from other creation tools in the sibling list. There's no indication of when this should be used instead of other mail-related tools like liara_send_email or liara_list_mail_servers.
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 for behavioral disclosure. 'Get app logs' implies a read-only operation, but it doesn't specify authentication requirements, rate limits, pagination behavior, or what happens when the app doesn't exist. For a tool with 4 parameters and no annotation coverage, this leaves significant behavioral questions unanswered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 3 words, which is efficient and front-loaded. However, it's arguably too brief given the tool's functionality - it sacrifices clarity for brevity. Every word earns its place, but more words might be needed to adequately describe the tool's purpose and usage.
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 tool's complexity (4 parameters, no output schema, no annotations), the description is insufficient. It doesn't explain what format the logs are returned in, whether they're real-time or historical, how they're structured, or any limitations. For a log retrieval tool that likely returns structured data, the description should provide more context about the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 4 parameters thoroughly. The description adds no additional parameter information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description, which applies here.
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 'Get app logs' states the basic action (get) and resource (app logs), but it's vague about scope and format. It doesn't differentiate from potential sibling tools like 'liara_get_metrics' or 'liara_get_app' that might provide related information. The purpose is understandable but lacks specificity about what kind of logs or what timeframe is covered.
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 about when to use this tool versus alternatives. With many sibling tools available (including other 'get' operations like 'liara_get_metrics'), the description offers no context about when log retrieval is appropriate versus other monitoring or diagnostic tools. There's no mention of prerequisites, typical use cases, or limitations.
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 of behavioral disclosure. It states 'Get details,' implying a read-only operation, but doesn't confirm safety aspects like no side effects, authentication requirements, rate limits, or error handling. For a tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves beyond basic functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: 'Get details of a DNS zone.' It's front-loaded with the core action and resource, with zero wasted words. However, it could be slightly more informative without losing conciseness (e.g., specifying what 'details' include). Overall, it's well-structured but minimal.
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 (a read operation with one parameter) and lack of annotations and output schema, the description is incomplete. It doesn't explain what 'details' are returned (e.g., zone configuration, status), potential errors, or how this fits into broader DNS management workflows. For a tool with no structured output information, more descriptive context is needed to guide the agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with 'zoneId' clearly documented as 'The zone ID.' The description doesn't add any meaning beyond this—it doesn't explain what a zone ID is, how to obtain it (e.g., from 'liara_list_zones'), or format examples. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, but no extra value is provided.
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 'Get details of a DNS zone' clearly states the verb ('Get') and resource ('DNS zone'), making the purpose understandable. However, it's somewhat vague—'details' is not specific about what information is retrieved (e.g., configuration, records, status). It doesn't differentiate from siblings like 'liara_get_dns_record' or 'liara_list_zones', which are related DNS operations.
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. It doesn't mention prerequisites (e.g., needing a zone ID from 'liara_list_zones'), compare to 'liara_get_dns_record' for record-level details, or specify use cases like troubleshooting or configuration review. Without such context, the agent must infer usage from 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Restart' implies a mutation operation that may cause downtime or service interruption, but the description doesn't clarify these effects, required permissions, rate limits, or expected outcomes. For a potentially disruptive tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at three words, which is efficient and front-loaded. However, it's arguably too brief for a tool that performs a potentially disruptive operation, as it omits critical context that would help the agent use it correctly. While not wasteful, it prioritizes brevity over completeness.
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 tool's complexity (a mutation operation on a server with no annotations and no output schema), the description is incomplete. It lacks details on behavioral traits (e.g., downtime, permissions), usage context, and expected outcomes. For a restart tool in a suite with start/stop alternatives, this leaves the agent under-informed about when and how to invoke it safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'mailId' documented as 'The mail server ID'. The description adds no additional parameter information beyond what the schema provides. According to the rules, when schema_description_coverage is high (>80%), the baseline score is 3 even with no param info in the description, which applies here.
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 'Restart a mail server' clearly states the action (restart) and target resource (mail server), providing a basic understanding of the tool's function. However, it doesn't differentiate from sibling tools like liara_start_mail_server or liara_stop_mail_server, nor does it specify what 'restart' entails (e.g., graceful vs. forced, downtime implications). The purpose is clear but lacks specificity and sibling 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., the mail server must exist and be running), when restart is appropriate versus start/stop, or what scenarios warrant its use. With sibling tools like liara_start_mail_server and liara_stop_mail_server available, this omission leaves the agent without 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 are provided, so the description carries the full burden of behavioral disclosure. 'Create a new network' implies a write operation, but it doesn't specify permissions required, whether it's idempotent, potential costs, rate limits, or what happens on failure (e.g., if a network with the same name exists). For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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 extremely concise with 'Create a new network'—a single, front-loaded sentence that directly states the tool's purpose without unnecessary words. It earns its place by being clear and to the point, though it could benefit from additional context.
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 of a network creation tool (likely involving infrastructure changes), no annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like side effects, return values, or error handling. For a mutation tool in a list with many siblings, more context is needed to ensure safe and correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with parameters 'name' and 'cidr' clearly documented. The description doesn't add any meaning beyond this, such as explaining naming conventions, CIDR format examples, or default behaviors. Since schema coverage is high, the baseline score of 3 is appropriate, as the schema handles parameter documentation adequately.
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 'Create a new network' clearly states the action (create) and resource (network), but it's vague about what a 'network' entails in this context. It doesn't differentiate from sibling tools like liara_attach_network or liara_detach_network, which also involve networks. The purpose is understandable but lacks specificity about the network's role or 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 guidance is provided on when to use this tool versus alternatives. With siblings like liara_attach_network and liara_detach_network, the description doesn't clarify if this is for initial setup, isolated networks, or specific use cases. There's no mention of prerequisites, dependencies, or typical scenarios for network creation.
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 of behavioral disclosure. While 'Delete' implies a destructive mutation, the description doesn't specify whether deletion is permanent, requires specific permissions, has side effects (e.g., removing associated resources), or provides confirmation. This is a significant gap for a destructive operation with zero annotation coverage.
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 'Delete an app' is extremely concise—just three words—with zero wasted language. It's front-loaded and efficiently communicates the core purpose without unnecessary elaboration, making it easy for an agent to parse quickly.
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 tool's destructive nature, lack of annotations, and absence of an output schema, the description is incomplete. It doesn't address critical aspects like what happens post-deletion (e.g., confirmation, error handling), dependencies, or safety warnings. For a deletion tool with no structured support, more descriptive context is needed to guide proper use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'name' clearly documented as 'The name of the app to delete'. The description adds no additional parameter information beyond what the schema provides, so it meets the baseline of 3 for high schema coverage without adding value.
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 'Delete an app' clearly states the action (delete) and target resource (app), which is a specific verb+resource combination. However, it doesn't distinguish this tool from other deletion tools in the sibling list (like liara_delete_backup, liara_delete_database, etc.), missing the opportunity to clarify what makes 'app' deletion unique in this 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing app), exclusions, or relationships with sibling tools like liara_get_app for verification or liara_list_apps for selection. This leaves the agent without context for proper tool 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 provided, the description carries full burden for behavioral disclosure. 'Delete a database' implies a destructive, irreversible mutation, but the description fails to disclose critical behavioral traits: whether deletion is permanent, if it requires specific permissions, what happens to associated data/connections, or any confirmation prompts. For a destructive operation with zero annotation coverage, this is dangerously inadequate.
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 maximally concise at three words, front-loading the essential action and resource. There's zero wasted language or redundant information. For a simple destructive operation, this brevity is appropriate, though it comes at the cost of missing important behavioral context.
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?
For a destructive database deletion tool with no annotations and no output schema, the description is severely incomplete. It doesn't address the mutation's consequences, required permissions, confirmation needs, or what happens upon success/failure. Given the high-stakes nature of database deletion and the lack of structured safety information, this description leaves critical gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'name' clearly documented as 'The name of the database to delete'. The description doesn't add any parameter semantics beyond what the schema already provides, such as format requirements or validation rules. With complete schema coverage, the baseline score of 3 is appropriate.
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 resource ('a database'), making the purpose immediately understandable. It distinguishes this from other database operations like 'create', 'update', or 'get' database tools in the sibling list. However, it doesn't specify whether this deletes a single database or has any scope limitations beyond what the parameter implies.
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. There's no mention of prerequisites (e.g., database must exist, no active connections), consequences (e.g., data loss, irreversible action), or when to choose deletion over other database management tools like 'update_database' or 'resize_database' from the sibling list.
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 of behavioral disclosure. It states the action is 'delete,' implying a destructive mutation, but fails to mention critical details like whether deletion is permanent, requires specific permissions, has side effects, or returns confirmation. This leaves the agent guessing about 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence, 'Delete a DNS record,' which is front-loaded and wastes no words. For a simple tool, this brevity is appropriate and efficient.
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 tool's destructive nature, no annotations, and no output schema, the description is incomplete. It lacks crucial context such as confirmation of deletion, error handling, or impact on related resources, making it inadequate for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with clear descriptions for zoneId and recordId in the input schema. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline of 3 for adequate but not enhanced documentation.
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 'Delete a DNS record' clearly states the action (delete) and resource (DNS record), which is specific enough to understand the basic purpose. However, it doesn't differentiate from sibling tools like liara_delete_zone or liara_delete_dns_record's counterpart liara_update_dns_record, leaving room for confusion about 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing DNS record), exclusions, or related tools like liara_get_dns_record for verification, which is a significant gap for a destructive operation.
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 of behavioral disclosure. 'Delete a network' implies a destructive mutation, but it doesn't specify whether this action is reversible, requires specific permissions, has side effects (e.g., impacting attached resources), or includes confirmation prompts. This lack of detail is a significant gap for a destructive operation.
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 extremely concise with just three words, front-loading the key action and resource. There is no wasted language or redundancy, making it efficient for quick parsing by an AI agent. This brevity is appropriate given the straightforward tool purpose.
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?
For a destructive tool with no annotations and no output schema, the description is incomplete. It lacks critical context such as behavioral traits (e.g., irreversibility, dependencies), usage prerequisites, and expected outcomes. While the schema covers the parameter, the overall tool understanding remains inadequate for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the parameter 'networkId' clearly documented as 'The network ID to delete'. The description adds no additional semantic context beyond this, such as format examples or sourcing instructions. Given the high schema coverage, a baseline score of 3 is appropriate, as the schema does the heavy lifting.
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 'Delete a network' clearly states the verb (delete) and resource (network), which is adequate. However, it doesn't differentiate from sibling deletion tools like liara_delete_app or liara_delete_zone, leaving the agent to infer the specific resource type from the name alone. This makes it vague in distinguishing among similar operations.
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. It doesn't mention prerequisites (e.g., whether the network must be detached first), exclusions, or related tools like liara_detach_network. The agent must rely solely on the tool name and context, which is insufficient for informed 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 provided, the description carries the full burden of behavioral disclosure but only states the action without details. It doesn't cover critical aspects like whether this is a mutating operation (likely yes, given 'deploy'), potential side effects (e.g., downtime, environment changes), authentication needs, rate limits, or response format. This leaves significant gaps in understanding 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with zero wasted words. It's front-loaded with the core action ('Deploy a release') and efficiently states the key input ('using a source ID'), making it easy to parse quickly without unnecessary elaboration.
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 tool's complexity (a deployment operation likely involving mutating changes), lack of annotations, and no output schema, the description is insufficient. It doesn't explain what 'deploy' entails, potential impacts, or return values, leaving the agent with inadequate context to use the tool safely and effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the parameters (appName, sourceID, envVars). The description adds no additional meaning beyond implying 'sourceID' comes from a previous upload, which is minimal value. This meets the baseline of 3, as the schema handles the heavy lifting without description enhancement.
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 action ('Deploy a release') and mentions the resource ('using a source ID'), which provides a basic purpose. However, it lacks specificity about what 'deploy' entails (e.g., activating a release, triggering a build) and doesn't distinguish it from sibling tools like 'liara_rollback_release' or 'liara_start_app', leaving ambiguity about its unique function.
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 offers no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an uploaded source via 'liara_upload_source'), exclusions, or comparisons to related tools like 'liara_rollback_release' or 'liara_restart_app', leaving the agent to infer usage context without explicit 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?
No annotations are provided, so the description carries full burden. It implies a read-only operation ('get'), but doesn't disclose behavioral traits such as authentication requirements, rate limits, error handling, or whether it returns partial/full details. The description is minimal and lacks necessary context 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded and directly states the tool's purpose without unnecessary elaboration, making it easy to parse quickly.
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 tool's complexity (a read operation with one parameter) and lack of annotations and output schema, the description is incomplete. It doesn't explain what details are returned, potential errors, or dependencies on other tools like 'liara_list_domains'. For a tool without structured output, more context is needed to guide the agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'domainId' clearly documented in the schema. The description adds no additional meaning beyond the schema, such as explaining where to obtain the domain ID or its format. Baseline score of 3 is appropriate since the schema adequately covers the parameter.
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 'Get details of a domain' clearly states the action (get) and resource (domain), but it's vague about what 'details' includes. It distinguishes from siblings like 'liara_list_domains' (list vs get details) and 'liara_add_domain' (create vs read), but lacks specificity about the scope of details returned.
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 explicit guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a domain ID from 'liara_list_domains'), nor does it clarify use cases like checking domain status versus configuration. The presence of sibling tools like 'liara_list_domains' and 'liara_remove_domain' suggests context, but the description provides no usage instructions.
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 full burden for behavioral disclosure. 'Get app metrics summary' implies a read-only operation, but doesn't specify authentication requirements, rate limits, data freshness, or what format the summary returns. For a metrics tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
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 extremely concise at just three words, with zero wasted language. It's front-loaded with the essential action and resource. For a simple retrieval tool, this brevity is appropriate and efficient.
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 no annotations, no output schema, and the description's minimalism, this is inadequate for a metrics tool. The description doesn't explain what 'metrics summary' includes, how metrics are aggregated, time granularity options, or return format. For a tool that presumably provides quantitative data about app performance, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('appName' and optional 'period') well-documented in the schema. The description doesn't add any parameter information beyond what the schema already provides, so it meets the baseline for high schema coverage but doesn't enhance understanding of parameter usage or constraints.
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 'Get app metrics summary' clearly states the verb ('Get') and resource ('app metrics summary'), making the purpose understandable. However, it's somewhat vague about what specific metrics are included and doesn't differentiate from sibling tools like 'liara_get_app' or 'liara_get_logs' that also retrieve app-related information.
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. With many sibling tools available (like liara_get_app, liara_get_logs, liara_list_apps), there's no indication of when metrics summary is appropriate versus other app information sources. No prerequisites 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.
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 states 'Get details' which suggests a read-only operation, but doesn't disclose behavioral traits like authentication needs, rate limits, error handling, or response format. The description is minimal and lacks context beyond the basic action, leaving gaps in understanding 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to scan. Every word earns its place by conveying the essential purpose without 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?
Given the complexity (a read operation with no output schema and no annotations), the description is incomplete. It doesn't explain what 'details' include, the response structure, or any behavioral aspects. For a tool that likely returns structured plan information, more context is needed to guide the agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage (parameter 'planId' is described as 'The plan ID'), so the baseline is 3. The description doesn't add any meaning beyond the schema—it doesn't explain what a plan ID is, how to obtain it, or format requirements. It relies entirely on the schema for parameter documentation.
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 'Get details of a specific plan' clearly states the action (get) and resource (plan), but it's vague about what 'details' entail. It distinguishes from siblings like 'liara_list_plans' by specifying retrieval of a single plan, but lacks specificity about the type of details returned (e.g., pricing, features, limits).
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 explicit guidance on when to use this tool versus alternatives. The description implies it's for retrieving a single plan by ID, but doesn't mention prerequisites (e.g., needing a plan ID from 'liara_list_plans'), exclusions, or comparisons to other get tools (e.g., 'liara_get_app'). Usage is implied but not clearly articulated.
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 of behavioral disclosure. 'Get details' implies a read-only operation, but it doesn't specify if this requires authentication, has rate limits, returns structured data, or involves any side effects. For a tool with zero annotation coverage, this is insufficient to inform 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded and wastes no space, making it easy to parse quickly. This is an example of optimal conciseness for a simple tool.
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 tool's moderate complexity (a read operation with 2 required parameters) and lack of annotations and output schema, the description is incomplete. It doesn't explain what 'details' are returned, potential errors, or behavioral traits like idempotency. For a tool with no structured output information, more descriptive context is needed to guide the agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear parameter descriptions ('appName' and 'releaseID'), so the schema does the heavy lifting. The description adds no additional meaning beyond implying these parameters identify a specific release, which is already inferred from the schema. Baseline 3 is appropriate as the schema provides adequate documentation.
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 'Get details of a specific release' clearly states the verb ('Get') and resource ('release'), making the purpose understandable. However, it's vague about what 'details' include and doesn't differentiate from sibling tools like 'liara_list_releases' or 'liara_rollback_release', which also involve releases. It's adequate 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing release), exclusions, or comparisons to siblings like 'liara_list_releases' for listing all releases or 'liara_rollback_release' for modifying releases. This leaves the agent without 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 provided, the description carries full burden but only states the action without behavioral details. It doesn't disclose potential downtime, permissions required, side effects (e.g., temporary unavailability), or response behavior. For a mutation tool like restart, this lack of transparency is a significant gap.
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 extremely concise at three words, with zero wasted text. It's front-loaded and to the point, making it easy to parse quickly. This is an example of efficient communication.
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 this is a mutation tool (restart) with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects like downtime, idempotency, error conditions, or what happens post-restart. For a tool that could disrupt service, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage (parameter 'name' is fully described), so the baseline score is 3. The tool description adds no additional parameter information beyond what the schema provides, but it doesn't need to compensate for gaps.
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 'Restart an app' clearly states the action (restart) and target resource (app), which is adequate. However, it doesn't differentiate from sibling tools like liara_start_app or liara_stop_app, nor does it specify what 'restart' entails (e.g., graceful vs. forced). It's a basic but functional statement of 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 is provided on when to use this tool versus alternatives like liara_start_app or liara_stop_app, or prerequisites (e.g., app must be running). The description alone offers no context for decision-making, leaving the agent to infer usage from the name and sibling list.
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 of behavioral disclosure. It states the action ('Start') but does not reveal any behavioral traits such as permissions required, whether it's idempotent, expected duration, side effects (e.g., service interruption), or error conditions. This leaves significant gaps 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with 'Start a database', consisting of a single, front-loaded sentence that directly states the tool's function without any wasted words. This efficiency is appropriate for a simple tool, though it may sacrifice detail for brevity.
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 tool's complexity (a mutation operation with no annotations and no output schema), the description is incomplete. It lacks information on behavioral aspects, usage context, and expected outcomes, which are crucial for an agent to invoke it correctly. The high schema coverage does not compensate for these gaps in a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'name' documented as 'The name of the database'. The description does not add any meaning beyond this, such as format constraints or examples. With high schema coverage, the baseline score of 3 is appropriate, as the schema handles the parameter documentation adequately.
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 'Start a database' clearly states the action (start) and resource (database), providing a basic purpose. However, it lacks specificity about what 'starting' entails (e.g., booting up, resuming from a stopped state) and does not differentiate from sibling tools like liara_restart_database or liara_stop_database, making it vague in 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 guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites (e.g., the database must be stopped), exclusions (e.g., cannot start if already running), or related tools like liara_stop_database or liara_restart_database, leaving the agent without 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 are provided, so the description carries the full burden of behavioral disclosure. 'Update' implies a mutation operation, but the description doesn't specify whether this requires specific permissions, what happens to unspecified fields (partial vs. full updates), potential side effects (e.g., DNS propagation delays), or error conditions. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
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, efficient sentence with zero waste. It's appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary elaboration. Every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of updating a DNS record (a mutation with 7 parameters), no annotations, and no output schema, the description is incomplete. It doesn't address behavioral aspects like permissions, side effects, or response format, leaving the agent with insufficient context to use the tool safely and effectively. The schema covers parameters well, but overall completeness is lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 7 parameters with descriptions and optional/required status. The description adds no additional meaning beyond the schema, such as explaining relationships between parameters (e.g., 'priority' only matters for certain 'type' values) or providing examples. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update a DNS record' clearly states the action (update) and resource (DNS record), making the purpose understandable. However, it lacks specificity about what aspects can be updated and doesn't differentiate from the sibling tool 'liara_update_database' which follows a similar pattern. It's not tautological but remains somewhat vague about 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?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites (e.g., needing an existing DNS record), comparison with 'liara_create_dns_record' for new records, or any context about when updates are appropriate versus deletion/recreation. Usage is implied but not explicitly stated.
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 full burden but only states the basic action without disclosing behavioral traits. It doesn't mention whether this requires specific permissions, if it's idempotent, what happens on conflicts, or any rate limits—critical for a mutation tool with zero annotation coverage.
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, efficient sentence that directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded, making it easy to parse quickly.
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?
For a mutation tool with no annotations and no output schema, the description is incomplete. It lacks information on permissions, error conditions, return values, or how it interacts with sibling domain tools, leaving significant gaps 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters ('appName' and 'domain') adequately. The description adds no additional meaning beyond what the schema provides, such as format examples or constraints, meeting the baseline for high schema coverage.
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 ('Add') and resource ('a domain to an app'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'liara_set_default_subdomain' or 'liara_remove_domain' that also operate on domains, missing explicit sibling 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 is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, constraints, or when to choose this over similar tools like 'liara_set_default_subdomain' for domain management, leaving usage context implied at best.
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 full burden for behavioral disclosure. 'Attach' implies a mutation operation, but the description doesn't specify whether this requires specific permissions, whether it's reversible, what happens if the network is already attached, or any rate limits. This leaves significant gaps in understanding 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise - a single, clear sentence that communicates the core purpose without any wasted words. It's front-loaded with the essential information and contains no unnecessary elaboration.
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?
For a mutation tool with no annotations and no output schema, the description is inadequate. It doesn't explain what happens after attachment, whether there are side effects, what the expected outcome looks like, or any error conditions. Given the complexity of network attachment operations, this leaves too many questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with both parameters clearly documented in the schema. The description doesn't add any additional parameter context beyond what's already in the schema, so it meets the baseline expectation but doesn't provide extra value.
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 ('Attach') and resource ('a network to a VM'), making the purpose immediately understandable. However, it doesn't distinguish this tool from its sibling 'liara_detach_network' or other network/Vm-related tools, which prevents a perfect score.
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 'liara_create_network' or 'liara_detach_network'. There's no mention of prerequisites, dependencies, or typical use cases, leaving the agent with insufficient context for optimal tool 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 provided, the description carries the full burden of behavioral disclosure. It states the action ('create') but lacks critical details: it doesn't specify if this is a destructive operation (e.g., overwrites existing backups), requires specific permissions, has rate limits, or what the expected outcome is (e.g., backup ID, status). For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
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, efficient sentence with zero wasted words—'Create a database backup'—making it front-loaded and easy to parse. Every word earns its place by conveying the core action and resource without unnecessary elaboration.
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 tool's complexity as a mutation operation with no annotations and no output schema, the description is incomplete. It lacks information on behavioral traits (e.g., side effects, permissions), output details (e.g., what is returned), and usage context, making it inadequate for an agent to fully understand how to invoke and interpret results from this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'databaseName' fully documented in the schema. The description adds no additional parameter information beyond implying a database is involved, which is already clear from the schema. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description neither compensates nor detracts from parameter understanding.
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 'Create a database backup' clearly states the action (create) and resource (database backup), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'liara_restore_backup' or 'liara_list_backups' beyond the basic verb, missing specific scope or method details that would distinguish it more precisely.
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. It doesn't mention prerequisites (e.g., database must exist), exclusions (e.g., cannot create backup while database is stopped), or related tools like 'liara_list_backups' for viewing existing backups, leaving the agent to infer usage context from 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?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It implies a write operation ('Create') but doesn't disclose critical traits like authentication requirements, rate limits, idempotency, error handling, or what happens on success (e.g., bucket creation confirmation). This leaves significant gaps 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with zero wasted words, front-loading the key action and resource. It efficiently communicates the core purpose without unnecessary elaboration, making it easy to parse quickly.
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?
For a mutation tool with no annotations and no output schema, the description is incomplete. It lacks behavioral details (e.g., side effects, response format), usage context, and doesn't compensate for the absence of structured output information. This could hinder an agent's ability to invoke it correctly without trial and error.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear parameter descriptions and an enum for 'permission'. The description adds no additional parameter context beyond the schema, such as naming conventions for 'name', default values for 'region', or implications of 'permission' choices. Baseline 3 is appropriate as the schema does the heavy lifting.
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 ('Create') and resource ('new storage bucket'), making the purpose immediately understandable. It distinguishes this as a creation tool among siblings like 'liara_get_bucket' or 'liara_list_buckets', though it doesn't explicitly differentiate from other creation tools like 'liara_create_app' or 'liara_create_database' beyond 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., permissions, quotas), when not to use it (e.g., if a bucket already exists), or refer to sibling tools like 'liara_list_buckets' for checking existing buckets or 'liara_delete_bucket' for removal.
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 full burden but only states it 'creates' without disclosing behavioral traits. It doesn't mention if this is a mutating operation (implied but not explicit), what permissions are required, whether it's idempotent, potential costs, or what happens on failure. For a creation tool with zero annotation coverage, this is a significant gap in transparency.
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, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it immediately scannable and appropriately sized for a straightforward creation tool.
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?
For a database creation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what happens after creation (e.g., returns a database ID, connection details), potential side effects, error conditions, or integration with other tools like 'liara_get_database_connection'. The 100% schema coverage helps with inputs but doesn't compensate for missing behavioral and output context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 4 parameters (name, type, planID, version) with descriptions and enum values. The description adds no additional parameter information beyond what's in the schema, which meets the baseline for high schema coverage but doesn't provide extra context like format examples or dependencies between 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 clearly states the action ('Create') and resource ('database'), making the purpose immediately understandable. It distinguishes from siblings like 'liara_update_database' (modify) and 'liara_list_databases' (read), but doesn't specify what kind of database beyond the generic term, which keeps it from a perfect score.
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. It doesn't mention prerequisites (e.g., needing a plan ID from 'liara_list_plans'), when not to use it (e.g., if a database already exists), or clarify differences from similar tools like 'liara_create_app' or 'liara_create_vm' for infrastructure creation.
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 of behavioral disclosure. It states 'Create' which implies a write/mutation operation, but doesn't address permissions required, whether this action is reversible, what happens on success/failure, or any rate limits. The description lacks crucial behavioral context for a creation tool.
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, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for a tool with only 2 parameters and follows the principle of front-loading the essential information.
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?
For a creation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what FTP access creation entails, what credentials or endpoints are returned, or any behavioral implications. The agent would need to guess about the tool's effects and outputs based on minimal information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage with clear parameter documentation, so the baseline is 3. The description doesn't add any parameter information beyond what's in the schema, but doesn't need to since schema coverage is complete. No additional semantic context is provided about the 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 'Create FTP access for a disk' clearly states the action (create) and resource (FTP access for a disk), making the purpose immediately understandable. However, it doesn't differentiate from the sibling tool 'liara_delete_ftp_access' or explain what FTP access entails beyond the basic verb-noun pairing.
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. There's no mention of prerequisites (e.g., needing an existing disk), constraints, or comparison with related tools like 'liara_list_ftp_accesses' or 'liara_delete_ftp_access', leaving the agent 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Create a VM snapshot' but does not mention critical details like whether this operation is destructive, requires specific permissions, impacts VM performance, or has rate limits. This leaves significant gaps in understanding 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, making it easy to parse and understand quickly. It is appropriately sized for the tool's purpose and front-loaded with essential information.
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 lack of annotations and output schema, the description is incomplete for a mutation tool. It fails to address behavioral aspects like side effects, error conditions, or return values, leaving the agent with insufficient context to use the tool safely and effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with 'vmId' and 'name' clearly documented. The description does not add any additional meaning beyond the schema, such as format examples or constraints, but the schema provides adequate baseline information, meeting the minimum viable standard.
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 'Create a VM snapshot' clearly states the action (create) and resource (VM snapshot), which is specific and unambiguous. However, it does not differentiate from sibling tools like 'liara_create_backup' or 'liara_restore_snapshot', which involve similar concepts, leaving some ambiguity in 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 guidance is provided on when to use this tool versus alternatives such as 'liara_create_backup' or 'liara_restore_snapshot'. The description lacks context about prerequisites (e.g., VM state), exclusions, or specific use cases, offering only a basic statement of purpose.
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 of behavioral disclosure. 'Create a new virtual machine' implies a mutation/write operation, but it doesn't disclose any behavioral traits: no information on permissions required, whether this is a long-running operation, what happens on failure, rate limits, or what the response looks like (since no output schema exists). For a creation tool with zero annotation coverage, this is a significant gap.
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, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it immediately scannable. Every word earns its place, and there's no redundancy or unnecessary elaboration.
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 of creating a virtual machine (a significant mutation with 5 parameters), the lack of annotations, and no output schema, the description is incomplete. It doesn't address behavioral aspects like permissions, execution time, error handling, or response format. While the schema covers parameters well, the overall context for safe and effective use is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with all 5 parameters clearly documented in the schema itself. The description adds no parameter-specific information beyond what's in the schema (e.g., no context on valid OS values, planID sources, or network requirements). According to the rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
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 ('Create') and resource ('virtual machine'), making the purpose immediately understandable. It distinguishes from siblings like 'liara_create_app' or 'liara_create_database' by specifying the VM resource type. However, it doesn't explicitly differentiate from other VM-related tools like 'liara_resize_vm' or 'liara_start_vm' beyond the 'create' verb.
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. There's no mention of prerequisites (e.g., needing a planID or network first), when not to use it (e.g., for modifying existing VMs), or how it relates to sibling tools like 'liara_get_vm' or 'liara_list_vms'. The agent must infer usage from the name and schema 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 provided, the description carries full burden for behavioral disclosure. 'Create' implies a write/mutation operation, but the description doesn't specify permissions required, whether this operation is idempotent, what happens on duplicate zone creation, rate limits, or what the tool returns. For a creation tool with zero annotation coverage, this is inadequate.
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, efficient sentence with zero wasted words. It's appropriately sized for a simple creation tool and front-loads the essential information.
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?
For a creation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what a DNS zone is in this context, what happens after creation, whether it returns a zone ID or confirmation, or any error conditions. Given the complexity of DNS management and the lack of structured metadata, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with the single parameter 'name' fully documented as 'Zone name (domain)'. The description doesn't add any additional parameter context beyond what the schema provides, such as format requirements (e.g., FQDN) or validation rules. Baseline 3 is appropriate when schema does the heavy lifting.
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 ('Create') and resource ('new DNS zone'), providing a specific verb+resource combination. It distinguishes from sibling tools like liara_get_zone (read) and liara_delete_zone (delete), though it doesn't explicitly differentiate from liara_add_domain which might have overlapping functionality.
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 liara_add_domain or liara_set_default_subdomain. The description doesn't mention prerequisites, constraints, or typical use cases for creating a DNS zone versus other domain-related 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?
No annotations are provided, so the description carries full burden. It states 'Delete' which implies a destructive mutation, but doesn't disclose critical behavioral traits: whether deletion is permanent/irreversible, if it requires specific permissions, what happens on success/failure, or if there are rate limits. For a destructive tool with zero annotation coverage, this is a significant gap.
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, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it immediately understandable. Every word earns its place.
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?
For a destructive mutation tool with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects (irreversibility, permissions), usage context, or what to expect after invocation. The agent lacks sufficient information to use this tool safely and effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('databaseName' and 'backupId') clearly documented in the schema. The description doesn't add any parameter semantics beyond what the schema provides (e.g., format examples or relationships between parameters). Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 resource ('a database backup'), providing a specific verb+resource combination. It doesn't explicitly differentiate from sibling tools like 'liara_delete_database' or 'liara_delete_snapshot', but the resource specificity is adequate for basic understanding.
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. There's no mention of prerequisites (e.g., needing to identify backups via 'liara_list_backups' first), consequences, or when not to use it (e.g., if the backup is critical). The agent must infer usage from context 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 provided, the description carries full burden but offers minimal behavioral insight. 'Delete' implies a destructive, irreversible mutation, but the description doesn't disclose critical traits like whether deletion requires specific permissions, what happens to contained objects, if there are rate limits, or what the response looks like. For a destructive operation with zero annotation coverage, this is inadequate.
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, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it immediately scannable and understandable without unnecessary elaboration.
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?
For a destructive deletion tool with no annotations and no output schema, the description is severely incomplete. It doesn't cover behavioral implications, success/failure responses, prerequisites, or error conditions. The agent lacks sufficient context to use this tool safely and effectively despite the simple parameter schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'name' clearly documented in the schema. The description adds no additional parameter context beyond what the schema already provides (e.g., format requirements, naming conventions, or examples). This meets the baseline for high schema coverage but doesn't enhance understanding.
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 verb ('Delete') and resource ('a storage bucket'), making the purpose immediately understandable. It distinguishes from siblings like 'liara_delete_object' (which deletes individual objects) and 'liara_delete_app' (which deletes applications). However, it doesn't specify that this deletes the entire bucket structure versus just contents, which would make it 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., bucket must be empty), consequences (e.g., irreversible deletion), or when to choose 'liara_delete_object' for individual items instead. This leaves the agent guessing about appropriate 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?
No annotations are provided, so the description carries full burden. 'Delete' implies a destructive mutation, but the description doesn't disclose critical behavioral traits: whether deletion is permanent, requires specific permissions, affects associated resources, or has confirmation steps. For a destructive operation with zero annotation coverage, this is a significant gap in safety and operational context.
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 extremely concise ('Delete a disk') - a single sentence with zero waste. It's front-loaded with the core action, though this brevity comes at the cost of completeness for a destructive operation.
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?
For a destructive mutation tool with no annotations and no output schema, the description is incomplete. It should address behavioral aspects (irreversibility, dependencies, permissions) and expected outcomes. The current description provides minimal context beyond the basic action, leaving critical gaps for safe and effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters (appName, diskName) clearly documented in the schema. The description adds no additional meaning about parameters beyond what's in the schema (e.g., format examples, relationships between app and disk). Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 resource ('a disk'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from other delete operations in the sibling list (like liara_delete_app, liara_delete_backup, etc.), which would require mentioning it specifically deletes disks rather than other resources.
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. There's no mention of prerequisites (e.g., needing an existing disk), consequences (e.g., data loss), or when to choose other tools like liara_delete_app or liara_resize_disk. The agent must 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 provided, the description carries the full burden of behavioral disclosure. It states the action is a deletion/unset, implying a destructive mutation, but lacks critical details: whether it requires specific permissions, if the change is immediate or reversible, potential impacts on the app (e.g., downtime), or error conditions. This leaves significant gaps for safe agent operation.
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, efficient sentence with zero wasted words, front-loading the core action. It's appropriately sized for a simple deletion tool, making it easy to parse quickly.
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?
For a destructive mutation tool with no annotations and no output schema, the description is incomplete. It lacks information on behavioral traits (e.g., side effects, auth needs), output format (e.g., success confirmation or error details), and usage context compared to siblings. This could lead to misuse or uncertainty in agent decisions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear parameter descriptions in the schema (appName and key). The description adds no additional semantic context beyond implying these parameters are needed, so it meets the baseline of 3 where the schema does the heavy lifting without extra value from the description.
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 verb 'delete/unset' and the resource 'environment variable for an app', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like liara_delete_env_vars (plural) or liara_set_env_var, which could cause confusion about 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing app or variable), compare it to liara_delete_env_vars (bulk deletion) or liara_set_env_var (creation/update), or indicate any constraints like permissions or effects on the app.
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 of behavioral disclosure. It states the tool deletes/unset variables, implying a destructive mutation, but fails to mention critical details like permission requirements, whether deletions are permanent, error handling for non-existent variables, or side effects on the app. This leaves significant gaps in understanding 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It is front-loaded with the core action and resource, making it easy to parse quickly, with no wasted verbiage.
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?
For a destructive mutation tool with no annotations and no output schema, the description is insufficient. It lacks details on behavioral traits (e.g., idempotency, auth needs), error scenarios, and what happens post-deletion (e.g., app restart). Given the complexity and risk of deleting environment variables, more context is needed for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting both parameters ('appName' and 'keys'). The description adds no additional semantic context beyond what the schema provides, such as format examples or constraints. Given the high schema coverage, a baseline score of 3 is appropriate, as the description doesn't compensate but doesn't need to heavily.
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/unset') and resource ('multiple environment variables for an app'), making the purpose evident. However, it doesn't explicitly differentiate from its sibling 'liara_delete_env_var' (singular), which might handle single deletions, leaving some ambiguity in sibling 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?
The description provides no guidance on when to use this tool versus alternatives like 'liara_delete_env_var' or 'liara_set_env_vars' for updates. It lacks context on prerequisites, such as whether the app must exist or variables be set, offering minimal 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 provided, the description carries full burden for behavioral disclosure. While 'Delete/revoke' implies a destructive mutation, it doesn't specify whether this action is reversible, what permissions are required, whether it affects other system components, or what happens to associated data. For a deletion tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
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, efficient sentence that communicates the core purpose without unnecessary words. It's appropriately sized for a straightforward deletion operation and gets directly to the point.
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?
For a destructive deletion tool with no annotations and no output schema, the description is insufficient. It doesn't address what the tool returns, what side effects might occur, or provide any context about the FTP access being deleted. Given the complexity of a deletion operation in a cloud infrastructure context, more completeness is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with all three parameters clearly documented in the input schema. The description doesn't add any additional parameter context beyond what's already in the schema, so it meets the baseline expectation when schema coverage is complete.
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/revoke') and target resource ('FTP access for a disk'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'liara_delete_disk' or 'liara_delete_app', which would require more specific language about what exactly is being removed.
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. With sibling tools like 'liara_list_ftp_accesses' and 'liara_create_ftp_access', there's no indication of prerequisites, sequencing, or when this deletion operation is appropriate versus other deletion 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It states 'Delete' implying a destructive, irreversible mutation, but lacks critical details: whether it requires specific permissions, confirmation steps, rate limits, or what happens to associated data. For a deletion tool, this minimal description is insufficient for safe agent operation.
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, direct sentence with zero wasted words—'Delete a mail server' efficiently conveys the core action and target. It's appropriately sized for a simple operation and front-loaded with the essential information.
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?
For a deletion tool with no annotations and no output schema, the description is incomplete. It doesn't address behavioral risks (e.g., irreversibility), success/failure responses, or dependencies on other tools. Given the complexity of a destructive operation and lack of structured safety hints, more context is needed for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage (parameter 'mailId' is documented as 'The mail server ID to delete'), so the baseline is 3. The description adds no additional parameter context beyond what the schema provides—it doesn't explain where to obtain the mailId or format requirements, though this is acceptable given the comprehensive schema.
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 resource ('a mail server'), making the purpose immediately understandable. It distinguishes from sibling tools like 'liara_get_mail_server' and 'liara_list_mail_servers' by specifying the destructive operation, though it doesn't explicitly contrast with other deletion tools (e.g., 'liara_delete_app').
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 doesn't mention prerequisites (e.g., needing a mail server ID from 'liara_list_mail_servers'), consequences of deletion, or when to choose other tools like 'liara_stop_mail_server' for temporary actions. This leaves the agent without context for proper tool 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 provided, the description carries full burden for behavioral disclosure. While 'Delete' implies a destructive mutation, the description doesn't specify whether deletion is permanent, reversible, requires specific permissions, or has side effects (e.g., affecting other objects). It also doesn't mention rate limits, authentication needs, or what happens on success/failure.
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, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it immediately scannable. Every word earns its place by conveying essential information without 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?
For a destructive tool with no annotations and no output schema, the description is incomplete. It doesn't address critical context like what 'delete' means operationally (permanent vs soft delete), error handling, permissions required, or what the tool returns. The agent lacks sufficient information to use this tool safely and effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('bucketName', 'objectKey') clearly documented in the schema. The description adds no additional parameter semantics beyond what's in the schema (e.g., format examples, constraints, or relationships between parameters). This meets the baseline for high schema coverage.
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 resource ('an object from a bucket'), making the purpose immediately understandable. It distinguishes from sibling tools like 'liara_delete_bucket' by specifying object-level deletion rather than bucket-level. However, it doesn't specify what type of object (e.g., file, blob) or provide additional context about the bucket system.
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. There's no mention of prerequisites (e.g., bucket must exist), error conditions, or comparison with similar tools like 'liara_list_objects' for verification. The agent must infer usage purely from the tool name and parameters.
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 full burden but only states the action without behavioral details. It doesn't disclose that this is destructive, irreversible, permission-dependent, or has any side effects. For a deletion tool with zero annotation coverage, this is a significant transparency gap.
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, focused sentence with zero wasted words. It's front-loaded with the essential action and resource, making it highly efficient and immediately scannable.
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?
For a destructive operation with no annotations and no output schema, the description is insufficient. It doesn't cover behavioral aspects like irreversibility, permissions needed, or what happens after deletion. The context demands more disclosure than provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both parameters (vmId and snapshotId). The description adds no additional parameter context beyond what's in the schema, meeting the baseline expectation when schema does the heavy lifting.
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 resource ('a VM snapshot'), making the purpose immediately understandable. It doesn't differentiate from sibling tools like 'liara_delete_vm' or 'liara_delete_backup', but the resource specificity is adequate for basic understanding.
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 about when to use this tool versus alternatives like 'liara_restore_snapshot' or 'liara_delete_vm'. The description doesn't mention prerequisites, consequences, or appropriate contexts for deletion, leaving the agent without 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 provided, the description carries the full burden of behavioral disclosure. It states 'Delete' which implies a destructive, irreversible mutation, but lacks details on permissions required, side effects (e.g., if deletion affects related resources), error conditions, or confirmation prompts. This is a significant gap for a mutation tool with zero annotation coverage.
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, efficient sentence with zero wasted words—'Delete an uploaded source' directly conveys the core action and resource. It's front-loaded and appropriately sized for a simple deletion tool, making it easy for an agent to parse quickly.
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 tool's destructive nature, lack of annotations, and no output schema, the description is incomplete. It doesn't address behavioral aspects like irreversibility, error handling, or return values, which are critical for safe invocation. While concise, it fails to provide sufficient context for a mutation tool in this environment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear documentation for 'appName' and 'sourceID'. The description adds no additional parameter semantics beyond what's in the schema, such as format examples or validation rules. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, though the description doesn't compensate for any gaps.
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 'Delete an uploaded source' clearly states the action (delete) and resource (uploaded source), making the purpose immediately understandable. It distinguishes itself from siblings like 'liara_delete_app' or 'liara_delete_object' by specifying 'source' as the target, though it doesn't explicitly differentiate from similar deletion tools beyond the resource 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing source), exclusions, or relationships with sibling tools like 'liara_list_sources' for identification or 'liara_upload_source' for creation, leaving the agent to infer context from 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Delete' implies a destructive, irreversible mutation, but the description doesn't specify whether this requires special permissions, confirmation steps, or has side effects (e.g., associated resources like disks or networks). It also omits details like response format, error conditions, or rate limits, leaving the agent with insufficient operational context.
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, direct sentence with zero wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place, adhering perfectly to conciseness principles without being under-specified in this minimal context.
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 tool's complexity (destructive mutation with no annotations and no output schema), the description is incomplete. It lacks critical context like irreversible consequences, permission requirements, or what happens to dependent resources. For a high-stakes operation like VM deletion, this minimal description fails to provide the necessary completeness for safe and effective use by an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with 'vmId' clearly documented as 'The VM ID to delete'. The description adds no additional parameter semantics beyond what the schema provides, such as format examples or sourcing hints. Since schema coverage is high, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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 resource ('a virtual machine'), making the purpose immediately understandable. It distinguishes from sibling tools like 'liara_get_vm' or 'liara_create_vm' by specifying deletion rather than retrieval or creation. However, it doesn't explicitly differentiate from other deletion tools like 'liara_delete_app' or 'liara_delete_database' beyond 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., the VM must exist or be stopped), consequences (e.g., data loss, billing implications), or when to choose deletion over other actions like stopping or snapshotting. With many sibling tools including other deletions, this lack of context is a significant gap.
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 of behavioral disclosure. While 'Delete' implies a destructive mutation, the description doesn't specify whether this action is irreversible, requires specific permissions, affects associated resources (e.g., DNS records), or has rate limits. For a deletion tool with zero annotation coverage, this leaves critical behavioral traits undisclosed.
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, direct sentence ('Delete a DNS zone') with zero wasted words. It is front-loaded and efficiently communicates the core action without unnecessary elaboration, making it easy to parse quickly.
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 tool's complexity (a destructive deletion operation), lack of annotations, and no output schema, the description is incomplete. It fails to address critical context like what happens post-deletion, error conditions, or confirmation requirements. For a mutation tool with significant implications, this minimal description leaves too many unknowns for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'zoneId' parameter clearly documented as 'The zone ID to delete'. The description adds no additional parameter semantics beyond what the schema provides, such as format examples or where to obtain the zoneId. With high schema coverage, the baseline score of 3 is appropriate, as the schema does the heavy lifting.
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 resource ('a DNS zone'), making the purpose immediately understandable. It distinguishes itself from siblings like 'liara_get_zone' (read) and 'liara_create_zone' (create), though it doesn't explicitly mention these distinctions. The description avoids tautology by not just restating 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing zone), consequences (e.g., irreversible deletion), or when to choose deletion over other operations like updating. With many sibling tools (e.g., 'liara_delete_dns_record' for record-level deletion), the lack of differentiation is a significant gap.
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. 'Detach' implies a mutation operation, but the description doesn't disclose whether this requires specific permissions, if it's reversible, what happens to network connectivity during/after detachment, or any rate limits. This leaves significant behavioral gaps 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core functionality without any wasted words. It's perfectly front-loaded with the essential information.
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?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after detachment, whether there are side effects, what the response contains, or any error conditions. Given the complexity of network detachment operations, this leaves too many unanswered questions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already documents both parameters (vmId and networkId) adequately. The description doesn't add any additional semantic context about these parameters beyond what the schema provides, meeting the baseline expectation.
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 ('detach') and resource ('a network from a VM'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'liara_attach_network', but the verb 'detach' inherently contrasts with 'attach', providing some implicit 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?
The description provides no guidance on when to use this tool versus alternatives, prerequisites, or consequences. With sibling tools like 'liara_attach_network' and 'liara_delete_network', there's no indication of when detaching is appropriate versus deleting or attaching networks.
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 full burden but offers minimal behavioral insight. It implies a read-only operation ('Get'), but doesn't disclose authentication needs, rate limits, error conditions, or what 'detailed information' entails (e.g., JSON structure, included fields). For a tool with zero annotation coverage, this is insufficient to guide 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It front-loads the core action ('Get detailed information') and resource ('about a specific app'), making it immediately understandable. Every word earns its place, achieving ideal conciseness for a simple tool.
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 lack of annotations and output schema, the description is incomplete for effective use. It doesn't explain what 'detailed information' includes (e.g., app configuration, status, resources), potential side effects, or error handling. For a tool that likely returns structured data about apps, this omission leaves significant gaps in understanding the tool's behavior and outputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'name' clearly documented in the schema. The description adds no additional meaning beyond implying the parameter identifies 'a specific app'. Since the schema does the heavy lifting, the baseline score of 3 is appropriate—the description neither compensates for gaps nor provides extra value.
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 verb ('Get') and resource ('detailed information about a specific app'), making the purpose understandable. It distinguishes from sibling tools like 'liara_list_apps' by focusing on a single app rather than listing multiple. However, it doesn't specify what 'detailed information' includes (e.g., configuration, status, metrics), which prevents a perfect score.
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. It doesn't mention prerequisites (e.g., needing an existing app name), contrast with 'liara_list_apps' for discovery, or specify use cases like checking app status before operations. This lack of context leaves the agent guessing about 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool does but doesn't describe important behavioral aspects: whether this is a read-only operation, if authentication is required, rate limits, whether the URL is temporary/permanent, or what format the response takes. The description is minimal and lacks operational context.
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, efficient sentence that communicates the core purpose without any wasted words. It's appropriately sized for a simple retrieval tool and gets straight to the point.
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?
For a tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the tool returns (e.g., URL format, expiration time), doesn't mention error conditions, and provides no operational context. Given the complexity of backup systems and the lack of structured metadata, more descriptive content would be valuable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with both parameters ('databaseName' and 'backupId') clearly documented in the schema. The description doesn't add any parameter-specific information beyond what's already in the schema, so it meets the baseline for high schema coverage.
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 ('Get download URL') and resource ('for a database backup'), making the purpose immediately understandable. It doesn't specifically differentiate from sibling tools like 'liara_get_object_download_url' or 'liara_list_backups', but the resource specificity (database backup) provides adequate 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?
The description provides no guidance on when to use this tool versus alternatives like 'liara_get_object_download_url' (for objects) or 'liara_list_backups' (to find backup IDs). There's no mention of prerequisites (e.g., needing an existing backup) 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states a read operation ('Get'), implying it's non-destructive, but doesn't address authentication needs, rate limits, error handling, or response format. For a tool with zero annotation coverage, this is a significant gap in transparency 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized for a simple retrieval tool and front-loaded with the core action, making it easy to parse quickly.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain what details are returned (e.g., bucket properties, status), error scenarios, or any behavioral nuances. For a tool that likely returns structured data, this leaves the agent guessing about the result format and usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'name' clearly documented in the schema. The description doesn't add any semantic details beyond what the schema provides (e.g., format constraints, examples, or bucket naming rules). This meets the baseline score of 3 since the schema does the heavy lifting for parameter 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 clearly states the verb ('Get') and resource ('details of a specific bucket'), making the purpose understandable. It distinguishes from sibling tools like 'liara_list_buckets' by specifying retrieval of a single bucket rather than listing all. However, it doesn't specify what details are included (e.g., metadata, configuration, status), which prevents a perfect score.
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 doesn't mention prerequisites (e.g., needing the bucket name), compare it to 'liara_list_buckets' for discovery, or indicate error conditions (e.g., what happens if the bucket doesn't exist). This leaves the agent without context for proper tool 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 are provided, so the description carries full burden. It implies a read operation ('Get'), but doesn't disclose behavioral traits such as authentication requirements, rate limits, whether credentials are temporary or permanent, or what format the credentials are returned in. This leaves significant gaps 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's front-loaded with the core action and resource, making it efficient and easy to parse.
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 no annotations and no output schema, the description is incomplete. It doesn't explain what the credentials are used for, their format (e.g., access key, secret key, endpoint), or any security implications. For a tool that handles sensitive credentials, this lack of context is a significant shortfall.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'name' documented as 'The name of the bucket'. The description doesn't add any meaning beyond this, such as bucket naming conventions or constraints. Baseline 3 is appropriate since the schema does the heavy lifting.
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 ('Get') and resource ('S3-compatible credentials for a bucket'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'liara_get_bucket' or 'liara_get_object_download_url', which also involve bucket-related retrieval but for different resources.
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, it doesn't specify if this is for accessing bucket contents programmatically or for administrative purposes, nor does it mention prerequisites like bucket existence or permissions.
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 of behavioral disclosure. 'Get details' implies a read-only operation, but it doesn't confirm this or address other behaviors like authentication requirements, rate limits, error conditions, or what the response format looks like (e.g., JSON structure). For a tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves.
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, efficient sentence with no wasted words. It's front-loaded with the core action ('Get details'), making it easy to parse quickly. Every part of the sentence directly contributes to understanding the tool's function.
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 of a DNS system and the lack of annotations and output schema, the description is insufficient. It doesn't explain what 'details' include, how errors are handled, or any dependencies on other tools. For a read operation in a domain with many related tools, more context is needed to ensure proper use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear documentation for 'zoneId' and 'recordId'. The description adds no additional meaning beyond implying these are needed to fetch details, which is already evident from the schema. According to the rules, when schema coverage is high (>80%), the baseline score is 3 even without param info in the description.
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 'Get details of a DNS record' clearly states the verb ('Get') and resource ('DNS record'), making the purpose immediately understandable. However, it doesn't distinguish this tool from its sibling 'liara_get_domain' or 'liara_get_zone' which also retrieve DNS-related information, nor does it specify what 'details' include beyond what might be obvious 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 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. With siblings like 'liara_list_dns_records' (for listing records) and 'liara_get_domain'/'liara_get_zone' (for related DNS entities), there's no indication of prerequisites, such as needing to know specific IDs from a list operation first, or when this is the appropriate choice over other get 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?
With no annotations provided, the description carries the full burden of behavioral disclosure but only states the basic action. It doesn't describe what 'details' are returned, whether this is a read-only operation, what permissions are required, error conditions, or any rate limits. For a tool with no 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core purpose without any wasted words. It's appropriately sized for a simple retrieval tool and gets straight to the point.
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?
For a tool with no annotations and no output schema, the description is too minimal. It doesn't explain what kind of details are returned, the format of the response, or any behavioral characteristics. Given the complexity of mail servers and the lack of structured metadata, the description should provide more context about the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'mailId' clearly documented as 'The mail server ID'. The description doesn't add any additional parameter information beyond what's already in the schema, which is acceptable given the high schema coverage.
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 verb ('Get details') and resource ('of a mail server'), making the purpose unambiguous. However, it doesn't distinguish this tool from its sibling 'liara_list_mail_servers' which likely lists multiple mail servers rather than getting details of a specific one.
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 about when to use this tool versus alternatives. The description doesn't mention prerequisites, when this tool is appropriate, or how it differs from the 'liara_list_mail_servers' sibling tool that appears to serve a related purpose.
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 of behavioral disclosure. It implies a read-only operation ('Get'), but doesn't specify authentication needs, rate limits, error handling (e.g., invalid networkId), or what 'details' entail (e.g., JSON structure, included fields). This is inadequate for a tool with zero annotation coverage, as 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero waste—'Get details of a network' directly conveys the core action. It's appropriately sized for a simple retrieval tool and front-loaded with the essential information, making it highly efficient.
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 tool's simplicity (1 parameter, 100% schema coverage) but lack of annotations and output schema, the description is incomplete. It doesn't explain what 'details' include in the response, which is crucial since there's no output schema. For a retrieval tool, this omission leaves the agent uncertain about the return value, reducing overall completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage (networkId is described as 'The network ID'), so the baseline is 3. The description adds no additional parameter semantics beyond the schema, such as format examples (e.g., UUID) or where to find the networkId. It meets the minimum but doesn't enhance understanding.
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 verb 'Get' and resource 'details of a network', making the purpose understandable. It distinguishes from siblings like liara_list_networks (which lists multiple networks) and liara_create_network/liara_delete_network (which mutate networks). However, it doesn't specify what 'details' include (e.g., configuration, status, resources), keeping it from a perfect score.
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 explicit guidance on when to use this tool versus alternatives is provided. The agent must infer from the name and sibling tools that this retrieves details for a specific network ID, while liara_list_networks lists all networks. There's no mention of prerequisites, error conditions, or when not to use it, leaving gaps in practical 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 provided, the description carries full burden for behavioral disclosure. It states the tool retrieves a URL but doesn't mention authentication requirements, rate limits, whether the URL is temporary or permanent, or what happens if the object doesn't exist. For a tool that likely generates time-sensitive URLs, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function with no wasted words. It's appropriately sized for a straightforward retrieval operation and front-loads the core purpose.
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?
For a tool with 3 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what the download URL looks like, whether it's signed or public, how expiration works, or error conditions. Given the complexity of URL generation and the lack of structured metadata, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage, so parameters are well-documented in the structured data. The description adds no additional parameter context beyond the tool name implying 'object' relates to 'objectKey'. This meets the baseline for high schema coverage but doesn't enhance understanding.
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 ('Get download URL') and resource ('for an object'), making the purpose immediately understandable. It doesn't differentiate from sibling tools like 'liara_get_backup_download_url' or 'liara_upload_object', but it's not misleading or 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. There are related tools like 'liara_get_backup_download_url' for backups and 'liara_upload_object' for uploads, but no indication of when this specific object URL tool is appropriate or what prerequisites might be needed.
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 of behavioral disclosure. It states this is a read operation ('Get'), but doesn't mention authentication requirements, rate limits, error conditions, or what specific details are returned (e.g., status, configuration, metrics). This is inadequate for a tool with no annotation coverage.
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, efficient sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly.
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 lack of annotations and output schema, the description is insufficient. It doesn't explain what 'details' are returned (e.g., JSON structure, fields like CPU, memory, state) or behavioral aspects like permissions needed. For a tool that likely returns structured VM data, this leaves significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'vmId' clearly documented in the schema. The description doesn't add any parameter-specific context beyond what the schema provides, such as format examples or where to find the VM ID. This meets the baseline for high schema coverage.
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 verb ('Get') and resource ('details of a virtual machine'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'liara_get_app' or 'liara_get_database', which have similar 'Get details of X' patterns, so it's not fully distinctive.
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, it doesn't mention whether to use this for single VM details versus 'liara_list_vms' for listing multiple VMs, or clarify prerequisites like needing the VM ID first.
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 full burden for behavioral disclosure. It states it's a list operation, implying read-only behavior, but doesn't mention pagination behavior (despite parameters for it), rate limits, authentication needs, or what the output looks like. For a tool with 4 parameters and no annotations, this leaves significant gaps in understanding how it behaves.
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, clear sentence with zero wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place by conveying essential purpose.
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 tool's complexity (4 parameters, no output schema, no annotations), the description is incomplete. It lacks information on pagination behavior, output format, error conditions, or how it fits with sibling tools. For a list operation with multiple pagination options, more context is needed to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 4 parameters (page, perPage, limit, offset). The description adds no parameter-specific information beyond implying a list operation. This meets the baseline of 3, as the schema handles the heavy lifting, but the description doesn't enhance parameter understanding (e.g., explaining relationships between page/perPage vs limit/offset).
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 verb ('List') and resource ('all apps/projects in your Liara account'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling list tools (like liara_list_buckets or liara_list_databases), but the resource specificity is sufficient for 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?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, related tools (like liara_get_app for details on a specific app), or context for choosing this over other list operations. It's a standalone 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('List backups') but does not describe key traits such as whether this is a read-only operation, if it requires specific permissions, pagination behavior (implied by parameters but not explained), rate limits, or what the output format looks like (no output schema). This leaves significant gaps for a tool with multiple parameters.
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, efficient sentence with zero waste. It is front-loaded and directly states the tool's purpose without unnecessary elaboration, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, no annotations, no output schema), the description is incomplete. It lacks behavioral context (e.g., safety, permissions, pagination), usage guidance, and details on output format. While the schema covers parameters, the overall context for effective tool invocation is insufficient, especially for a list operation with pagination options.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so all parameters are documented in the input schema. The description does not add any additional meaning beyond the schema (e.g., it does not explain relationships between 'page/perPage' and 'limit/offset' alternatives). According to the rules, with high schema coverage, the baseline is 3 even without param info in the description.
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 verb ('List') and resource ('backups for a database'), making the purpose specific and understandable. It distinguishes from siblings like 'liara_create_backup' or 'liara_restore_backup' by focusing on listing rather than creating or restoring, but does not explicitly mention how it differs from other list tools (e.g., 'liara_list_databases').
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. It does not mention prerequisites (e.g., needing an existing database), exclusions, or comparisons to other list tools in the sibling set, leaving the agent to infer usage from 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'List' implies a read-only operation, the description doesn't clarify whether this requires specific permissions, if it's rate-limited, what the return format looks like (e.g., JSON array of database objects), or if there are any side effects. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
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, efficient sentence that directly states the tool's purpose without any fluff. It's front-loaded with the core action ('List all databases'), making it immediately scannable. Every word earns its place, and there's no redundancy or unnecessary elaboration.
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 (a list operation with pagination parameters), lack of annotations, and no output schema, the description is insufficiently complete. It doesn't explain what the output contains (e.g., database metadata fields), how pagination works in practice, or any error conditions. For a tool that returns a list of resources, more contextual information is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with all four parameters ('page', 'perPage', 'limit', 'offset') well-documented in the schema itself. The description adds no parameter-specific information beyond what the schema provides. According to the rules, when schema_description_coverage is high (>80%), the baseline score is 3 even with no param info in the description.
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 verb ('List') and resource ('all databases in your Liara account'), making the purpose immediately understandable. It distinguishes itself from sibling tools like 'liara_get_database' (singular retrieval) and 'liara_create_database' (creation). However, it doesn't specify the scope beyond 'all databases' (e.g., whether it includes deleted or archived ones), preventing a perfect score.
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. It doesn't mention when pagination parameters should be used, how this differs from 'liara_get_database' for single database retrieval, or any prerequisites (e.g., authentication requirements). The agent must infer usage from the tool name and context 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 provided, the description carries the full burden of behavioral disclosure. 'List disks' implies a read-only operation, but the description doesn't mention pagination behavior (despite the schema having pagination parameters), authentication requirements, rate limits, or what format the list returns. This leaves significant gaps for a tool with 5 parameters.
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 extremely concise at just 4 words, front-loading the essential information with zero wasted words. Every word earns its place in conveying the core functionality.
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?
For a tool with 5 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain the pagination system (page/perPage vs limit/offset alternatives), doesn't describe the return format, and provides no behavioral context. The 100% schema coverage helps but doesn't compensate for the missing behavioral information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 5 parameters thoroughly. The description adds no additional parameter information beyond what's in the schema, meeting the baseline expectation but not providing extra value.
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 ('List') and resource ('disks for an app'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'liara_get_disk' or 'liara_list_apps' which might have overlapping functionality, keeping it from a perfect score.
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. There's no mention of prerequisites, when this tool is appropriate compared to 'liara_get_disk' (which might retrieve a specific disk), or any 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?
With no annotations provided, the description carries full burden for behavioral disclosure. 'List DNS records' implies a read-only operation, but there's no information about authentication requirements, rate limits, pagination behavior (beyond what's in the schema), error conditions, or what format the returned data takes. The description doesn't add meaningful behavioral context beyond the basic operation name.
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 extremely concise - a single sentence that directly states the tool's purpose. There's zero wasted language, and the information is front-loaded. Every word earns its place in this minimal description.
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?
For a list operation with 5 parameters and no output schema, the description is insufficient. It doesn't explain what the output looks like, how pagination works (despite having page/perPage/limit/offset parameters), or any constraints on the zoneId parameter. With no annotations and no output schema, the description should provide more context about the operation's behavior and results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
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 ('List') and resource ('DNS records for a zone'), making the purpose immediately understandable. However, it doesn't distinguish this tool from its sibling 'liara_get_dns_record' which presumably retrieves a single record, leaving some ambiguity about when to use one versus the other.
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. With siblings like 'liara_get_dns_record' (likely for single records) and 'liara_list_zones' (for listing zones), there's no indication of when this list operation is appropriate versus other list or get operations in the same domain.
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 of behavioral disclosure. It states the tool lists FTP accesses but doesn't mention if this is a read-only operation, whether it requires specific permissions, how pagination works with the multiple parameters, or what the output format looks like. This leaves significant gaps 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core purpose, making it easy to parse quickly.
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 of 6 parameters (including pagination alternatives) and no annotations or output schema, the description is insufficient. It doesn't explain how to handle pagination choices (page/perPage vs limit/offset), what the returned data structure includes, or any error conditions, leaving the agent with incomplete context for proper usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so all parameters are documented in the input schema. The description doesn't add any additional meaning beyond implying that 'appName' and 'diskName' are required to scope the listing, which is already clear from the schema. This meets the baseline for high schema coverage.
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 ('List') and resource ('FTP accesses for a disk'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'liara_list_disks' or 'liara_list_objects' beyond the specific resource type, missing explicit sibling 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 is provided on when to use this tool versus alternatives. The description lacks context about prerequisites, such as needing an existing disk with FTP access configured, or comparisons to other listing tools in the sibling set.
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 of behavioral disclosure. It states it's a list operation, implying it's read-only and non-destructive, but doesn't confirm this or add context like pagination behavior (implied by parameters), rate limits, authentication needs, or return format. For a tool with 4 parameters and no annotations, this leaves significant gaps in understanding how it behaves.
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, efficient sentence ('List all mail servers') with zero wasted words. It's front-loaded with the core action and resource, making it easy to scan and understand immediately. Every word earns its place by conveying essential purpose without 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?
Given the tool's complexity (4 parameters, no annotations, no output schema), the description is incomplete. It lacks behavioral context (e.g., pagination defaults, error handling), usage guidelines, and details on return values. While the schema covers parameters well, the description doesn't add enough to help an agent invoke it correctly beyond the basic purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, fully documenting all 4 parameters (page, perPage, limit, offset) with clear meanings. The description adds no parameter information beyond what the schema provides, so it meets the baseline score of 3. However, it doesn't compensate for any gaps since there are none in the schema.
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 verb ('List') and resource ('all mail servers'), making the purpose immediately understandable. It distinguishes itself from sibling tools like 'liara_get_mail_server' (singular) by indicating it returns multiple items. However, it doesn't explicitly differentiate from other list tools like 'liara_list_apps' or 'liara_list_domains' beyond 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing existing mail servers), exclusions (e.g., not for filtered searches), or comparisons to siblings like 'liara_get_mail_server' for single-server details. The agent must infer usage from the name and context 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 provided, the description carries full burden for behavioral disclosure. 'List all networks' implies a read-only operation but doesn't specify pagination behavior (though parameters suggest it), authentication requirements, rate limits, or what 'all' means in context (e.g., all accessible networks vs all in account). The description adds minimal behavioral context beyond the obvious.
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 maximally concise at three words with zero waste. It's front-loaded with the essential action and resource. Every word earns its place, though this conciseness comes at the cost of completeness in other dimensions.
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?
For a list operation with 4 pagination parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what a 'network' is in this context, what fields are returned, error conditions, or how the pagination parameters interact. The agent lacks sufficient context to use this tool effectively beyond basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage with clear parameter documentation, so the baseline is 3. The description adds no parameter information beyond what's in the schema - it doesn't explain how pagination works, default values, or relationships between parameters like 'page/perPage' versus 'limit/offset'. The schema does the heavy lifting here.
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 'List all networks' clearly states the verb ('List') and resource ('networks'), making the purpose immediately understandable. It distinguishes this tool from siblings like 'liara_get_network' (singular) and 'liara_create_network', but doesn't specify scope or filtering details that might differentiate it from other list tools in the server.
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. There's no mention of prerequisites, when this tool is appropriate versus 'liara_get_network' for single network details, or how it relates to other list operations in the system. The agent must infer usage from 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?
No annotations are provided, so the description carries full burden. It states it's a list operation, implying read-only behavior, but doesn't disclose any behavioral traits like pagination (implied by maxKeys), rate limits, authentication requirements, error conditions, or what the output looks like (e.g., list of objects with metadata). This leaves significant gaps for an agent to understand how to use it effectively.
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, efficient sentence with zero waste: 'List objects in a bucket'. It's front-loaded and gets straight to the point without unnecessary words or complexity.
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 no annotations and no output schema, the description is incomplete. It doesn't explain what 'objects' entail (e.g., files, metadata), how results are returned, or any behavioral aspects like pagination or errors. For a tool with 3 parameters and no structured output info, this minimal description leaves too much undefined for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters (bucketName, prefix, maxKeys) with clear descriptions. The description adds no additional parameter semantics beyond implying the tool lists objects, which is already evident from the name and schema. Baseline 3 is appropriate as the schema does the heavy lifting.
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 'List objects in a bucket' clearly states the action (list) and resource (objects in a bucket). It distinguishes from siblings like liara_list_buckets (lists buckets) and liara_upload_object (uploads objects), but doesn't explicitly differentiate from other list operations like liara_list_apps or liara_list_vms, which share the same verb pattern.
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, it doesn't mention if this is the primary way to browse bucket contents or if there are other tools for filtering/searching objects. The description assumes the user knows this is for listing objects, but offers no context about 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?
With no annotations provided, the description carries full burden but lacks behavioral details. It doesn't disclose that this is a read-only operation (implied by 'List'), pagination behavior (despite parameters like 'page' and 'perPage'), rate limits, authentication requirements, or error handling. This leaves significant gaps for safe agent invocation.
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 with zero wasted words. It efficiently conveys the core purpose without redundancy or unnecessary elaboration, making it easy for an agent to parse quickly.
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 tool's complexity (5 parameters, no output schema, no annotations), the description is inadequate. It lacks details on return format (e.g., list structure, release fields), pagination defaults, error cases, or how it fits into the broader release management workflow, leaving the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are fully documented in the schema. The description adds no additional meaning beyond implying 'appName' is required (stated in schema) and that releases are scoped to an app. It doesn't explain parameter interactions (e.g., 'page' vs 'offset'), keeping it at the baseline.
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 verb ('List') and resource ('releases for an app'), making the purpose immediately understandable. It distinguishes itself from siblings like 'liara_get_release' (singular) and 'liara_deploy_release' (action), but doesn't explicitly differentiate from other list tools (e.g., 'liara_list_apps'), which keeps it from a perfect score.
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 doesn't mention prerequisites (e.g., needing an existing app), exclusions, or comparisons to similar tools like 'liara_get_release' for single releases or 'liara_list_apps' for broader 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 provided, the description carries full burden for behavioral disclosure. It states it's a listing operation, implying it's read-only and non-destructive, but doesn't elaborate on critical aspects like authentication requirements, rate limits, error conditions, or response format. For a tool with 5 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient phrase ('List VM snapshots') with zero wasted words. It's front-loaded and perfectly concise for its purpose, making it easy to parse quickly.
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 tool's complexity (5 parameters, no output schema, no annotations), the description is inadequate. It lacks details on behavior, output structure, pagination logic (how page/perPage vs. limit/offset interact), or error handling. This leaves significant gaps for an agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema fully documents all 5 parameters (vmId, page, perPage, limit, offset). The description adds no additional parameter semantics beyond implying 'VM snapshots' relates to 'vmId'. This meets the baseline for high schema coverage but doesn't enhance understanding.
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 'List VM snapshots' clearly states the verb ('List') and resource ('VM snapshots'), making the purpose immediately understandable. It distinguishes itself from siblings like 'liara_create_snapshot' and 'liara_delete_snapshot' by specifying it's a listing operation. However, it doesn't specify scope (e.g., all snapshots vs. filtered) or explicitly mention pagination, which keeps it from a perfect score.
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. It doesn't mention prerequisites (e.g., needing a VM ID), differentiate from other listing tools (e.g., 'liara_list_backups'), or indicate when not to use it. This leaves the agent with minimal 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 provided, the description carries the full burden of behavioral disclosure. It states it's a list operation, implying read-only behavior, but doesn't cover aspects like pagination details (implied by parameters but not explained), rate limits, authentication needs, or error conditions. This leaves significant gaps for an agent to understand how the tool behaves beyond basic listing.
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, clear sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and efficiently communicates the core function, making it easy to parse quickly.
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 of a list operation with pagination parameters and no output schema, the description is insufficient. It doesn't explain the return format (e.g., what 'sources' are, their structure), how pagination works with the provided parameters, or any behavioral nuances. With no annotations and missing output details, it fails to provide complete context for effective tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all parameters. The description adds no additional meaning beyond implying a list operation, which the schema already supports with parameters like 'appName', 'page', and 'perPage'. This meets the baseline for high schema coverage without extra value.
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 ('List') and resource ('uploaded sources for an app'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'liara_list_apps' or 'liara_list_objects' beyond the resource type, missing explicit sibling 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 is provided on when to use this tool versus alternatives. The description lacks context about prerequisites, such as whether the app must exist or be active, and doesn't mention any exclusions or recommended 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?
No annotations are provided, so the description carries full burden. 'List all virtual machines' implies a read-only operation but doesn't disclose behavioral traits like pagination behavior (implied by parameters but not stated), rate limits, authentication requirements, or what 'all' means in context (e.g., accessible VMs vs. all in account). The description adds minimal context beyond the basic action.
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, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse. No extraneous details or redundancy are present.
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?
For a list tool with 4 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain the return format, pagination strategy, or error conditions. While the schema covers parameters, the overall context for safe and effective use is lacking, especially given the server's complexity and many sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are fully documented in the schema. The description adds no parameter-specific information beyond implying a list operation. This meets the baseline of 3 since the schema does the heavy lifting, but the description doesn't compensate with additional context like parameter interactions or defaults.
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 verb ('List') and resource ('all virtual machines'), making the purpose unambiguous. It distinguishes from sibling tools like 'liara_get_vm' (single VM) and 'liara_create_vm' (creation), but doesn't explicitly differentiate from other list tools like 'liara_list_apps' or 'liara_list_disks' beyond 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 is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, appropriate contexts, or comparisons to similar list operations (e.g., paginated vs. filtered searches). With many sibling tools, this lack of differentiation is a significant gap.
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 of behavioral disclosure. It states 'Remove a domain from an app,' implying a destructive mutation, but fails to detail critical aspects like whether this action is reversible, requires specific permissions, affects app functionality, or has side effects (e.g., DNS changes). For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, making it easy for an agent to parse quickly. This exemplifies optimal conciseness for a simple tool.
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 tool's complexity as a destructive mutation with no annotations and no output schema, the description is insufficiently complete. It lacks details on behavioral traits (e.g., irreversibility, permissions), expected outcomes, or error conditions. While the schema covers the single parameter well, the overall context for safe and effective use is poorly addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with 'domainId' clearly documented as 'The domain ID to remove.' The description adds no additional parameter semantics beyond this, such as format examples or where to find the ID. Given the high schema coverage, the baseline score of 3 is appropriate, as the schema does the heavy lifting without extra value from the description.
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 ('Remove') and target ('a domain from an app'), making the purpose evident. It distinguishes from sibling tools like 'liara_add_domain' by specifying removal rather than addition, though it doesn't explicitly mention this contrast. The description is specific but lacks explicit sibling differentiation, which would elevate it to 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?
The description provides no guidance on when to use this tool versus alternatives, such as 'liara_delete_domain' (if it existed) or other domain-related operations. It also omits prerequisites, like whether the domain must be detached or if the app needs to be in a specific state. Without such context, the agent has minimal 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'change app plan (resize resources),' which implies a mutation that modifies app resources, but lacks critical details: whether this requires specific permissions, causes downtime, is reversible, has rate limits, or what the response looks like. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
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 extremely concise—a single phrase with zero waste. It's front-loaded with the core action and resource, making it easy to parse. Every word ('Change,' 'app plan,' 'resize resources') earns its place by contributing to understanding the tool's purpose.
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 tool's complexity as a mutation operation with no annotations and no output schema, the description is incomplete. It lacks information on behavioral traits (e.g., side effects, error handling), usage context, and output expectations. For a tool that changes app resources, this leaves significant gaps for an AI agent to operate effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for both parameters ('name' as app name, 'planID' as new plan ID). The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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 ('Change app plan') and resource ('app'), specifying it involves resizing resources. It distinguishes from some siblings like 'liara_get_app' or 'liara_delete_app' by indicating a modification rather than retrieval or deletion. However, it doesn't explicitly differentiate from other resize tools like 'liara_resize_database' or 'liara_resize_vm', which target different resources.
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. It doesn't mention prerequisites (e.g., app must exist), when not to use it (e.g., during active deployments), or direct alternatives like 'liara_update_database' for other resource types. Usage is implied only by the verb 'change,' with 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?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions 'Change database plan' which implies a mutation, but doesn't disclose critical traits like whether this requires admin permissions, causes downtime, is reversible, has rate limits, or what the response looks like. For a mutation tool with zero annotation coverage, this is inadequate.
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, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse. Every word earns its place by conveying essential information without 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?
Given the tool's complexity (mutation with no annotations, no output schema, and 2 parameters), the description is incomplete. It lacks details on behavioral traits, usage context, and output expectations. While the schema covers parameters, the description fails to provide sufficient guidance for safe and effective use, especially compared to siblings like 'liara_resize_app'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters ('name' and 'planID'). The description adds no additional meaning beyond implying these are used for plan changes. Baseline 3 is appropriate as the schema does the heavy lifting, but the description doesn't compensate with extra context (e.g., format of planID, where to find valid plans).
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 ('Change database plan') and resource ('database'), specifying it involves resizing resources. It distinguishes from siblings like 'liara_update_database' by focusing on plan changes rather than general updates. However, it could be more specific about what 'resize resources' entails (e.g., CPU, memory, storage).
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 'liara_update_database' or 'liara_resize_app'. The description implies usage for changing plans, but lacks context on prerequisites (e.g., database must be running), exclusions (e.g., not for scaling replicas), or sibling differentiation, leaving the agent to infer based on tool names 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Resize a disk' implies a mutation operation that likely requires specific permissions and may have side effects (e.g., downtime, data migration, cost implications), but none of this is mentioned. The description doesn't address whether the operation is reversible, idempotent, or has rate limits, leaving critical behavioral traits undisclosed.
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 extremely concise with just three words ('Resize a disk'), making it front-loaded and efficient. Every word earns its place by specifying the action and resource without any fluff or redundancy. This is an example of optimal brevity for a simple tool purpose.
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 of a disk resize operation (a mutation with potential side effects), no annotations, and no output schema, the description is incomplete. It fails to address critical context such as what 'resize' entails (e.g., capacity change), whether it's destructive, what permissions are needed, or what the response looks like. For a tool with three parameters and significant behavioral implications, this is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all three parameters (appName, diskName, size) clearly documented in the schema. The description adds no additional semantic context beyond implying that 'size' refers to disk capacity. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, though the description doesn't compensate for any gaps (there are none).
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 'Resize a disk' clearly states the action (resize) and resource (disk), making the purpose immediately understandable. It distinguishes from siblings like 'liara_create_disk' or 'liara_delete_disk' by specifying a modification operation rather than creation or deletion. However, it doesn't specify what aspect of the disk is being resized (capacity), which prevents a perfect score.
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. It doesn't mention prerequisites (e.g., needing an existing disk), constraints (e.g., size limits or downtime implications), or related tools like 'liara_get_disk' for checking current size. With many sibling tools available, this lack of contextual guidance is a significant gap.
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 full burden for behavioral disclosure. It states the action ('Resize') but doesn't mention critical details like whether this requires downtime, affects billing, has permission requirements, or what happens to existing data. For a mutation tool with zero annotation coverage, this is a significant gap.
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 extremely concise with just one phrase ('Resize a virtual machine (change plan)'). It's front-loaded with the core action and includes clarifying parenthetical information. Every word serves a purpose with zero waste.
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?
For a mutation tool with no annotations and no output schema, the description is inadequate. It doesn't explain what 'resize' entails operationally, potential impacts, success indicators, or error conditions. The agent lacks sufficient context to use this tool effectively beyond basic parameter passing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters (vmId and planID). The description adds no additional parameter information beyond what's in the schema, such as format examples or where to find plan IDs. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Resize') and resource ('virtual machine'), and specifies the action as changing the plan. It's specific enough to understand the core function, though it doesn't explicitly differentiate from similar tools like liara_resize_app or liara_resize_database.
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. There's no mention of prerequisites, constraints, or comparison to sibling tools like liara_resize_app or liara_resize_database, leaving the agent without context for tool 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 provided, the description carries full burden for behavioral disclosure. 'Restart a database' implies a potentially disruptive operation that may cause downtime, but the description doesn't mention this, nor does it address permissions needed, whether the restart is immediate or scheduled, or what happens to active connections. This is inadequate for a mutation tool with zero annotation coverage.
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 extremely concise - just three words that directly convey the tool's purpose. There's zero wasted language, and the information is front-loaded with the essential action and resource.
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?
For a database restart operation with no annotations and no output schema, the description is insufficient. It doesn't explain what 'restart' entails (graceful shutdown? forced restart?), potential impacts (downtime, data loss risk), success indicators, or error conditions. The agent lacks critical context to use this tool safely and effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage (the 'name' parameter is fully documented in the schema), so the baseline is 3. The description doesn't add any parameter information beyond what's in the schema, but doesn't need to since the schema already covers the single required parameter adequately.
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 ('Restart') and resource ('a database'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like liara_start_database or liara_stop_database, but the verb 'restart' is specific enough to imply a different operation from start/stop.
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 liara_start_database, liara_stop_database, or liara_update_database. There's no mention of prerequisites, consequences, or appropriate contexts for restarting versus other database 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the action ('Restart') which implies a mutation, but doesn't describe whether this requires specific permissions, if it causes downtime, what the expected response is, or any rate limits. For a mutation tool with zero annotation coverage, this is a significant gap.
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, direct sentence with zero wasted words. It's appropriately sized for a simple tool and front-loads the essential information efficiently.
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?
For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain behavioral aspects like downtime, permissions needed, or what happens on success/failure. Given the complexity of restarting a VM and the lack of structured data, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'vmId' clearly documented in the schema. The description doesn't add any parameter-specific information beyond what the schema provides, so it meets the baseline of 3 where the schema does the heavy lifting.
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 ('Restart') and resource ('a virtual machine'), making the purpose immediately understandable. It distinguishes from sibling tools like 'liara_start_vm' and 'liara_stop_vm' by specifying the restart action, though it doesn't explicitly contrast them.
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 'liara_start_vm' or 'liara_stop_vm', nor does it mention prerequisites (e.g., VM must be running) or consequences. It simply states what the tool does without 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('restore') but fails to mention critical details like whether this is a destructive operation that overwrites existing data, requires specific permissions, involves downtime, or has rate limits. This leaves significant gaps in understanding 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with zero wasted words, making it highly efficient and front-loaded. It immediately conveys the core action without unnecessary elaboration, earning full marks for conciseness.
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 of a restoration tool (potentially destructive) with no annotations and no output schema, the description is insufficient. It lacks details on behavioral traits, error conditions, or return values, making it incomplete for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear parameter definitions for 'databaseName' and 'backupId'. The description does not add any additional semantic context beyond what the schema provides, such as format examples or constraints, so it meets the baseline for high schema coverage without enhancing parameter understanding.
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 'Restore a database from a backup' clearly states the verb ('restore') and resource ('database from a backup'), making the purpose immediately understandable. It distinguishes from siblings like 'liara_create_backup' or 'liara_restore_snapshot' by specifying database restoration, though it doesn't explicitly contrast with these alternatives in the text.
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 'liara_restore_snapshot' for snapshot restoration or 'liara_update_database' for other modifications. It also lacks information on prerequisites, like needing an existing backup or database, leaving usage context unclear.
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 of behavioral disclosure. 'Restore' implies a potentially destructive write operation that could replace current VM state, but the description doesn't warn about downtime, data loss, or permission requirements. It also omits details like whether restoration is immediate, reversible, or affects VM status. For a mutation tool with zero annotation coverage, this is a significant gap.
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, efficient sentence with zero wasted words. It's front-loaded with the core action and resources, making it immediately scannable. Every word earns its place by conveying essential information without 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?
For a destructive operation (restoring a VM) with no annotations and no output schema, the description is inadequate. It doesn't explain what restoration entails (e.g., overwriting current state, potential downtime), what happens to the original VM, error conditions, or return values. Given the complexity and risk of VM restoration, more context is needed for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters (vmId, snapshotId) clearly documented in the schema. The description doesn't add any parameter details beyond what the schema provides (e.g., format examples, relationship between VM and snapshot). Given the high schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting.
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 'Restore a VM from a snapshot' clearly states the action (restore) and target resources (VM, snapshot), making the purpose immediately understandable. It distinguishes from siblings like 'liara_create_snapshot' or 'liara_restore_backup' by focusing on VM restoration from snapshots. However, it doesn't explicitly differentiate from 'liara_restore_backup' which might involve similar concepts.
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. It doesn't mention prerequisites (e.g., needing an existing snapshot), exclusions (e.g., not for backups), or comparisons to siblings like 'liara_restore_backup' or 'liara_create_vm'. This leaves the agent to infer usage context from 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?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Rollback' implies a potentially destructive state change, but the description doesn't mention whether this requires specific permissions, whether it's reversible, what happens to current deployments, or any rate limits/constraints. This is inadequate for a mutation tool with zero annotation coverage.
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, efficient sentence with zero wasted words. It's appropriately sized for a tool with two clear parameters and gets straight to the point without unnecessary elaboration.
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?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'rollback' entails operationally, what the expected outcome is, potential side effects, or error conditions. The agent would be left guessing about important behavioral aspects of this state-changing operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting both required parameters (appName and releaseID). The description doesn't add any parameter details beyond what the schema provides, but with complete schema coverage, a baseline score of 3 is appropriate as the schema does the heavy lifting.
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 ('Rollback') and target ('to a previous release'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'liara_restore_backup' or 'liara_restore_snapshot' which also involve reverting to previous states, leaving room for potential confusion about when to use this specific rollback tool.
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 'liara_restore_backup' or 'liara_restore_snapshot', nor does it mention prerequisites, dependencies, or typical use cases. An agent would have to infer usage context from 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?
With no annotations provided, the description carries full burden but only states the basic action without disclosing behavioral traits. It doesn't mention authentication needs, rate limits, error handling, or what happens on success/failure (e.g., email queued vs. sent). This is inadequate for a mutation tool with zero annotation coverage.
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, efficient sentence with zero waste, front-loading the core purpose. It's appropriately sized for a straightforward tool, though brevity contributes to gaps in other dimensions.
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 no annotations, no output schema, and a mutation tool with 6 parameters, the description is incomplete. It lacks essential context like behavioral details, usage guidelines, and output expectations, making it insufficient for safe and effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 6 parameters. The description adds no additional meaning beyond the schema, such as explaining parameter interactions (e.g., html vs. text content) or constraints. Baseline 3 is appropriate when schema does the heavy lifting.
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 'Send an email via a mail server' clearly states the action (send) and resource (email), distinguishing it from sibling tools like liara_create_mail_server or liara_restart_mail_server. However, it lacks specificity about the email content or server context, which could slightly improve 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 provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a configured mail server), exclusions, or related tools like liara_get_mail_server for checking server status, 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 provided, the description carries the full burden of behavioral disclosure. It states the action ('Enable or disable') but doesn't mention permissions required, whether changes are reversible, potential side effects, or any rate limits. For a mutation tool, this leaves significant gaps in understanding how it behaves.
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, efficient sentence that directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded, making it easy to parse quickly.
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 that this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects like permissions, side effects, or response format, leaving the agent with insufficient context to use it safely and effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with clear descriptions for both parameters ('appName' and 'enabled'). The description adds no additional meaning beyond what the schema provides, such as explaining what 'default subdomain' entails or format details. Baseline 3 is appropriate since the schema does the heavy lifting.
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 ('Enable or disable') and the resource ('default subdomain for an app'), making the purpose specific and understandable. However, it doesn't differentiate from sibling tools like 'liara_add_domain' or 'liara_remove_domain', which might handle similar domain-related operations, so it doesn't fully distinguish itself from alternatives.
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 'liara_add_domain' or 'liara_remove_domain'. It lacks context about prerequisites, exclusions, or specific scenarios, leaving the agent with no usage direction beyond the basic purpose.
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 full burden for behavioral disclosure. It states the tool performs a write operation ('Set'), but doesn't describe effects (e.g., whether it overwrites existing variables, requires app restart, has rate limits, or returns confirmation). For a mutation tool with zero annotation coverage, this leaves critical behavior undocumented.
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, efficient sentence that immediately conveys the core functionality without unnecessary words. It's appropriately sized for a straightforward tool and front-loaded with the essential action and target.
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?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't cover behavioral aspects (overwrite behavior, side effects), error conditions, or what happens after setting the variable. The 100% schema coverage helps with parameters, but overall context for safe and effective use is lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear parameter descriptions in the schema. The description adds no additional parameter context beyond implying 'single' variable (contrasting with bulk operations), but doesn't explain parameter relationships or constraints like key formatting rules beyond what's in the schema. Baseline 3 is appropriate when schema does the heavy lifting.
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 ('Set') and target ('a single environment variable for an app'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from its sibling 'liara_set_env_vars' (plural), which likely sets multiple variables, leaving some ambiguity about when to choose one over the other.
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. It doesn't mention prerequisites (e.g., app must exist), compare to 'liara_set_env_vars' for bulk operations, or indicate when environment variables should be set (e.g., during deployment vs. runtime). Usage context is implied but not stated.
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 of behavioral disclosure. While 'Set or update' implies a mutation operation, it fails to describe critical behaviors: whether this replaces all existing variables or merges with them, if it requires specific permissions, what happens on success/failure, or if there are rate limits. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
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, efficient sentence that directly states the tool's function without any fluff or redundant information. It's appropriately sized and front-loaded, making it easy to parse quickly while conveying the essential purpose.
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 of a mutation tool with no annotations and no output schema, the description is insufficient. It lacks details on behavioral traits (e.g., overwrite vs. merge behavior), error handling, return values, and differentiation from sibling tools. This leaves the agent under-informed for safe and effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with clear documentation for both parameters ('appName' and 'variables'), including nested object details for variables. The description adds no additional parameter semantics beyond what the schema already provides, such as format examples or constraints not in the schema. This meets the baseline for high schema coverage but doesn't enhance understanding.
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 ('Set or update') and target ('environment variables for an app'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'liara_set_env_var' (singular) or 'liara_delete_env_var(s)', leaving room for confusion about when to use this versus those alternatives.
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 'liara_set_env_var' (singular) or 'liara_delete_env_var(s)', nor does it mention prerequisites (e.g., app must exist) or context (e.g., whether this overwrites all existing variables). This lack of differentiation and context leaves the agent guessing about 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?
No annotations are provided, so the description carries full burden. While it mentions the return value ('returns IP when enabling'), it doesn't disclose critical behavioral traits: whether this requires specific permissions, if changes are immediate or require restart, potential downtime, rate limits, or error conditions. For a tool that modifies network configuration, this lack of transparency is significant.
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 perfectly concise - a single sentence that communicates the core functionality and key behavioral detail (return value). Every word earns its place with zero waste. It's front-loaded with the primary action and resource.
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?
For a configuration mutation tool with no annotations and no output schema, the description is inadequate. It doesn't explain what 'static IP' means in this context, whether disabling releases the IP, if there are costs or limits, or what format the returned IP has. The single behavioral detail about return values doesn't compensate for the missing context about this potentially impactful operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters (appName and enabled). The description adds marginal value by clarifying that 'enabling' returns an IP address, which provides context about the enabled=true case. However, it doesn't add meaningful semantic information beyond what's in the schema descriptions.
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 ('Enable or disable static IP') and resource ('for an app'), making the purpose immediately understandable. It distinguishes this from sibling tools by focusing specifically on IP configuration rather than general app management or other operations. However, it doesn't explicitly differentiate from other IP-related tools (none appear 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 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. It doesn't mention prerequisites (e.g., app must exist), consequences of enabling/disabling, or what happens if static IP is already enabled/disabled. With many sibling tools for app management, there's no context about when IP configuration is appropriate versus other app modifications.
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 full burden for behavioral disclosure. While 'Enable or disable' implies a mutation operation, it doesn't specify whether this requires admin permissions, if changes are reversible, potential downtime, or rate limits. For a tool that modifies app state, this leaves critical behavioral aspects undocumented.
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, efficient sentence that immediately conveys the core functionality without unnecessary words. It's appropriately sized for a simple toggle operation and front-loads the essential information.
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?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what read-only mode entails, what operations it affects, or what the response looks like. Given the complexity of modifying app state and the lack of structured documentation, more context is needed for safe usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters clearly documented in the schema (appName and enabled with boolean semantics). The description adds no additional parameter context beyond what's in the schema, so it meets the baseline for high schema coverage without adding value.
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 ('Enable or disable') and target resource ('read-only mode for an app'), making the purpose immediately understandable. However, it doesn't differentiate this tool from similar sibling tools like liara_set_env_var or liara_set_fixed_ip, which also modify app settings.
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. It doesn't mention prerequisites (e.g., app must exist), consequences of enabling read-only mode, or when to choose this over other configuration tools like liara_set_env_var. The agent must infer usage from context 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 provided, the description carries the full burden of behavioral disclosure. It states the action is to 'enable or disable' which implies a mutation/write operation, but doesn't disclose any behavioral traits like whether changes are immediate, reversible, require specific permissions, affect running instances, or have rate limits. This is a significant gap 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states exactly what the tool does with zero waste. It's appropriately sized and front-loaded with the core functionality.
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?
For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what happens when zero-downtime is enabled/disabled, whether the change affects current deployments, what the response looks like, or any error conditions. The 100% schema coverage helps with parameters but doesn't compensate for the lack of behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters (appName and enabled). The description doesn't add any meaning beyond what the schema provides - it mentions 'enable or disable' which the schema's enabled parameter description already covers. Baseline 3 is appropriate when schema does the heavy lifting.
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 ('Enable or disable') and the resource ('zero-downtime deployment for an app'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'liara_deploy_release' or 'liara_restart_app' which might also affect deployment behavior, though the 'zero-downtime' specificity helps somewhat.
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. It doesn't mention prerequisites (e.g., app must be running), consequences of enabling/disabling, or when to choose this over other deployment-related tools like 'liara_deploy_release' or 'liara_rollback_release'.
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 of behavioral disclosure. 'Start an app (scale up)' implies a mutation that changes the app's state, but it doesn't specify whether this requires admin permissions, if it's reversible (e.g., via 'stop_app'), potential downtime, or rate limits. The phrase 'scale up' hints at resource allocation but lacks detail on what that entails.
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 extremely concise—a single phrase with no wasted words. It's front-loaded with the core action ('Start an app') and includes a clarifying note ('scale up') in parentheses. Every element serves a purpose.
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?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain the outcome (e.g., what 'scale up' means operationally), error conditions, or side effects. Given the complexity of starting/scaling an app, more context is needed for the agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'name' clearly documented as 'The name of the app to start'. The description adds no additional parameter details beyond what the schema provides, so it meets the baseline for high coverage without extra value.
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 'Start an app (scale up)' clearly states the action (start) and resource (app), with 'scale up' providing additional context about the effect. It distinguishes from siblings like 'restart_app' (which implies the app is already running) and 'stop_app' (opposite action), though it doesn't explicitly name these alternatives.
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 doesn't mention prerequisites (e.g., the app must exist and be stopped), nor does it differentiate from similar tools like 'restart_app' or 'resize_app'. This leaves the agent without context for tool 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 provided, the description carries the full burden of behavioral disclosure. 'Start a virtual machine' implies a state-changing operation but reveals nothing about permissions required, side effects (e.g., billing implications), rate limits, or what happens if the VM is already running. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words—it directly states the tool's function without fluff. It's appropriately sized and front-loaded, making it easy to parse quickly.
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 tool's complexity (a state-changing operation with no output schema and no annotations), the description is incomplete. It lacks details on behavioral traits, error conditions, or return values, leaving significant gaps for an AI agent to understand how to invoke it correctly in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage (the 'vmId' parameter is documented as 'The VM ID'), so the schema does the heavy lifting. The description adds no additional parameter context beyond what's in the schema, such as format examples or where to find the VM ID, meeting the baseline for high schema coverage.
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 'Start a virtual machine' clearly states the action (start) and resource (virtual machine), making the purpose immediately understandable. It doesn't distinguish from sibling tools like 'liara_restart_vm' or 'liara_stop_vm', which would require explicit differentiation for a perfect score.
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 'liara_restart_vm' or 'liara_stop_vm', nor does it mention prerequisites (e.g., the VM must be stopped). There's no explicit when/when-not context or named alternatives, leaving usage decisions ambiguous.
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 full burden for behavioral disclosure. 'Stop an app (scale down)' implies a state-changing operation that likely reduces resources or halts execution, but it doesn't specify whether this is reversible, requires specific permissions, affects availability, or has side effects. The parenthetical adds some context but leaves critical behavioral questions unanswered.
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 extremely concise at just 4 words, with zero wasted language. The core action is front-loaded ('Stop an app'), and the parenthetical '(scale down)' efficiently adds clarifying context without unnecessary elaboration.
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?
For a state-changing operation with no annotations and no output schema, the description is insufficient. It doesn't explain what 'scale down' means operationally, what happens to the app's state, whether data is preserved, or what the tool returns. Given the complexity of stopping an application and the lack of structured metadata, more behavioral context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100% with the single parameter 'name' fully documented as 'The name of the app to stop.' The description doesn't add any parameter information beyond what the schema provides, which is acceptable given the high schema coverage. The baseline of 3 reflects adequate but minimal value addition.
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 verb ('stop') and resource ('an app'), with the parenthetical '(scale down)' providing additional context about the action. However, it doesn't explicitly differentiate from sibling tools like liara_stop_database or liara_stop_vm, which perform similar stopping operations on different resource types.
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. There's no mention of prerequisites (e.g., app must be running), consequences of stopping, or when to choose this over liara_restart_app or liara_delete_app. The agent must infer usage from context 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 provided, the description carries the full burden of behavioral disclosure. It states the action ('Stop') but doesn't describe what stopping entails (e.g., service interruption, data persistence, reversibility), required permissions, rate limits, or error conditions. This is a significant gap for a mutation tool with zero annotation coverage.
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, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place without 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?
For a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., what 'stop' means operationally), error handling, side effects, and typical response format. Given the complexity of stopping a database service, more context is needed for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage, with the single parameter 'name' documented as 'The name of the database'. The description doesn't add any additional semantic context beyond this, such as format examples or naming constraints. Baseline 3 is appropriate since the schema adequately covers the parameter.
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 ('Stop') and resource ('a database'), making the purpose immediately understandable. It distinguishes from siblings like 'liara_start_database' and 'liara_restart_database' by specifying the stop action. However, it doesn't explicitly differentiate from other stop operations (e.g., liara_stop_app) beyond 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 is provided on when to use this tool versus alternatives like 'liara_restart_database' or 'liara_delete_database'. The description lacks context about prerequisites (e.g., database must be running), consequences of stopping, or typical use cases, leaving the agent with minimal 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?
No annotations are provided, so the description carries full burden. 'Stop' implies a state change (likely from running to stopped), but it doesn't disclose behavioral traits such as whether this requires admin permissions, if it's reversible (via 'liara_start_mail_server'), potential downtime effects, or what happens to queued emails. The description is minimal and lacks critical operational context.
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, direct sentence with zero wasted words. It's front-loaded with the core action and resource, making it highly efficient and easy to parse at a glance.
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 tool's complexity (a state-changing operation with no annotations or output schema), the description is insufficient. It doesn't cover behavioral aspects like reversibility, side effects, or error conditions, leaving significant gaps for an agent to understand how to use it safely and effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'mailId' clearly documented as 'The mail server ID'. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline of 3 for adequate but not enhanced coverage.
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 ('Stop') and resource ('a mail server'), making the purpose immediately understandable. It distinguishes from siblings like 'liara_restart_mail_server' and 'liara_delete_mail_server' by specifying the stop action, though it doesn't explicitly contrast them in the description text 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?
The description provides no guidance on when to use this tool versus alternatives like restarting or deleting the mail server. It doesn't mention prerequisites (e.g., the server must be running) or consequences, 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Stop a virtual machine' implies a state-changing operation, but it doesn't describe what 'stop' entails (e.g., graceful shutdown vs. force stop), permissions required, side effects, or response behavior. This is inadequate for a mutation tool with zero annotation coverage.
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, efficient sentence with no wasted words. It's front-loaded and appropriately sized for the tool's purpose, making it easy to parse quickly.
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?
For a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavior, side effects, error conditions, and what happens post-stop (e.g., state changes, billing implications). This leaves significant gaps for an AI agent to understand the tool fully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with 'vmId' documented as 'The VM ID'. The description adds no parameter information beyond this, so it doesn't enhance semantics. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Stop a virtual machine' clearly states the action (stop) and resource (virtual machine), which is specific and unambiguous. However, it doesn't differentiate from sibling tools like 'liara_restart_vm' or 'liara_delete_vm', which also affect VMs, so it doesn't fully distinguish from alternatives.
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 restarting or deleting a VM, nor does it mention prerequisites (e.g., the VM must be running) or exclusions. It's a bare statement 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?
No annotations are provided, so the description carries full burden. It mentions 'update' implying a mutation, but doesn't disclose critical behavioral traits: whether this requires admin permissions, if changes are reversible, potential downtime during resizing/version updates, rate limits, or what the response looks like. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: 'Update database settings such as plan (resize) or version'. It's front-loaded with the core purpose and avoids unnecessary words. However, it could be slightly more structured by explicitly listing the two update types (resize vs version change) 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 this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what happens after the update (e.g., confirmation message, error handling), doesn't cover behavioral aspects like permissions or side effects, and doesn't differentiate from sibling tools. For a tool that modifies database infrastructure, more context is needed for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters (name, planID, version) with clear descriptions. The description adds minimal value by mentioning 'plan (resize)' and 'version', which aligns with schema but doesn't provide additional syntax, format details, or constraints beyond what's in the schema. Baseline 3 is appropriate when schema does the heavy lifting.
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's purpose: 'Update database settings such as plan (resize) or version'. It specifies the verb ('update'), resource ('database settings'), and key operations (resizing plan, changing version). However, it doesn't explicitly distinguish this from sibling tools like 'liara_resize_database' or 'liara_restart_database', which reduces clarity about when to use each.
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. It doesn't mention prerequisites, dependencies, or compare it to similar tools like 'liara_resize_database' (which might handle only resizing) or 'liara_restart_database' (which might handle restarts). Without this context, the agent must guess based on tool names 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?
No annotations are provided, so the description carries full burden. It states 'Upload an object to a bucket', which implies a write/mutation operation, but doesn't disclose behavioral traits like required permissions, whether it overwrites existing objects, rate limits, error conditions, or response format. For a mutation tool with zero annotation coverage, this is a significant gap, scoring a 2.
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, efficient sentence: 'Upload an object to a bucket'. It's front-loaded with the core action and resource, with zero wasted words. This is appropriately sized for a straightforward tool, earning a 5 for optimal conciseness.
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 tool's complexity (a mutation operation with 3 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like permissions, overwrite behavior, or response details, which are crucial for safe usage. With no structured fields to compensate, this scores a 2 for inadequate completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for all 3 parameters: bucketName, objectKey, and filePath. The description doesn't add any parameter semantics beyond what the schema provides (e.g., no details on path formats or constraints). With high schema coverage, the baseline is 3, as the schema does the heavy lifting.
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 'Upload an object to a bucket' clearly states the action (upload) and target resource (object to bucket), which is specific and unambiguous. It distinguishes from siblings like 'liara_create_bucket' or 'liara_delete_object', but doesn't explicitly differentiate from 'liara_upload_source', which might be similar. This earns a 4 for clear purpose without explicit sibling 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., bucket must exist), when to choose this over other upload tools like 'liara_upload_source', or any constraints. With no usage context provided, this scores a 2 for lack of guidance.
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 of behavioral disclosure. It mentions 'upload' and 'for deployment', implying a write operation that likely triggers deployment, but fails to specify critical details like whether this overwrites existing source code, requires authentication, has rate limits, or what happens after upload (e.g., automatic deployment start). This leaves significant gaps 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and resource without any wasted words. It directly communicates the tool's function in a compact form, making it easy for an agent to parse quickly.
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 tool's complexity as a write operation for deployment with no annotations and no output schema, the description is insufficient. It doesn't explain the outcome (e.g., success response, deployment status), error conditions, or how it fits into the broader deployment lifecycle. For a mutation tool in a rich ecosystem, more context is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting both parameters ('appName' and 'filePath'). The description adds minimal value beyond the schema by implying the file must be a .tar.gz archive for deployment, but doesn't elaborate on parameter interactions or constraints (e.g., app must exist, file path validity). This meets the baseline for high schema coverage.
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 ('upload') and the resource ('source code (.tar.gz file) for deployment'), making the purpose immediately understandable. It distinguishes itself from sibling tools like 'liara_upload_object' by specifying 'source code' rather than generic objects, though it doesn't explicitly contrast with 'liara_deploy_release' which might handle deployment differently.
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 'liara_deploy_release' or 'liara_upload_object', nor does it mention prerequisites such as needing an existing app or specific file format requirements. It lacks context about deployment workflows or integration with other tools.
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 of behavioral disclosure. It states a read operation ('Get details'), implying it's likely non-destructive, but doesn't confirm safety, permissions required, rate limits, or error conditions. For a tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves.
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, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded with the core action ('Get details'), making it easy to parse. Every part of the sentence earns its place by clarifying the scope ('of a specific database').
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on usage, behavioral traits, or output format. For a simple read tool, this might suffice, but it doesn't provide a complete picture for reliable agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'name' parameter fully documented. The description adds no additional semantic context beyond implying retrieval by name. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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 verb ('Get') and resource ('details of a specific database'), making the purpose evident. It distinguishes from sibling tools like 'liara_list_databases' by specifying retrieval of a single database rather than listing. However, it doesn't explicitly contrast with other 'get' tools (e.g., 'liara_get_database_connection'), so it's not fully 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a database name), contrast with 'liara_list_databases' for discovery, or specify use cases like checking status or configuration. Without such context, the agent must 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is a 'Get' operation, implying read-only behavior, but doesn't clarify if it requires specific permissions, returns sensitive credentials, has rate limits, or what format the output takes. For a tool that likely handles credentials, this lack of detail is a significant gap.
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, efficient sentence that front-loads the core purpose without unnecessary words. It directly states what the tool does and what information it retrieves, making it easy to parse quickly. Every part of the sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (retrieving connection info likely involving credentials), no annotations, and no output schema, the description is minimally adequate. It specifies the type of information returned but doesn't cover behavioral aspects like security implications or output format. For a tool with potential sensitivity, it should do more to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'databaseName' clearly documented in the schema. The description doesn't add any parameter-specific details beyond what the schema provides, such as examples or constraints. Given the high schema coverage, the baseline score of 3 is appropriate.
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 ('Get') and the resource ('database connection information'), specifying what information is retrieved (host, port, credentials). It distinguishes from siblings like 'liara_get_database' by focusing on connection details rather than general database metadata. However, it doesn't explicitly contrast with all similar tools, keeping it at a 4 rather than 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?
The description provides no guidance on when to use this tool versus alternatives. For example, it doesn't mention whether this should be used after creating a database, for configuration purposes, or in what scenarios connection info is needed. Without such context, the agent must 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?
No annotations are provided, so the description carries full burden. It states 'Get details' implying a read-only operation, but doesn't disclose behavioral traits like authentication requirements, rate limits, error conditions, or what specific details are returned. This leaves gaps 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded and appropriately sized for a simple tool, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (2 required parameters, no output schema, no annotations), the description is minimally adequate. However, it lacks completeness for a read operation with no annotations—missing details on return format, error handling, or prerequisites. It meets basic needs but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear parameter descriptions in the schema. The description adds no additional meaning beyond implying the tool fetches details for a disk identified by appName and diskName. Baseline 3 is appropriate as the schema does the heavy lifting.
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 verb ('Get') and resource ('details of a specific disk'), making the purpose evident. However, it doesn't differentiate from sibling tools like 'liara_list_disks' (which lists multiple disks) or 'liara_get_app' (which gets app details), missing explicit sibling 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 is provided on when to use this tool versus alternatives. For example, it doesn't mention using 'liara_list_disks' to find disk names first or clarify that this retrieves details for a single, pre-identified disk. The description lacks context for tool 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 provided, the description carries the full burden of behavioral disclosure. It states 'Get all environment variables,' implying a read-only operation, but doesn't specify if it requires authentication, returns paginated results, includes sensitive data, or has rate limits. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
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, efficient sentence with no wasted words, clearly front-loading the core purpose. It's appropriately sized for a simple retrieval tool, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (single parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on behavioral traits and usage context, which are needed for full completeness in a server with many sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'appName' parameter fully documented in the schema. The description doesn't add any extra meaning or context beyond what the schema provides (e.g., format examples or validation rules), so it meets the baseline of 3 for high schema coverage.
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 verb ('Get') and resource ('all environment variables for an app'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'liara_get_app' or 'liara_set_env_var', which would require mentioning it's for retrieval only versus configuration 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., app must exist), exclusions, or comparisons to siblings like 'liara_set_env_var' for setting variables or 'liara_get_app' for broader app info, leaving usage context implied at best.
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 of behavioral disclosure. 'List all storage buckets' implies a read-only operation, but it doesn't mention pagination behavior (implied by the input schema), rate limits, authentication requirements, or what the output looks like. For a list tool with zero annotation coverage, this leaves significant gaps in understanding 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core purpose and appropriately sized for a simple list operation, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (a list operation), 100% schema coverage, and no output schema, the description is minimally adequate. However, it lacks details about output format, pagination defaults, or error handling, which would be helpful for an agent to use it correctly. It's complete enough for basic understanding but leaves room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear documentation for all four parameters (page, perPage, limit, offset). The description adds no parameter information beyond what the schema provides, so it meets the baseline of 3 for high schema coverage without adding extra value.
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 'List all storage buckets' clearly states the verb ('List') and resource ('storage buckets'), making the purpose immediately understandable. However, it doesn't distinguish this tool from other list tools in the sibling set (like liara_list_apps, liara_list_databases, etc.), which follow the same pattern but target different resources.
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. There are no explicit instructions about prerequisites, context, or comparisons to other tools (e.g., liara_get_bucket for retrieving a single bucket). Usage is implied by the name and description alone, but no explicit guidelines 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?
No annotations are provided, so the description carries full burden. It states a read operation ('List'), implying it's non-destructive, but doesn't disclose critical behaviors like pagination handling (implied by parameters but not explained), authentication requirements, rate limits, or what 'attached to apps' means contextually. For a list tool with zero annotation coverage, this is a significant gap in 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste—'List all domains attached to apps' directly conveys the core action and scope. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a list operation with pagination parameters), no annotations, and no output schema, the description is minimally adequate. It identifies the resource but lacks details on return format, error handling, or the meaning of 'attached to apps.' With 100% schema coverage for inputs, it's complete enough for basic use but leaves gaps in output and behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all four parameters (page, perPage, limit, offset) well-documented in the schema. The description adds no parameter-specific information beyond what's in the schema, such as default values or interdependencies (e.g., that limit is an alternative to perPage). This meets the baseline of 3 since the schema does the heavy lifting.
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 verb ('List') and resource ('all domains attached to apps'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'liara_get_domain' or 'liara_list_dns_records' which might also involve domain-related operations, so it doesn't reach the highest level of 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?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'liara_get_domain' (likely for single domain details) and 'liara_list_dns_records' (potentially overlapping in domain context), there's no explicit or implied direction for selection. This leaves the agent to infer usage based on naming 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?
No annotations are provided, so the description carries full burden. It mentions 'available plans' but does not disclose behavioral traits like pagination behavior (implied by parameters but not described), rate limits, authentication needs, or whether it's read-only. For a list tool with zero annotation coverage, this is a significant gap in transparency.
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, efficient sentence with zero waste, front-loaded with the core action. It uses parentheses for optional clarification without redundancy, making it appropriately sized and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/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 5 parameters with full schema coverage, the description is minimally adequate. It states the purpose but lacks behavioral context and output details, making it incomplete for optimal agent use. It meets a basic threshold but has clear gaps in transparency and guidelines.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 5 parameters. The description adds minimal value by hinting at plan types in parentheses, but does not provide additional semantics beyond what the schema already covers. Baseline 3 is appropriate as the schema does the heavy lifting.
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 'List available plans (apps, databases, or VMs)' clearly states the verb ('List') and resource ('available plans'), with parenthetical clarification of plan types. It distinguishes from siblings like liara_list_apps or liara_list_vms by focusing on plans rather than specific resources, though it could be more explicit about the 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 is provided on when to use this tool versus alternatives, such as liara_get_plan for a single plan or other list tools for specific resource types. The description implies usage for listing plans but lacks explicit context or exclusions, leaving the agent to infer based on sibling names.
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 states the action ('List all DNS zones') but doesn't disclose behavioral traits like pagination behavior (implied by parameters but not described), rate limits, authentication requirements, or what 'all' entails (e.g., includes deleted zones?). This leaves gaps 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence ('List all DNS zones') that is front-loaded with the core action. There is no wasted verbiage, making it easy to parse and understand immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (a list operation with no output schema and no annotations), the description is minimally complete but lacks depth. It covers the basic purpose but misses behavioral details (e.g., pagination, return format) that would help an agent use it correctly without annotations or output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with clear descriptions for all 4 parameters (page, perPage, limit, offset). The description adds no additional parameter semantics beyond what the schema provides, which is acceptable given the high coverage, resulting in a baseline score of 3.
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 'List all DNS zones' clearly states the verb ('List') and resource ('DNS zones'), making the purpose immediately understandable. It distinguishes from siblings like 'liara_get_zone' (singular retrieval) and 'liara_create_zone' (creation), though it doesn't explicitly mention this 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 is provided on when to use this tool versus alternatives. While the name implies listing all zones, there's no mention of filtering options, prerequisites, or comparisons to other list tools (e.g., 'liara_list_dns_records' for records within zones). The description lacks 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, so the description carries full burden. It states 'Get' which implies a read operation, but doesn't disclose behavioral traits like authentication requirements, rate limits, error conditions, or what 'comprehensive' entails. The description is too vague to provide meaningful transparency beyond the basic operation.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized for a simple retrieval tool and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema), the description is minimally adequate. However, without annotations and with sibling tools that perform similar 'get' operations, it lacks context about what makes this tool unique or when to use it. The description covers the basic purpose but leaves gaps in usage and behavioral context.
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?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the absence of parameters. The description doesn't need to add parameter information, and it appropriately doesn't mention any parameters. This meets the baseline expectation for a parameterless tool.
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's purpose: 'Get comprehensive user information including plans and teams.' It specifies the verb ('Get') and resource ('user information') with additional details about what information is included. However, it doesn't explicitly differentiate from sibling tools like 'liara_get_app' or 'liara_get_plan' beyond 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context for retrieving user information, or how it differs from other 'get' tools in the sibling list. The agent must infer usage 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.

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:

[![liara-mcp MCP server](https://glama.ai/mcp/servers/razavioo/liara-mcp/badges/card.svg)](https://glama.ai/mcp/servers/razavioo/liara-mcp)

Score Badge

Copy to your README.md:

[![liara-mcp MCP server](https://glama.ai/mcp/servers/razavioo/liara-mcp/badges/score.svg)](https://glama.ai/mcp/servers/razavioo/liara-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/razavioo/liara-mcp'

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