DuploCloud Docker MCP Server

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose targeting specific resources (buckets, databases, ECS services, hosts, services, tenants) with well-defined actions (create, delete, get, list, update, restart, reboot, run). There is no ambiguity or overlap between tools, as each combines a resource type with a unique operation.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern with snake_case, such as bucket_create, database_list, ecs_service_update, host_reboot, service_restart, and tenant_delete. The naming is uniform across all 31 tools, making them predictable and easy to understand.
Tool Count3/5
With 31 tools, the count is borderline high for a single server, potentially feeling heavy. However, given the broad scope covering multiple AWS services (S3, RDS, ECS, EC2) and DuploCloud-specific operations, it is reasonable but could be overwhelming for agents due to the volume.
Completeness4/5
The tool set provides comprehensive CRUD/lifecycle coverage for each resource type (buckets, databases, hosts, services, tenants) and includes additional operations like restart, reboot, and run. Minor gaps exist, such as no update for tenants and limited ECS service operations (e.g., missing create), but core workflows are well-covered.
Average 3.1/5 across 31 of 31 tools scored.
See the Tool Scores section below for per-tool breakdowns.
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

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 creates a bucket but fails to mention critical traits such as required permissions, whether the operation is idempotent, potential side effects (e.g., costs or conflicts), or response behavior (though an output schema exists). 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with the core purpose in the first sentence and parameters listed concisely. There is minimal waste, though the parameter explanations could be slightly more informative without sacrificing brevity.
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 mutation with 2 parameters), no annotations, and an output schema (which reduces need to explain returns), the description is moderately complete. It covers the basic purpose and parameters but lacks behavioral context and usage guidelines, making it adequate but with clear gaps for safe 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 0%, so the description must compensate. It lists both parameters (tenant_id and name) with brief explanations, adding meaning beyond the bare schema. However, it does not provide details like format constraints (e.g., bucket naming rules) or dependencies, only partially addressing the coverage gap.
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 a new S3 bucket') and resource ('in a DuploCloud tenant'), providing specific verb+resource. However, it does not explicitly differentiate from sibling tools like bucket_update or database_create, which would require mentioning uniqueness such as being the only bucket creation tool or contrasting with update 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 lacks context on prerequisites (e.g., tenant existence), exclusions (e.g., when not to create a bucket), or comparisons to siblings like bucket_update or database_create, 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 full burden but only states it retrieves details without mentioning behavioral aspects like authentication requirements, error conditions (e.g., if bucket doesn't exist), rate limits, or what 'details' specifically includes. This leaves significant gaps for a read operation.
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 efficiently structured with a clear opening sentence followed by parameter explanations. However, the 'Args:' section could be integrated more seamlessly, and some redundancy exists (e.g., 'bucket' repeated).
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 2 parameters with 0% schema coverage and an output schema present, the description provides basic parameter semantics but lacks behavioral context. The output schema likely covers return values, but the description doesn't mention authentication, errors, or usage context, making it minimally adequate but incomplete.
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 0%, but the description adds basic semantic context for both parameters ('tenant ID containing the bucket' and 'bucket name to look up'), clarifying their roles. However, it doesn't provide format examples, constraints, or relationships between parameters beyond what's minimally required.
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 details') and resource ('specific S3 bucket'), making the purpose immediately understandable. However, it doesn't differentiate from sibling 'bucket_list' which also retrieves bucket information but for multiple buckets, 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 like 'bucket_list' for listing all buckets or 'bucket_update' for modifying bucket details. The description only states what it does without context about appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 this is an update operation (implying mutation) but doesn't disclose important behavioral traits: whether this requires specific permissions, if changes are reversible, what happens to other bucket settings not mentioned, rate limits, or error conditions. The description only covers the basic action without the operational context needed for safe use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the core purpose in the first sentence. The Args section is structured but could be more integrated. There's minimal waste, though the formatting with separate 'Args:' section creates some structural separation that isn't ideal. Every sentence earns its place by providing necessary parameter 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 this is a mutation tool with no annotations, 3 parameters, 0% schema coverage, but with an output schema present, the description is moderately complete. The output schema existence means return values don't need explanation in the description. However, for a configuration update tool affecting cloud storage, the description lacks important context about side effects, permission requirements, and what constitutes valid updates. It's adequate but has clear gaps for safe 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 0%, so the description must compensate. It provides basic semantic meaning for all three parameters: tenant_id ('The tenant ID containing the bucket'), name ('The bucket name to update'), and versioning ('Enable or disable versioning'). However, it doesn't explain parameter interactions, format requirements (e.g., bucket naming rules), or what 'optional' means for versioning (default behavior, null handling). The description adds value but doesn't fully compensate for the schema coverage gap.
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 ('Update') and resource ('S3 bucket configuration'), making the purpose immediately understandable. It distinguishes from siblings like bucket_create, bucket_delete, and bucket_get by specifying it's for updating existing buckets rather than creating, deleting, or retrieving them. However, it doesn't fully differentiate from database_update or service_update which perform similar update operations on 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., bucket must exist), when not to use it, or clarify relationships with sibling tools like bucket_get (to check current configuration) or bucket_delete (for removal). The agent must 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool deletes a database instance, implying a destructive, irreversible action, but doesn't cover critical aspects like permissions required, confirmation prompts, rate limits, deletion time, or what happens to associated data. For a destructive tool with zero annotation coverage, this leaves significant behavioral gaps that could lead to misuse.
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 appropriately sized and front-loaded, with the main purpose stated concisely in the first sentence. The Args section adds necessary parameter explanations without redundancy. There's no wasted text, but the structure could be slightly improved by integrating parameter details more seamlessly rather than as a separate block.
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 (destructive deletion with 2 parameters), lack of annotations, and presence of an output schema (which handles return values), the description is partially complete. It covers the basic action and parameters but misses important contextual details like safety warnings, error conditions, or dependencies. For a deletion tool, this is a moderate gap that could impact 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 0%, so the description must compensate for undocumented parameters. It adds semantic context by explaining that 'tenant_id' identifies the tenant containing the database and 'name' is the database instance identifier to delete, which clarifies beyond the schema's generic titles ('Tenant Id', 'Name'). However, it doesn't provide format details (e.g., ID patterns, name constraints) or examples, leaving some ambiguity for the two required 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 ('Delete') and resource ('RDS database instance from a DuploCloud tenant'), making the purpose immediately understandable. It distinguishes from siblings like database_create, database_get, database_list, and database_update by specifying deletion rather than creation, retrieval, listing, or updating. However, it doesn't explicitly differentiate from other delete tools like bucket_delete or tenant_delete, which slightly limits 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., database must exist), exclusions (e.g., cannot delete if in use), or comparisons to siblings like database_list (to identify databases) or database_get (to check status). Without such context, an agent might struggle to determine 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 the full burden. It mentions 'resizing' which implies a mutation that could be disruptive (e.g., downtime, cost changes), but doesn't disclose critical behavioral traits like whether the operation is reversible, requires specific permissions, has rate limits, or what happens if size is null. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the purpose clearly, and the Args section is structured for readability. There's no wasted text, though it could be slightly more concise by integrating the example into the main sentence. Every sentence adds value.
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 (mutation with 3 parameters, no annotations, but has an output schema), the description is moderately complete. It covers the basic action and parameters but lacks behavioral details (e.g., side effects, error conditions) and doesn't leverage the output schema's existence to omit return value explanations. For a mutation tool, more context on risks or outcomes would improve 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 0%, so the description must compensate. It provides a brief explanation for each parameter (tenant_id, name, size) and an example for size ('e.g. db.t3.small'), which adds meaning beyond the schema's type definitions. However, it doesn't fully cover semantics like format constraints for tenant_id or name, or the implications of size being nullable (default null). The description partially compensates but leaves 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 clearly states the verb ('Update') and resource ('RDS database instance'), and specifies the current capability ('Currently supports resizing'). It distinguishes from siblings like database_create, database_delete, and database_get by focusing on modification rather than creation, deletion, or retrieval. However, it doesn't explicitly differentiate from database_list or other update tools like bucket_update or service_update 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., database must exist), exclusions (e.g., cannot resize while in certain states), or comparisons to siblings like database_get (for checking current size) or database_create (for initial setup). Usage is implied only by the action and resource.
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 states it's a list operation (implied read-only), but doesn't cover pagination, rate limits, authentication needs, error conditions, or what 'all' means in practice (e.g., all services regardless of state).
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 efficiently structured with a clear purpose statement followed by parameter documentation. Both sentences earn their place by providing essential information without redundancy, though the parameter section could be integrated more seamlessly.
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, list operation) and the presence of an output schema (which handles return values), the description is minimally adequate. However, it lacks context about sibling tools and behavioral details, leaving gaps 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?
Schema description coverage is 0%, but the description adds basic semantic context for the single parameter ('tenant_id: The tenant ID to list ECS services for'). This clarifies the parameter's role, though it doesn't provide format examples or constraints. With 0% schema coverage, this partial compensation justifies a baseline score.
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 all') and resource ('ECS services in a DuploCloud tenant'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'service_list' or 'ecs_task_list', which would require explicit comparison to achieve 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 sibling tools like 'service_list' (which might list different service types) or 'ecs_task_list' (which lists tasks rather than services), 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is an update operation but doesn't mention critical details like required permissions, whether it's destructive (e.g., causes service downtime), rate limits, or what the output contains. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the core purpose, followed by a structured 'Args' section. There's no redundant information, though the parameter descriptions could be more detailed without sacrificing conciseness.
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 (mutation of a cloud service), lack of annotations, and 0% schema description coverage, the description is incomplete. It covers the basic purpose and parameters but misses behavioral context and usage guidelines. The presence of an output schema helps, but the description doesn't reference it or explain what to expect from the update 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 description includes an 'Args' section that lists and briefly describes all three parameters, adding meaning beyond the schema (which has 0% description coverage). However, the descriptions are minimal (e.g., 'The tenant ID containing the ECS service' for tenant_id) and don't provide format examples or constraints. This partially compensates for the schema gap but isn't comprehensive.
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 the image of an ECS service's task definition.' This specifies the verb ('update'), resource ('ECS service's task definition'), and target field ('image'). However, it doesn't explicitly differentiate from sibling tools like 'service_update' or 'ecs_service_delete', which would require 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. It doesn't mention prerequisites (e.g., existing ECS service), exclusions (e.g., not for creating new services), or comparisons to siblings like 'ecs_service_list' or 'service_update'. Without this 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 the action ('Run') but lacks critical details: it doesn't specify permissions required, whether this is a one-time execution or managed service, potential side effects (e.g., resource consumption, costs), or error handling. For a tool that likely involves infrastructure changes, 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 appropriately sized and front-loaded, with the core purpose in the first sentence and parameter details following in a structured list. There's no wasted text, but it could be slightly more concise by integrating the default value note into the 'replicas' explanation rather than a separate sentence.
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 (running ECS tasks), lack of annotations, and an output schema (which exists but isn't shown), the description is moderately complete. It covers the basic action and parameters but misses behavioral context like execution outcomes, error cases, or integration with sibling tools. The output schema likely handles return values, reducing the burden, but more operational guidance 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 0%, so the description must compensate. It adds meaning by explaining each parameter's role: 'tenant_id' specifies the context, 'family_name' identifies the task definition, and 'replicas' indicates the number of instances with a default. However, it doesn't provide format details (e.g., what a 'family_name' looks like), constraints (e.g., valid ranges for 'replicas'), or examples, leaving some ambiguity.
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 ('Run an ECS task') and the resource ('from a task definition family'), making the purpose immediately understandable. It distinguishes from sibling tools like 'ecs_task_list' or 'ecs_task_def_list' by focusing on execution rather than listing. However, it doesn't explicitly differentiate from other ECS-related siblings like 'ecs_service_update' in terms of scope or 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 an existing task definition), compare it to sibling tools like 'ecs_service_update' for service-based tasks, or specify scenarios where running a task is appropriate over other operations. Usage is implied but not explicitly defined.
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 ('Reboot') but does not cover critical aspects like permissions required, whether the reboot is graceful or forced, expected downtime, or error handling, leaving 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose, followed by parameter details in a structured 'Args' section. It is efficient with minimal waste, though slightly verbose in formatting.
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 mutation with 2 parameters), no annotations, and an output schema (which reduces need to explain returns), the description is moderately complete. It covers the action and parameters but lacks behavioral details and usage context, making it adequate but with 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 0%, so the description must compensate. It lists the parameters ('tenant_id' and 'name') with brief explanations, adding some meaning beyond the schema. However, it does not detail format constraints or examples, resulting in a baseline score.
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 ('Reboot') and resource ('a host in a DuploCloud tenant'), making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like 'service_restart' or 'host_delete', which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'service_restart' for services or 'host_delete' for removal. The description lacks context about prerequisites or exclusions, 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?
No annotations are provided, so the description carries the full burden. It states the tool deletes a service, implying a destructive operation, but lacks critical behavioral details such as permissions required, whether deletion is irreversible, effects on dependencies, or error handling. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose in the first sentence, followed by parameter explanations. It is appropriately sized with no redundant information, though it could be slightly more structured for clarity.
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 as a destructive operation with no annotations, 0% schema coverage, but an output schema present, the description is minimally adequate. It covers the basic action and parameters but lacks behavioral context and usage guidelines, making it incomplete 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?
Schema description coverage is 0%, so the description must compensate. It adds basic semantics by explaining 'tenant_id' as 'The tenant ID containing the service' and 'name' as 'The service name to delete', which clarifies parameter roles. However, it does not provide format details, constraints, or examples, leaving gaps in 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 ('Delete') and resource ('a service from a DuploCloud tenant'), making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like 'ecs_service_delete' or 'service_delete' (if present), which would require clarification on what type of service is being deleted.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'ecs_service_delete' and 'service_delete' (implied from context), it fails to specify distinctions such as service types or contexts, 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 full burden for behavioral disclosure. It states this is a 'Get' operation, implying read-only behavior, but doesn't clarify authentication needs, rate limits, error conditions, or what 'details' include. For a tool with no 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the core purpose in the first sentence. The 'Args' section is structured but could be more integrated; overall, it's efficient with minimal waste, though slightly fragmented.
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 2 parameters with 0% schema coverage and an output schema present, the description is moderately complete. It covers the basic purpose and parameters but lacks behavioral context and usage guidelines. The output schema reduces the need to explain return values, but overall completeness is adequate with 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 0%, so the description must compensate. It adds minimal semantics by naming the parameters ('tenant_id' and 'name') and briefly describing them ('The tenant ID containing the service' and 'The service name to look up'), but doesn't provide format examples, constraints, or contextual meaning beyond basic labels. This partially compensates but remains basic.
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 ('specific service by name'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'service_list' (which lists services) or 'service_create/delete/update' (which modify services), missing explicit sibling distinction that would warrant 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. It doesn't mention when to use 'service_get' (for single service details) versus 'service_list' (for multiple services) or other sibling tools, nor does it specify prerequisites or exclusions, 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 full burden for behavioral disclosure. While it mentions 'triggering a rolling redeployment' (which implies some availability considerations), it doesn't address critical aspects like: whether this requires elevated permissions, potential downtime or service disruption, idempotency, rate limits, or what happens if the service doesn't exist. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with the core purpose stated first, followed by parameter documentation. Both sentences earn their place - the first establishes the action and behavioral nuance (rolling redeployment), the second documents parameters. No wasted words, though it could be slightly more front-loaded with critical behavioral 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 this is a mutation tool with no annotations, 0% schema description coverage, but with an output schema (which reduces need to describe return values), the description is moderately complete. It covers the basic action and parameters but lacks important context about permissions, side effects, error conditions, and differentiation from sibling tools that would be needed for safe and appropriate 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 description includes an 'Args' section that documents both parameters (tenant_id and name) with brief explanations, compensating for the 0% schema description coverage. However, the explanations are minimal ('The tenant ID containing the service', 'The service name to restart') and don't provide format examples, constraints, or validation rules that would be helpful for correct invocation.
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 a service') and specifies it triggers 'a rolling redeployment', which adds important context about the restart mechanism. However, it doesn't explicitly differentiate this tool from sibling tools like 'host_reboot' or 'service_update', which could involve similar operations on related 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. With sibling tools like 'service_update' (which might include restart functionality) and 'host_reboot' (which operates at a different resource level), there's no indication of when this specific restart operation is appropriate versus other maintenance or update 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 states 'Create a new DuploCloud tenant' which implies a write/mutation operation, but doesn't specify permissions required, whether the operation is idempotent, potential side effects, or error conditions. For a creation tool with zero annotation coverage, this leaves significant behavioral gaps unaddressed.
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 appropriately concise with a clear purpose statement followed by parameter explanations. The two-sentence structure is efficient with no wasted words. The Args section is well-formatted but could be more integrated with the main description for better flow.
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 this is a creation tool with no annotations, 2 parameters, 0% schema description coverage, but with an output schema present, the description is minimally adequate. It covers what the tool does and what parameters mean at a basic level, but lacks behavioral context, usage guidance, and detailed parameter semantics that would be helpful for proper 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 description provides basic parameter explanations ('Name for the new tenant', 'The infrastructure plan ID to associate with'), which adds some meaning beyond the schema's 0% description coverage. However, it doesn't elaborate on format constraints, valid plan_id values, or character limits for account_name. With two parameters and low schema coverage, the description provides minimal but adequate compensation.
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 ('DuploCloud tenant'), making the purpose immediately understandable. It distinguishes this tool from sibling tools like tenant_delete, tenant_get, and tenant_list by specifying creation rather than deletion, retrieval, or listing operations. However, it doesn't explicitly differentiate from other creation tools like bucket_create or database_create 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, when not to use it, or how it relates to sibling tools like tenant_list (for checking existing tenants) or tenant_delete (for removal). The agent must infer usage from the name and description alone without explicit 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 the destructive action ('Delete') but lacks critical details: it doesn't warn about irreversible deletion, specify permissions required, describe cleanup of associated resources (e.g., tasks, load balancers), or mention confirmation prompts. This 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the core purpose, followed by a structured 'Args:' section. There's no redundant information, though it could be slightly more concise by integrating the parameter explanations into the main text without the separate heading.
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 (destructive deletion with 2 parameters), no annotations, and an output schema (which handles return values), the description is minimally adequate. It covers the basic action and parameters but lacks safety warnings, usage context, and behavioral details needed for responsible invocation, leaving gaps in completeness.
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?
Schema description coverage is 0%, so the description must compensate. It adds meaningful context for both parameters: 'tenant_id' is explained as 'The tenant ID containing the ECS service' (implying a container relationship), and 'name' as 'The ECS service name to delete' (clarifying it's the identifier). This goes beyond the schema's basic titles ('Tenant Id', 'Name'), providing useful semantic 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 ('Delete') and resource ('an ECS service from a DuploCloud tenant'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'service_delete' or 'ecs_task_list', which would require mentioning it specifically targets ECS services rather than generic services or other ECS 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., the service must exist), exclusions (e.g., cannot delete if running tasks), or refer to related tools like 'ecs_service_list' for verification or 'ecs_service_update' for modification instead.
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 describes a read-only list operation, which implies safety, but fails to mention any constraints like pagination, rate limits, permissions required, or what the output includes. This leaves significant gaps 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the main purpose in the first sentence, followed by parameter details. It avoids unnecessary verbosity, though the structure could be slightly improved by integrating the parameter explanation more seamlessly.
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) and the presence of an output schema, the description is minimally adequate. However, with no annotations and incomplete behavioral details, it doesn't fully cover aspects like error handling or usage context, leaving room for improvement.
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 description adds a brief explanation for the single parameter ('tenant_id: The tenant ID to list task definitions for'), which provides meaning beyond the schema's basic type information. Since schema description coverage is 0%, this compensates well, though it could be more detailed (e.g., format or source of the ID).
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 all') and resource ('ECS task definition families in a DuploCloud tenant'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'ecs_task_list' or 'ecs_service_list', which reduces 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, such as 'ecs_task_list' or 'ecs_service_list', nor does it mention prerequisites or exclusions. It only 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?
No annotations are provided, so the description carries the full burden. It states it 'lists' tasks, implying a read-only operation, but doesn't disclose behavioral traits like pagination, rate limits, authentication needs, error conditions, or what 'running' means (e.g., active vs. all tasks). This leaves significant gaps 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with the core purpose stated first in a single sentence, followed by parameter details. There's no wasted text, though the structure could be slightly improved by integrating the 'Args' section more seamlessly.
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 (2 parameters, no annotations, but with an output schema), the description is minimally adequate. It covers the purpose and parameters but lacks behavioral context and usage guidelines. The output schema reduces the need to explain return values, but more completeness is needed for safe operation.
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 description includes an 'Args' section that explains both parameters ('tenant_id' and 'service_name') with brief semantics, adding meaning beyond the input schema (which has 0% description coverage). This compensates well for the schema's lack of descriptions, though it could provide more detail (e.g., format examples).
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 ('running ECS tasks for a specific service'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'ecs_service_list' or 'ecs_task_def_list', which list 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 sibling tools like 'ecs_service_list' (for listing services) or 'ecs_task_run' (for running tasks), nor does it specify prerequisites or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Terminate' implies a destructive, irreversible action, but the description doesn't specify consequences (e.g., data loss, downtime), permissions required, rate limits, or error conditions. For a deletion tool with zero annotation coverage, this lack of critical safety and operational details 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the core purpose, followed by a brief Args section that efficiently lists parameters. There's no redundant information, and every sentence adds value. However, the structure could be slightly improved by integrating parameter explanations into the main flow rather than a separate block.
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 (destructive operation with 2 parameters), no annotations, and an output schema (which handles return values), the description is partially complete. It covers the basic action and parameters but lacks critical behavioral details like safety warnings or usage context. The output schema mitigates some gaps, but for a deletion tool, more guidance is needed to be fully adequate.
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?
Schema description coverage is 0%, so the description must compensate. It adds meaningful context by explaining that tenant_id identifies 'The tenant ID containing the host' and name is 'The host name to delete,' clarifying the purpose and relationship of each parameter beyond their basic types. This adequately covers both parameters, though it doesn't detail format constraints (e.g., string patterns).
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 ('Terminate') and resource ('a host in a DuploCloud tenant'), making the purpose unambiguous. It distinguishes from siblings like host_create, host_get, host_list, and host_reboot by specifying deletion. However, it doesn't explicitly contrast with bucket_delete or service_delete, which are similar destructive operations on different resources, leaving some sibling differentiation incomplete.
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 host must exist), exclusions (e.g., not for stopping vs. deleting), or related tools like host_reboot for non-destructive actions. Without such context, an agent might misuse it in scenarios where less destructive options are available.
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 deletion operation, implying it's destructive and non-read-only, but doesn't elaborate on critical aspects like whether deletion is irreversible, what happens to associated resources, permissions required, or error conditions. 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 extremely concise and well-structured: a clear purpose statement followed by a brief parameter explanation. Every sentence adds value with no wasted words, and it's front-loaded with the main action.
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 this is a destructive tool with no annotations, 0% schema description coverage, but with an output schema (which handles return values), the description is minimally adequate. It covers the basic purpose and parameter meaning, but lacks critical behavioral context (e.g., irreversibility, side effects) that would be expected for a deletion 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 0%, but the description adds basic semantics for the single parameter 'name' by explaining it's 'The tenant name to delete.' This clarifies the parameter's purpose beyond the schema's title 'Name.' However, it doesn't provide format details (e.g., string constraints, case sensitivity) or examples, leaving some ambiguity.
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 target resource ('a DuploCloud tenant by name'), which is specific and unambiguous. However, it doesn't explicitly differentiate from sibling tools like tenant_get or tenant_list, though the destructive nature is implied by the verb 'Delete'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., tenant must exist), consequences (e.g., irreversible deletion), or suggest using tenant_list or tenant_get first to verify the tenant. The description only states what it does, not when or why to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action. It doesn't disclose critical behavioral traits like whether deletion is irreversible, requires specific permissions, has side effects on related resources, or follows AWS S3 deletion rules (e.g., bucket must be empty).
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 and well-structured: a clear purpose statement followed by brief parameter explanations. Every sentence earns its place with no redundant 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 this is a destructive operation with no annotations and 2 parameters, the description is minimally adequate but incomplete. It explains what the tool does and parameters, but lacks crucial context about deletion behavior, safety, and output. The presence of an output schema helps, but doesn't fully compensate for missing behavioral details.
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 description adds meaningful context for both parameters: 'tenant_id' is explained as 'The tenant ID containing the bucket' and 'name' as 'The bucket name to delete'. With 0% schema description coverage, this compensates well by clarifying what each parameter represents, though it doesn't specify format constraints.
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 ('S3 bucket from a DuploCloud tenant'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'bucket_update' or 'bucket_get' beyond the obvious action difference.
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., bucket must be empty), consequences, or when to choose deletion over other bucket operations like 'bucket_update'.
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 authentication requirements, rate limits, pagination behavior, error conditions, or what format the output takes. For a tool with 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise and well-structured. The first sentence clearly states the tool's purpose, followed by a clean parameter explanation. Every word earns its place with zero redundancy or 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 simplicity (single parameter, list operation) and the presence of an output schema, the description is minimally adequate. However, for a tool with no annotations, it should ideally provide more behavioral context about authentication, error handling, or output characteristics. The output schema existence reduces but doesn't eliminate the need for some operational 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 description provides clear semantic meaning for the single parameter (tenant_id: 'The tenant ID to list buckets for'), which adds value beyond the schema's 0% description coverage. While there's only one parameter, the description fully explains its purpose and relationship to the operation, compensating for the schema's lack of parameter 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 ('List all') and resource ('S3 buckets in a DuploCloud tenant'), making the purpose immediately understandable. It distinguishes from siblings like bucket_create, bucket_delete, bucket_get, and bucket_update by specifying it's a listing operation. However, it doesn't explicitly differentiate from other list tools like database_list or service_list 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 when this tool is appropriate compared to bucket_get (for single bucket details) or other list tools for different resources. There's no discussion of prerequisites, limitations, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is a read operation ('Get details'), implying it's non-destructive, but doesn't cover aspects like authentication needs, rate limits, error handling, or what 'details' include. For a tool with no annotations, this leaves significant behavioral gaps, though it correctly indicates a read action.
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 appropriately sized and front-loaded, with the main purpose stated first ('Get details of a specific host by name') followed by parameter explanations. The two-sentence structure is efficient with minimal waste, though the parameter section could be slightly more integrated. It earns its place by clarifying parameters given low schema coverage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/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 parameters, no nested objects), no annotations, and the presence of an output schema (which handles return values), the description is reasonably complete. It covers the purpose and parameters adequately, though it lacks behavioral details like error cases or performance hints. The output schema reduces the need for return value explanation, making this sufficient for basic use.
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?
Schema description coverage is 0%, so the description must compensate. It adds meaning by explaining that 'tenant_id' is 'The tenant ID containing the host' and 'name' is 'The host name to look up', which clarifies the purpose of each parameter beyond their titles ('Tenant Id', 'Name'). This adequately compensates for the lack of schema descriptions, though it doesn't provide format examples or constraints.
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 with 'Get details of a specific host by name', which includes a specific verb ('Get') and resource ('host'). It distinguishes from sibling tools like host_list (which lists hosts) and host_create/delete/reboot (which modify hosts), though it doesn't explicitly mention these distinctions. The purpose is clear but lacks 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 sibling tools like host_list for listing all hosts or host_create for creating a new host, nor does it specify prerequisites or exclusions. The only implied context is retrieving details for a known host, but this is basic and insufficient for explicit usage guidelines.
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 'Create' implies a write operation, it doesn't address important behavioral aspects like required permissions, whether the operation is idempotent, what happens on failure, rate limits, or what the output contains. The description provides minimal behavioral 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 efficiently structured with a clear purpose statement followed by a well-organized Args section. Every sentence adds value, and there's no redundant or unnecessary information. The formatting makes parameters easy to scan and understand.
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 this is a creation tool with no annotations but with an output schema (which handles return values), the description covers the basic action and parameters adequately. However, for a mutation operation, it should ideally address more behavioral aspects like permissions, idempotency, or error handling to be fully complete.
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?
With 0% schema description coverage, the description compensates well by explaining all 4 parameters in the Args section. It clarifies tenant_id context, name purpose, image format with an example, and replicas default value. This adds significant meaning beyond what the bare schema provides.
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 a new service') and resource ('in a DuploCloud tenant'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like service_update or service_restart, which would require mentioning this is for initial creation only.
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 tenant), when not to use it (e.g., for updating existing services), or refer to sibling tools like service_update for 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. It states this is a listing operation but doesn't mention whether it's paginated, what format the output takes, whether it requires specific permissions, or any rate limits. For a tool with no 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 perfectly concise with zero wasted words. The first sentence states the core purpose, and the Args section cleanly documents the parameter. Every sentence earns its place, and the information is front-loaded appropriately.
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 has an output schema (which handles return values), 0% schema description coverage, and no annotations, the description is minimally adequate. It covers the basic purpose and parameter but lacks behavioral context about permissions, pagination, or error conditions that would be helpful for a listing operation.
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?
With 0% schema description coverage, the description fully compensates by clearly documenting the single parameter 'tenant_id' and its purpose ('The tenant ID to list services for'). This adds essential meaning beyond what the bare schema provides, though it doesn't specify format or constraints for the tenant_id 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 ('List') and resource ('services in a DuploCloud tenant'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from sibling tools like 'service_get' or 'ecs_service_list', which would require more specific scope information to earn 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 'service_get' (for single service) or 'ecs_service_list' (for ECS-specific services). It mentions the required tenant_id parameter but offers no context about prerequisites, filtering capabilities, or comparison with other listing 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. It states this is a read operation ('Get details'), which implies it's non-destructive, but doesn't disclose any behavioral traits like authentication needs, rate limits, error conditions, or what 'details' include. For a tool with no annotations, 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 appropriately sized and front-loaded: the first sentence clearly states the purpose, and the 'Args' section efficiently documents the parameter. Every sentence earns its place with no wasted words, 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 (1 parameter, no annotations, but has an output schema), the description is minimally complete. It explains what the tool does and the parameter, but lacks usage guidelines and behavioral details. The presence of an output schema means return values are documented elsewhere, so the description doesn't need to cover that, but it should still address when to use this tool.
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 description adds meaning beyond the input schema by explaining that the 'name' parameter is used 'to look up' a tenant, which clarifies its purpose as an identifier. With 0% schema description coverage and only 1 parameter, this minimal addition is sufficient to compensate, earning a baseline 4 for such a simple case.
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 details of a specific DuploCloud tenant by name.' This is a specific verb ('Get details') + resource ('DuploCloud tenant') combination. However, it doesn't explicitly differentiate from sibling tools like 'tenant_list' or 'tenant_get' vs 'tenant_create/delete', though the distinction is implied by the verb 'Get'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'tenant_list' for listing all tenants or 'tenant_create/delete' for other operations. The only context is the parameter requirement, which doesn't help with 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. It discloses the partial update behavior ('Provide only the fields to change'), which is valuable. However, it lacks critical behavioral details: it doesn't mention that this is a mutation/write operation (implied but not stated), doesn't specify permissions needed, doesn't describe error conditions, and doesn't explain what happens to unchanged fields. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the core purpose, followed by a clear Args section. Every sentence earns its place by adding value. Minor improvement could be integrating the optional note into the Args list more seamlessly, but overall it's efficient.
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 (mutation with 4 parameters), no annotations, and an output schema (which reduces need to describe returns), the description is moderately complete. It covers purpose and parameters well but lacks behavioral context like permissions, side effects, or error handling. For a mutation tool, this leaves gaps that could hinder safe usage.
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?
Schema description coverage is 0%, so the description must compensate. It adds meaningful semantics for all 4 parameters: tenant_id ('The tenant ID containing the service'), name ('The service name to update'), image ('New Docker image'), and replicas ('New replica count'). It also clarifies that image and replicas are optional. This goes well beyond the bare schema, though it doesn't explain parameter formats or constraints.
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 'Update' and resource 'existing service', making the purpose specific and understandable. It distinguishes from siblings like service_create, service_delete, and service_restart by focusing on partial field updates. However, it doesn't explicitly differentiate from service_get or service_list, which are read operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through 'Provide only the fields to change', suggesting a partial update scenario. It doesn't explicitly state when to use this vs. alternatives like service_create (for new services) or service_restart (for restarting without config changes), nor does it mention prerequisites or exclusions. Guidelines are present but not comprehensive.
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 creates a database but doesn't mention whether this is a long-running operation, what permissions are required, potential costs, error conditions, or what the output contains. The description is minimal and lacks critical 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the core purpose in the first sentence, followed by a structured Args section. Every sentence adds value, though the parameter explanations could be slightly more detailed given the complexity of database creation. No wasted text, but room for more context in the opening statement.
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 (database creation with 6 parameters), no annotations, and an output schema (which reduces need to describe returns), the description is moderately complete. It covers parameters well but lacks behavioral context, usage guidelines, and error handling. For a creation tool with significant implications, more completeness is needed despite the output schema.
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?
With 0% schema description coverage, the description compensates well by explaining all 6 parameters in the Args section, adding meaning beyond the bare schema. It clarifies what each parameter represents (e.g., 'tenant_id: The tenant ID to create the database in'), notes defaults ('Defaults to master'), and indicates requirements ('Required for most engines'). However, it doesn't provide format examples or constraints beyond basic explanations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Create a new RDS database instance') and resource ('in a DuploCloud tenant'), distinguishing it from sibling tools like database_delete, database_get, database_list, and database_update. It precisely identifies what the tool does beyond just restating 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 like database_update or other creation tools (e.g., bucket_create, host_create). It lacks context about prerequisites, dependencies, or scenarios where this tool is appropriate, offering only basic parameter explanations 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a creation operation but doesn't mention important behavioral aspects: what permissions are required, whether this is an asynchronous operation, what happens on failure, rate limits, or what the output contains. The description only covers basic parameter semantics without 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the core purpose in the first sentence. The parameter explanations are clear and efficient. While slightly longer than minimal, every sentence adds value given the 0% schema coverage. No redundant or wasted text is present.
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 this is a mutation tool with no annotations but with an output schema (which handles return values), the description is moderately complete. It covers all parameters well but lacks behavioral context about permissions, async nature, or error handling. For a VM creation tool, more operational context would be helpful, though the output schema reduces the need to describe return values.
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?
With 0% schema description coverage, the description must compensate, and it does so effectively by explaining all 4 parameters. It clarifies tenant_id context, friendly_name purpose, capacity as instance type, and agent_platform with specific enum values (0=Linux Docker, 7=EKS Linux) and default. This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Create a new host (VM)') and resource ('in a DuploCloud tenant'), distinguishing it from sibling tools like host_get, host_list, host_delete, and host_reboot. It explicitly identifies the resource type as a VM/host rather than other resources like buckets, databases, or services.
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 tenant), when not to use it, or how it differs from similar creation tools like service_create or tenant_create. The only implied context is that a tenant must exist, but this isn't 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool lists hosts but does not describe output format, pagination, error handling, authentication needs, or rate limits. For a read operation 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 appropriately sized and front-loaded, with the main purpose stated first and parameter details in a structured 'Args:' section. It avoids unnecessary details, though the parameter explanation could be slightly more concise by integrating it into the main sentence.
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) and the presence of an output schema (which handles return values), the description is minimally complete. However, it lacks behavioral context (e.g., output structure hints, error cases) and usage guidelines, making it adequate but with clear gaps for effective agent use.
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?
With 0% schema description coverage, the description compensates by explaining the single parameter 'tenant_id' as 'The tenant ID to list hosts for.' This adds clear meaning beyond the schema's basic type and title, though it could specify format or constraints. Since there is only one parameter, the baseline is high, and the description provides adequate semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('List all hosts') and resource ('virtual machines in a DuploCloud tenant'), distinguishing it from siblings like host_create, host_delete, host_get, and host_reboot by focusing on listing rather than creating, deleting, retrieving details, or rebooting.
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 sibling tools like host_get (for specific host details) or host_create/host_delete (for management), nor does it specify prerequisites or exclusions, 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?
No annotations are provided, so the description carries full burden. It states this is a read operation ('Get details'), which is helpful, but doesn't disclose behavioral traits like authentication requirements, rate limits, error conditions, or what 'details' include (e.g., status, configuration). For a tool with no annotations, this leaves significant gaps in understanding how it behaves beyond basic retrieval.
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 front-loaded with the core purpose in the first sentence, followed by a clear Args section that efficiently documents parameters. Every sentence earns its place with no wasted words, making it easy to scan and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values), 2 parameters with 0% schema coverage (compensated by the description), and no annotations, the description is reasonably complete. It covers purpose and parameters well, but lacks behavioral details like error handling or performance, which would be beneficial given the absence of annotations.
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?
Schema description coverage is 0%, so the description must compensate. It adds meaningful context by explaining that 'tenant_id' identifies the tenant containing the database and 'name' is the database instance identifier, which clarifies beyond the schema's bare titles ('Tenant Id', 'Name'). This adequately covers both parameters, though it doesn't specify formats or constraints.
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 details') and resource ('specific RDS database instance'), making the purpose immediately understandable. It distinguishes from siblings like database_list (which lists multiple instances) and database_create/delete/update (which modify rather than retrieve). However, it doesn't explicitly contrast with database_get's absence from siblings, though the naming pattern implies it's the counterpart to other *_get tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when details of a specific database are needed, but provides no explicit guidance on when to choose this over alternatives like database_list or when not to use it (e.g., if only basic info is needed). It mentions the required parameters, which hints at prerequisites, but lacks clear context about alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool lists instances but lacks behavioral details such as whether it requires specific permissions, how results are formatted (though an output schema exists), pagination, rate limits, or error handling. This is a significant gap 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 front-loaded with the core purpose in the first sentence, followed by a concise parameter explanation. Every sentence earns its place with no wasted words, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/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) and the presence of an output schema (which handles return values), the description is reasonably complete. It covers the purpose and parameter semantics adequately, though behavioral transparency could be improved to fully compensate for the lack of annotations.
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?
Schema description coverage is 0%, so the description must compensate. It adds meaning by explaining that 'tenant_id' is 'The tenant ID to list databases for', clarifying its purpose beyond the schema's generic 'Tenant Id' title. With only one parameter, this provides adequate semantic context, though not exhaustive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('List all RDS database instances') and resource ('in a DuploCloud tenant'), distinguishing it from siblings like database_create, database_get, and database_update. It precisely communicates what the tool does without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by specifying the resource (RDS database instances) and context (DuploCloud tenant), but does not explicitly state when to use this tool versus alternatives like database_get (for a single instance) or other list tools (e.g., bucket_list). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It indicates a read-only list operation but doesn't disclose behavioral traits like pagination, sorting, rate limits, or authentication requirements. It's minimal but not misleading.
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 purpose without any wasted words. It's appropriately sized for a simple list tool with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/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 (0 parameters, no annotations, but with an output schema), the description is complete enough for basic understanding. It states what the tool does, though it could benefit from more behavioral context, but the output schema reduces the need for return value explanation.
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 no parameter documentation is needed. The description doesn't add param info, but that's appropriate here, warranting a baseline score above 3 due to the lack of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('List') and resource ('all tenants accessible in the DuploCloud portal'), distinguishing it from sibling tools like tenant_create, tenant_delete, and tenant_get. It precisely defines scope without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing tenants but provides no explicit guidance on when to use this tool versus alternatives like tenant_get (for a single tenant) or other list tools. It lacks context about prerequisites or exclusions.
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:

[![duplocloud-docker-mcp MCP server](https://glama.ai/mcp/servers/robford-brookai/duplocloud-docker-mcp/badges/card.svg)](https://glama.ai/mcp/servers/robford-brookai/duplocloud-docker-mcp)

Score Badge

Copy to your README.md:

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

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