The Sakura Cloud MCP Server enables AI assistants to interact with Sakura Cloud infrastructure through a standardized Model Context Protocol interface. With this server, you can:
Access and manage various resources (servers, disks, networks, switches, appliances, archives, ISO images, etc.)
Retrieve detailed information about specific resources
Query public pricing information without authentication
Manage AppRun containerized applications (create, update, start/stop, delete, view logs)
Handle billing information and view monthly breakdowns
Manage coupon information
Configure infrastructure components (SSH keys, icons, startup scripts)
Support multiple zones for targeting specific data centers
Check authentication status and permissions
Integrate with Claude Desktop app for conversational AI interactions
Enables management of Docker containers through the Sakura Cloud AppRun platform, allowing users to create, update, start, stop, and delete containerized applications with custom Docker images.
Uses Node.js as the runtime environment for the MCP server, with specific support for Node.js v16 or higher as a prerequisite for running the server.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Sakura Cloud MCP Server list all my servers and show their current status"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server implementation for interacting with Sakura Cloud's API.
The Model Context Protocol (MCP) is a standardized communication protocol that enables AI applications to securely interact with external systems and data sources. It follows a client-server architecture where LLM applications initiate connections to servers that expose resources and tools.
Related MCP server: k8s-mcp-server
This project implements an MCP server that allows AI assistants to interact with Sakura Cloud infrastructure through a standardized interface. It enables AI assistants to:
Access Sakura Cloud resources like servers, disks, networks, and more
Use tools to list resources and retrieve detailed information about specific resources
Query public pricing information without authentication requirements
Manage AppRun containerized applications
Node.js (v16 or higher)
Sakura Cloud API credentials (token and secret)
Claude Desktop app for using with Claude (MCP is currently only supported in the desktop app)
# Clone the repository
git clone https://github.com/hidenorigoto/sacloud-mcp.git
cd sacloud-mcp
# Install dependencies
npm install
# Build the project
npm run buildSet the following environment variables:
SACLOUD_API_TOKEN: Your Sakura Cloud API token
SACLOUD_API_SECRET: Your Sakura Cloud API secret
Resource URI | Description |
| Lists all servers in your Sakura Cloud account |
| Lists all switches in your Sakura Cloud account |
| Lists all appliances in your Sakura Cloud account |
| Lists all disks in your Sakura Cloud account |
| Lists all archives in your Sakura Cloud account |
| Lists all ISO images (CD-ROMs) in your Sakura Cloud account |
| Lists all bridges in your Sakura Cloud account |
| Lists all routers in your Sakura Cloud account |
| Lists all network interfaces in your Sakura Cloud account |
| Lists all icons in your Sakura Cloud account |
| Lists all startup scripts and notes in your Sakura Cloud account |
| Lists all SSH keys in your Sakura Cloud account |
| Lists all regions in your Sakura Cloud account |
| Lists all zones in your Sakura Cloud account |
| Lists all available products in your Sakura Cloud account |
| Lists all common service items (DNS, Simple Monitor, etc.) in your Sakura Cloud account |
| Lists all licenses in your Sakura Cloud account |
| Shows current authentication status and permissions |
| Shows monthly billing information |
| Shows detailed breakdown of billing information |
| Lists all available coupons |
| Lists all private hosts in your Sakura Cloud account |
| Shows public pricing information for Sakura Cloud services (no authentication required) |
| Lists all AppRun applications in your Sakura Cloud account |
Tool Name | Description | Required Parameters |
| Retrieves list of all servers | None |
| Retrieves detailed information about a specific server |
|
| Retrieves list of all switches | None |
| Retrieves detailed information about a specific switch |
|
| Retrieves list of all appliances | None |
| Retrieves detailed information about a specific appliance |
|
| Retrieves list of all disks | None |
| Retrieves detailed information about a specific disk |
|
| Retrieves list of all archives | None |
| Retrieves detailed information about a specific archive |
|
| Retrieves list of all ISO images | None |
| Retrieves detailed information about a specific ISO image |
|
| Retrieves list of all bridges | None |
| Retrieves detailed information about a specific bridge |
|
| Retrieves list of all routers | None |
| Retrieves detailed information about a specific router |
|
| Retrieves list of all network interfaces | None |
| Retrieves detailed information about a specific network interface |
|
| Retrieves list of all icons | None |
| Retrieves detailed information about a specific icon |
|
| Retrieves list of all notes and startup scripts | None |
| Retrieves detailed information about a specific note or startup script |
|
| Retrieves list of all SSH keys | None |
| Retrieves detailed information about a specific SSH key |
|
| Retrieves list of all regions | None |
| Retrieves detailed information about a specific region |
|
| Retrieves list of all zones | None |
| Retrieves detailed information about a specific zone |
|
| Retrieves detailed information about specific product offerings |
|
| Retrieves list of all common service items | None |
| Retrieves detailed information about a specific common service item |
|
| Retrieves list of all licenses | None |
| Retrieves detailed information about a specific license |
|
| Retrieves billing information for a specific month |
|
| Retrieves detailed billing information for a specific month |
|
| Retrieves information about a specific coupon |
|
| Retrieves detailed information about a specific private host |
|
| Retrieves public pricing information for Sakura Cloud services | None |
| Retrieves list of all AppRun applications | None |
| Retrieves detailed information about a specific AppRun application |
|
| Creates a new AppRun application |
|
| Deletes an AppRun application |
|
| Starts an AppRun application |
|
| Stops an AppRun application |
|
| Updates an existing AppRun application |
|
| Gets logs from an AppRun application |
|
Sakura Cloud AppRun is a containerized application platform that allows you to run Docker containers without managing infrastructure. This MCP server provides full AppRun management capabilities:
View all your AppRun applications
Create new applications with custom Docker images
Update existing applications (change image, configuration, etc.)
Start and stop applications
View application logs
Delete applications when no longer needed
When creating or updating an AppRun application, you can specify:
Application name and description
Docker image to use
Plan ID (determines resources allocated)
Environment variables as key-value pairs
All API calls support specifying a zone parameter to target specific Sakura Cloud data centers. The default zone is tk1v (Tokyo), but you can specify others such as:
is1a (Ishikari)
tk1a (Tokyo)
And more...
Example URI with zone parameter: sakura:///servers?zone=is1a
Claude Desktop app provides MCP support. Follow these steps to integrate this server with Claude:
Make sure the server is running locally or on an accessible host.
Create a claude_desktop_config.json file in the appropriate location for your OS:
Windows: %APPDATA%\Claude\claude_desktop_config.json
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json
Add the following configuration to the file:
{
"sacloud-server": {
"command": "node",
"args": ["path/to/mcp/dist/server.js"],
"env": {
"SACLOUD_API_TOKEN": "your_token_here",
"SACLOUD_API_SECRET": "your_secret_here"
}
}
}Restart the Claude Desktop app to apply the configuration.
In a conversation with Claude, you can now access Sakura Cloud resources and tools.
This server handles sensitive API credentials
Never commit API tokens or secrets to version control
Use environment variables for all sensitive information
Implement proper access controls in production
ISC
Create a new AppRun application
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the AppRun application | |
| description | No | Description of the AppRun application | |
| dockerImage | Yes | Docker image to use for the AppRun application | |
| planId | Yes | Plan ID for the AppRun application | |
| environment | No | Environment variables for the AppRun application | |
| zone | No | The zone to use (e.g., "tk1v", "is1a", "tk1a"). Defaults to "tk1v" if not specified. |
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 'Create' which implies a write/mutation operation, but doesn't mention permissions required, whether this is idempotent, what happens on failure, or typical response format. For a creation tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that states exactly what the tool does with zero wasted words. It's appropriately sized and front-loaded with the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with 6 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what happens after creation, how to verify success, error conditions, or relationship to other tools like 'get_apprun_info'. The agent lacks crucial context for proper tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so all parameters are documented in the schema itself. The description adds no additional parameter information beyond what's already in the schema descriptions. This meets the baseline expectation when schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('new AppRun application'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its sibling 'update_apprun' or explain what distinguishes creation from updating, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 'update_apprun' or what prerequisites might be needed. It doesn't mention any context for creation (e.g., after planning or as an initial setup), 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.
Delete an AppRun application
| Name | Required | Description | Default |
|---|---|---|---|
| appId | Yes | The ID of the AppRun application to delete | |
| zone | No | The zone to use (e.g., "tk1v", "is1a", "tk1a"). Defaults to "tk1v" if not specified. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'Delete' which implies a destructive, irreversible mutation, but doesn't specify permissions required, confirmation steps, error handling, or what happens to associated resources. This is inadequate for a destructive 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse quickly without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation tool with no annotations and no output schema, the description is insufficient. It lacks critical details like irreversible consequences, required states (e.g., app must be stopped), error scenarios, or return values. Given the complexity and risk, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters (appId and zone) fully. The description adds no additional parameter semantics beyond what's in the schema, such as format examples or constraints. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the resource ('AppRun application'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'update_apprun' or 'stop_apprun' in terms of destructive nature, though the verb 'delete' implies permanence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., the app must be stopped), exclusions, or comparisons to siblings like 'stop_apprun' or 'update_apprun', 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.
Get detailed information about a specific appliance
| Name | Required | Description | Default |
|---|---|---|---|
| applianceId | Yes | The ID of the appliance to retrieve |
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 retrieves information, implying a read-only operation, but doesn't specify aspects like authentication requirements, rate limits, error handling, or what 'detailed information' includes (e.g., fields returned). 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded with the core action ('Get detailed information'), making it easy to parse. There is zero waste, earning a top score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a simple parameter with full schema coverage, the description is incomplete. It lacks details on behavioral traits (e.g., safety, performance) and output format, which are critical for a read operation. While the parameter is covered, overall context is insufficient for effective tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the parameter 'applianceId' documented as 'The ID of the appliance to retrieve'. The description adds no additional meaning beyond this, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate, as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'detailed information about a specific appliance', making the purpose understandable. It distinguishes from siblings like 'get_appliance_list' by specifying retrieval of a single appliance rather than a list. However, it doesn't explicitly contrast with other 'get_*_info' tools (e.g., 'get_server_info'), so it's not fully specific to sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an appliance ID), exclusions (e.g., not for lists), or direct alternatives like 'get_appliance_list' for multiple appliances. Usage is implied by the name but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get list of appliances
| Name | Required | Description | Default |
|---|---|---|---|
| zone | No | The zone to use (e.g., "tk1v", "is1a", "tk1a"). Defaults to "tk1v" if not specified. |
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 only states the action ('Get list') without mentioning whether this is a read-only operation, if it requires authentication, what the output format might be (e.g., list of names vs. full objects), 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at three words, which is efficient for a simple tool. However, it's arguably too brief given the lack of sibling differentiation and behavioral context—every word earns its place, but more words might be warranted to improve clarity. It's front-loaded but under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, 100% schema coverage) but lack of annotations and output schema, the description is incomplete. It doesn't explain what 'appliances' refers to in this context (e.g., virtual machines, devices), what the list contains, or how it relates to sibling tools. For a tool in a server with many similar 'get_' tools, more context is needed to avoid confusion.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'zone' parameter fully documented in the schema itself (including default value and examples). The description adds no additional parameter information beyond what's in the schema. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't need to compensate but also adds no extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get list of appliances' clearly states the verb ('Get') and resource ('appliances'), making the basic purpose understandable. However, it doesn't differentiate this tool from similar sibling tools like 'get_appliance_info' or 'get_apprun_list', leaving ambiguity about what specific aspect of appliances it retrieves. The purpose is clear but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'get_appliance_info' (likely for detailed info on a specific appliance) and 'get_apprun_list' (likely for appliance runs), there's no indication of whether this tool returns basic metadata, full details, or something else. No context or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific AppRun application
| Name | Required | Description | Default |
|---|---|---|---|
| appId | Yes | The ID of the AppRun application to retrieve | |
| zone | No | The zone to use (e.g., "tk1v", "is1a", "tk1a"). Defaults to "tk1v" if not specified. |
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 doesn't disclose whether this is a read-only operation (implied by 'get'), authentication requirements, rate limits, error conditions, or what 'detailed information' includes. The agent must infer behavior from the name alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It front-loads the core purpose ('Get detailed information') and specifies the resource precisely. No extraneous words or redundant information detract from clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'detailed information' entails (e.g., status, configuration, metrics), potential side effects, or error handling. Given the complexity of application data, more context is needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both parameters (appId and zone). The description adds no parameter-specific details beyond what's in the schema, such as example appId formats or zone implications. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get detailed information') and resource ('about a specific AppRun application'), making the purpose unambiguous. It distinguishes from siblings like 'get_apprun_list' (which lists multiple applications) and 'get_appliance_info' (which targets different resources), though it doesn't explicitly mention these distinctions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing appId), contrast with 'get_apprun_list' for browsing, or specify use cases like troubleshooting or status checks. Usage is implied but not articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get list of all AppRun applications
| Name | Required | Description | Default |
|---|---|---|---|
| zone | No | The zone to use (e.g., "tk1v", "is1a", "tk1a"). Defaults to "tk1v" if not specified. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the action without behavioral details. It doesn't cover permissions, rate limits, pagination, or output format, leaving significant gaps for a tool that likely returns a list of applications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, clearly front-loading the core purpose. It's appropriately sized for a simple list tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and multiple sibling tools, the description is incomplete. It lacks details on return values, error handling, and differentiation from other list tools, making it insufficient for full contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the 'zone' parameter. The description adds no additional parameter information beyond what's in the schema, resulting in the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'list of all AppRun applications', making the purpose understandable. It distinguishes from siblings like get_apprun_info (single app details) and get_apprun_logs (logs), but doesn't explicitly contrast with get_appliance_list or other list tools, keeping it at 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_apprun_info or get_appliance_list is provided. The description implies a broad listing function but lacks explicit context or prerequisites, resulting in minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get logs from an AppRun application
| Name | Required | Description | Default |
|---|---|---|---|
| appId | Yes | The ID of the AppRun application to get logs from | |
| offset | No | Offset to start fetching logs from (default: 0) | |
| limit | No | Maximum number of log entries to fetch (default: 100) | |
| zone | No | The zone to use (e.g., "tk1v", "is1a", "tk1a"). Defaults to "tk1v" if not specified. |
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 doesn't disclose whether this is a read-only operation (implied by 'Get'), potential rate limits, authentication needs, or what happens if the app isn't running. For a tool with 4 parameters and 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste—it directly states the tool's purpose without redundancy. It's appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters, no annotations, no output schema), the description is incomplete. It doesn't cover return values (e.g., log format, structure), error conditions, or behavioral traits like pagination (implied by offset/limit but not explained). For a logging tool with multiple parameters, this leaves too much unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented in the schema itself. The description adds no additional meaning beyond implying 'appId' is required (which the schema already states). It doesn't explain parameter interactions or provide context beyond what's in the schema, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get logs') and resource ('from an AppRun application'), making the purpose unambiguous. It distinguishes from siblings like get_apprun_info (which likely returns metadata) and get_apprun_list (which lists applications). However, it doesn't specify the exact scope or format of logs (e.g., application vs. system logs), keeping it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives is provided. While the name implies it's for logs (distinguishing from get_apprun_info for metadata), the description doesn't mention prerequisites (e.g., the app must be running), exclusions, or comparisons to other logging tools. Usage is implied by context but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific archive
| Name | Required | Description | Default |
|---|---|---|---|
| archiveId | Yes | The ID of the archive to retrieve |
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 retrieves information, implying a read-only operation, but does not cover aspects like authentication requirements, rate limits, error handling, or the format of returned data. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, making it easy for an AI agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It does not explain what 'detailed information' includes, how the data is structured, or potential behavioral traits like side effects. For a tool that retrieves specific entity details, more context is needed to guide effective usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'archiveId' parameter clearly documented. The description adds no additional meaning beyond the schema, such as explaining what an archive ID is or where to find it. Given the high schema coverage, a baseline score of 3 is appropriate, as the description does not compensate but also does not detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('detailed information about a specific archive'), making the purpose evident. However, it does not explicitly differentiate from sibling tools like 'get_archive_list' (which likely lists archives rather than retrieving details for one), leaving room for improvement in sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. For example, it does not mention when to use 'get_archive_info' over 'get_archive_list' or other 'get_*_info' tools, nor does it specify prerequisites like needing an archive ID. This lack of context reduces its utility for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get list of archives
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get list of archives' implies a read-only operation, but it doesn't specify permissions required, pagination behavior, rate limits, or what the output looks like (e.g., format, fields). For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description 'Get list of archives' is extremely concise—just three words—with zero wasted language. It's front-loaded and to the point, making it efficient for an AI agent to parse, though this brevity contributes to gaps in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a list operation with no parameters) and lack of annotations or output schema, the description is incomplete. It doesn't explain what 'archives' entails, the return format, or any behavioral aspects like sorting or filtering. For a tool in a server with many siblings, more context is needed to ensure correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, meaning there are no parameters to document. The description doesn't need to add parameter semantics, so a baseline of 4 is appropriate as it doesn't introduce confusion or redundancy regarding parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get list of archives' clearly states the verb ('Get') and resource ('archives'), making the basic purpose understandable. However, it doesn't differentiate from sibling tools like 'get_archive_info' or specify what type of archives (e.g., backup archives, data archives) or what context (e.g., system, user) is involved, leaving it somewhat vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'get_archive_info' (likely for details of a specific archive) and other list tools (e.g., 'get_apprun_list'), there's no indication of context, prerequisites, or exclusions, leaving the agent to infer usage based on naming alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed billing information for a specific month
| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes | The year (YYYY) of the billing period | |
| month | Yes | The month (MM) of the billing period |
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 retrieves billing information but doesn't mention whether this is a read-only operation, if it requires authentication, rate limits, or what the output format looks like. For a tool with no 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it easy to parse quickly, with zero wasted information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete for a tool that likely returns complex billing data. It doesn't explain what 'detailed billing information' includes, such as cost breakdowns or usage metrics, leaving the agent uncertain about the tool's full capabilities and output structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting the 'year' and 'month' parameters with their formats (YYYY and MM). The description adds no additional parameter semantics beyond what the schema provides, such as examples or constraints, so it meets the baseline score of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('detailed billing information for a specific month'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from its sibling 'get_bill_info', which might be a similar billing-related tool, leaving some ambiguity about when to use one versus the other.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 the sibling 'get_bill_info'. It lacks context on prerequisites, exclusions, or specific scenarios where this tool is preferred, leaving the agent to infer usage based on the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get billing information for a specific month
| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes | The year (YYYY) of the billing period | |
| month | Yes | The month (MM) of the billing period |
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 behavioral traits like whether this is a read-only operation (implied by 'Get' but not explicit), authentication requirements, rate limits, error conditions, or what format the billing information returns. For a 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place without being overly terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations and no output schema, the description is incomplete. It doesn't explain what 'billing information' includes (e.g., summary vs. details), potential return formats, or any behavioral context needed for safe invocation. For a tool with 2 parameters and no structured output documentation, this leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'for a specific month' which implies parameters for time period, aligning with the schema's year and month parameters. Since schema description coverage is 100% (both parameters are well-documented in the schema), the description adds minimal value beyond what's already in structured data, meeting the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('billing information') with specific scope ('for a specific month'), making the purpose unambiguous. However, it doesn't differentiate from sibling 'get_bill_detail' which might provide more granular billing data, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_bill_detail' or other billing-related tools. It doesn't mention prerequisites, constraints, or typical use cases, leaving the agent with minimal contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific bridge
| Name | Required | Description | Default |
|---|---|---|---|
| bridgeId | Yes | The ID of the bridge to retrieve |
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 this is a read operation ('Get'), implying it's non-destructive, but doesn't cover aspects like authentication requirements, rate limits, error conditions, or the format of returned information. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any unnecessary words. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 required parameter) and high schema coverage, the description is minimally adequate. However, with no annotations and no output schema, it should provide more behavioral context (e.g., what 'detailed information' includes) to be fully complete for agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'bridgeId' parameter clearly documented. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline score of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'detailed information about a specific bridge', making the purpose unambiguous. However, it doesn't explicitly differentiate from its sibling 'get_bridge_list' (which presumably lists bridges rather than retrieving details for one), so it falls short of 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.
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 the sibling 'get_bridge_list' for listing bridges or other tools for related operations, leaving the agent to infer usage from naming conventions alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get list of bridges
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It states a read operation ('Get'), implying it's likely safe and non-destructive, but doesn't specify aspects like pagination, sorting, filtering, rate limits, or authentication needs. For a list tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise ('Get list of bridges') with no wasted words, making it front-loaded and easy to parse. However, it might be overly terse, potentially under-specifying the tool's scope or behavior, which slightly reduces its effectiveness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete for a list tool. It doesn't explain what the list contains (e.g., bridge IDs, names, statuses), how results are formatted, or any behavioral traits like limits or errors. With no structured data to rely on, the description should provide more context to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, meaning no parameters are documented in the schema. The description doesn't add parameter details, which is appropriate since there are none to explain. A baseline of 4 is applied as the description doesn't need to compensate for missing parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get list of bridges' clearly states the verb ('Get') and resource ('bridges'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'get_bridge_info' or other 'get_*_list' tools, leaving ambiguity about what distinguishes this specific list operation from others.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'get_bridge_info' (likely for individual bridge details) and other list tools (e.g., 'get_server_list'), there's no indication of context, prerequisites, or exclusions, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific ISO image
| Name | Required | Description | Default |
|---|---|---|---|
| cdromId | Yes | The ID of the ISO image to retrieve |
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'), but doesn't disclose behavioral traits like authentication requirements, rate limits, error handling, or what 'detailed information' includes (e.g., metadata, size, status). For a 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Get detailed information') without any wasted words. It's appropriately sized for a simple lookup tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (single parameter, read-only implied), 100% schema coverage, but no annotations or output schema, the description is minimally adequate. It states the purpose clearly but lacks behavioral details and usage context, leaving gaps for an agent to infer correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the parameter 'cdromId' clearly documented in the schema as 'The ID of the ISO image to retrieve'. The description adds no additional meaning beyond implying specificity ('specific ISO image'), so it meets the baseline of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('detailed information about a specific ISO image'), making the purpose unambiguous. However, it doesn't explicitly differentiate from its sibling 'get_cdrom_list' (which presumably lists multiple ISO images) beyond implying specificity through 'specific ISO image'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_cdrom_list' or other 'get_*_info' tools. It lacks context about prerequisites, such as needing the ISO ID from a list operation, or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get list of ISO images
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it's a read operation ('Get'), but doesn't cover aspects like whether it requires authentication, rate limits, pagination, or the format of the returned list. This is a significant gap for a 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's appropriately sized for a simple tool and front-loads the key information ('Get list of ISO images').
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema), the description is minimal but adequate for basic understanding. However, with no annotations and no output schema, it lacks details on behavioral traits (e.g., authentication needs, return format) and doesn't differentiate from siblings, making it incomplete for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and it doesn't incorrectly imply any parameters. A baseline of 4 is appropriate for a tool with no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('list of ISO images'), making the purpose understandable. However, it doesn't distinguish this tool from sibling tools like 'get_cdrom_info' or other list tools, which would require mentioning it's specifically for ISO images rather than physical CD-ROMs or other media.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_cdrom_info' for detailed information or other list tools for different resources, nor does it specify prerequisites or contexts for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific common service item
| Name | Required | Description | Default |
|---|---|---|---|
| itemId | Yes | The ID of the common service item to retrieve |
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'), implying it's non-destructive, but doesn't cover aspects like authentication needs, rate limits, error conditions, or what 'detailed information' entails in the response. For a 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, straightforward sentence that efficiently conveys the core purpose without unnecessary words. It's front-loaded with the main action, though it could be slightly more structured by including key usage notes. Overall, it's concise and well-sized for its content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a read operation with one parameter) and lack of annotations or output schema, the description is incomplete. It doesn't explain what 'detailed information' includes in the response, potential errors, or how this tool fits within the broader context of sibling tools. For a tool without structured output documentation, more descriptive detail is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'itemId' documented as 'The ID of the common service item to retrieve'. The description adds no additional meaning beyond this, such as format examples or sourcing hints. With high schema coverage, the baseline score of 3 is appropriate as the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get detailed information') and resource ('about a specific common service item'), making the purpose understandable. However, it doesn't distinguish this tool from its sibling 'get_commonserviceitem_list' or other 'get_*_info' tools, which would require mentioning what makes 'common service items' unique or how this differs from listing them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an item ID), contrast with 'get_commonserviceitem_list' for listing items, or specify contexts where detailed info is needed over a list. This leaves 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.
Get list of common service items (DNS, Simple Monitor, etc.)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden but only states the basic action without behavioral details. It lacks information on permissions, rate limits, pagination, or response format, which are critical for a list operation in a server context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core purpose and includes helpful examples, 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 params, no output schema) and lack of annotations, the description is minimal. It covers the basic purpose but misses behavioral context like how results are returned or any constraints, leaving gaps for an agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add param info, but that's acceptable here, earning a baseline 4 for adequately handling the lack of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get list') and resource ('common service items'), with examples like DNS and Simple Monitor that help specify the scope. It distinguishes from siblings like get_commonserviceitem_info by focusing on listing rather than detailed info, though it doesn't explicitly contrast with all list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. While the description implies it's for listing items, it doesn't specify contexts, prerequisites, or exclusions, such as when to choose get_commonserviceitem_info for details instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about a specific coupon
| Name | Required | Description | Default |
|---|---|---|---|
| couponId | Yes | The ID of the coupon to retrieve |
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 information without disclosing behavioral traits like read-only nature, error handling, authentication needs, or rate limits. It's minimal and lacks essential context 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, front-loading the core action. It's appropriately sized for a simple retrieval tool, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It doesn't explain what information is returned, error conditions, or behavioral aspects, making it inadequate for a tool that likely involves data retrieval with potential constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema fully documents the single parameter 'couponId'. The description adds no additional meaning beyond implying retrieval of a specific coupon, aligning with the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'information about a specific coupon', making the purpose understandable. However, it doesn't differentiate from sibling tools like 'get_product_info' or 'get_license_info' beyond the resource type, missing explicit sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context for coupon retrieval, or compare to other 'get_*' tools in the sibling list, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific disk
| Name | Required | Description | Default |
|---|---|---|---|
| diskId | Yes | The ID of the disk to retrieve | |
| zone | No | The zone to use (e.g., "tk1v", "is1a", "tk1a"). Defaults to "tk1v" if not specified. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it 'gets' information, implying a read-only operation, but doesn't clarify if it requires authentication, has rate limits, returns structured data, or handles errors. For a tool with no annotations, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded with the core action and resource, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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) and 100% schema coverage, the description is minimally adequate. However, with no annotations and no output schema, it fails to explain what 'detailed information' includes or behavioral aspects, leaving room for improvement in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'a specific disk', which aligns with the 'diskId' parameter, but adds no meaning beyond what the schema provides. Since schema description coverage is 100%, the baseline score is 3, as the schema adequately documents both parameters without needing extra explanation in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'detailed information about a specific disk', making the purpose understandable. It distinguishes from sibling tools like 'get_disk_list' by focusing on a single disk rather than listing multiple. However, it doesn't specify what 'detailed information' includes, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 'get_disk_list' or other 'get_*_info' tools. It lacks context about prerequisites (e.g., needing a disk ID) or exclusions, leaving the agent to infer usage from the tool name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get list of disks
| Name | Required | Description | Default |
|---|---|---|---|
| zone | No | The zone to use (e.g., "tk1v", "is1a", "tk1a"). Defaults to "tk1v" if not specified. |
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 whether this is a read-only operation, what permissions are needed, whether it's paginated, what the return format looks like, or any rate limits. For a list tool with zero annotation coverage, this is a significant gap in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just three words, with zero wasted language. It's front-loaded with the core purpose and doesn't include any unnecessary elaboration. This is an example of efficient communication where every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a list operation with no annotations, no output schema, and a simple single parameter, the description is inadequate. It doesn't explain what information the list contains, whether it's filtered or paginated, or what the return structure looks like. For even a simple tool, more context would be helpful for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter information beyond what's already in the schema (which has 100% coverage). The schema fully documents the single optional 'zone' parameter with its type, description, and default value. The description doesn't compensate or add any additional context about parameters, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get list of disks' clearly states the action (get) and resource (disks), but it's vague about scope and doesn't distinguish from sibling tools like get_disk_info. It provides basic purpose but lacks specificity about what kind of disks or what information is included in the list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like get_disk_info or other list tools. The description doesn't mention prerequisites, context, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific icon
| Name | Required | Description | Default |
|---|---|---|---|
| iconId | Yes | The ID of the icon to retrieve |
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 retrieves information, implying a read-only operation, but does not cover aspects like authentication requirements, rate limits, error handling, or the format of the returned information. This leaves significant gaps for a tool that likely interacts with a system resource.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It is front-loaded with the core action ('Get detailed information'), making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is insufficient for a tool that retrieves system resource information. It does not explain what 'detailed information' includes, potential side effects, or error conditions, leaving the agent with incomplete context for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'iconId' parameter clearly documented. The description adds no additional semantic context beyond implying retrieval of details for a specific icon, which aligns with the schema. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('detailed information about a specific icon'), making the purpose understandable. However, it does not differentiate this tool from its sibling 'get_icon_list' (which presumably lists icons rather than retrieving details for a specific one), preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 'get_icon_list' or other 'get_*_info' tools. It lacks context about prerequisites (e.g., needing an icon ID) or exclusions, offering only a basic statement of function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get list of icons
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states a read operation ('Get'), implying it's likely safe and non-destructive, but doesn't disclose behavioral traits like pagination, rate limits, authentication needs, or what the output format might be (e.g., JSON array, plain text). This leaves significant gaps for agent decision-making.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence ('Get list of icons') with no wasted words. It's appropriately sized for a simple tool and front-loaded with the core action, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema) and lack of annotations, the description is incomplete. It doesn't explain what the list contains (e.g., icon IDs, names, metadata), how it's returned, or any usage context. For a tool in a server with many siblings, more detail would help an agent use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100% (empty schema). The description doesn't need to add parameter semantics, so it meets the baseline of 4 for zero-parameter tools. No additional value is required or provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get list of icons' clearly states the action ('Get list') and resource ('icons'), but it's vague about scope and doesn't differentiate from sibling tools like 'get_icon_info' (which presumably gets details about a specific icon). It's not tautological but lacks specificity about what kind of icons or what the list contains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. Given siblings like 'get_icon_info' (for specific icon details) and many other list tools (e.g., 'get_appliance_list'), the description doesn't help an agent choose between them or indicate any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific network interface
| Name | Required | Description | Default |
|---|---|---|---|
| interfaceId | Yes | The ID of the interface to retrieve |
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 'Get detailed information' implies a read-only operation, it doesn't specify authentication requirements, rate limits, error conditions, or what constitutes 'detailed information' (what fields are returned). This is particularly important for a network interface tool where details could include configuration, status, statistics, etc.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that immediately conveys the core purpose without any wasted words. It's appropriately sized for a simple retrieval tool and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'detailed information' includes, how results are structured, or any behavioral constraints. Given the network context and lack of structured output documentation, more context about return values and operational characteristics would be needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'interfaceId' clearly documented as 'The ID of the interface to retrieve'. The description doesn't add any additional parameter context beyond what the schema provides, which is acceptable given the high schema coverage. However, it doesn't explain where to find interface IDs or what format they follow.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get detailed information') and target resource ('about a specific network interface'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from its sibling 'get_interface_list' which presumably lists interfaces rather than retrieving details about a specific one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 'get_interface_list' (likely listing interfaces) and 'get_server_info' (possibly related), there's no indication of when this specific interface retrieval is appropriate versus other information-gathering tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get list of network interfaces
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Get list' implies a read-only operation, it doesn't specify whether this requires authentication, what format the list returns (e.g., names only vs. full objects), if there are rate limits, or if the list is filtered/paginated. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence ('Get list of network interfaces') that directly states the purpose without any unnecessary words. It's front-loaded with the core action and resource, making it immediately scannable and easy to understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate but lacks context about the return format or behavioral constraints. It doesn't explain what 'list' entails (e.g., array of names vs. objects), which could be important for an agent to process the output correctly. However, for a basic list tool, it meets the minimum threshold.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100% (though empty). The description doesn't need to explain any parameters, which is appropriate. It could theoretically mention that no parameters are required, but this is adequately covered by the structured schema, so a baseline score of 4 is warranted for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get list of network interfaces' clearly states the action (get) and resource (network interfaces), making the purpose immediately understandable. However, it doesn't differentiate itself from sibling tools like 'get_interface_info' which presumably provides detailed information about a specific interface, leaving room for potential confusion about when to use each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 'get_interface_info' (for detailed info on a specific interface) and various other list tools (e.g., 'get_server_list', 'get_zone_list'), there's no indication of when this list retrieval is appropriate versus when other list tools or the info variant should be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific license
| Name | Required | Description | Default |
|---|---|---|---|
| licenseId | Yes | The ID of the license to retrieve |
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 this is a read operation ('Get'), but doesn't mention any behavioral traits like authentication requirements, rate limits, error conditions, or what 'detailed information' includes. This leaves significant gaps for an agent to understand how to use it effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is insufficiently complete. It doesn't explain what 'detailed information' includes, how the licenseId should be formatted, or what the return structure looks like. For a tool with no structured output documentation, this leaves too many unknowns for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'licenseId' fully documented in the schema. The description doesn't add any additional meaning beyond what the schema provides about this parameter, so it meets the baseline score of 3 for adequate coverage without extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('detailed information about a specific license'), making the purpose understandable. However, it doesn't distinguish this tool from its sibling 'get_license_list', which presumably lists multiple licenses rather than retrieving details for a specific one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'get_license_list'. The description implies it's for retrieving details of a specific license, but there's no explicit comparison or context about when this is preferred over listing licenses.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get list of licenses
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Get list' which implies a read operation, but doesn't disclose behavioral traits like whether it requires authentication, returns paginated results, has rate limits, or what format the list is in. For a tool with zero annotation coverage, this is insufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at three words ('Get list of licenses'), front-loaded with the core action, and has zero wasted text. Every word earns its place by specifying the verb and resource without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a simple list operation, the description is incomplete. It doesn't explain what the list contains, how it's structured, or any behavioral context. For a tool in a server with many siblings, more completeness is needed to help the agent understand this tool's role and output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage (empty schema). The description doesn't need to explain parameters, and it doesn't add or contradict any parameter information. Baseline is 4 for zero parameters as the description appropriately doesn't discuss nonexistent inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get list of licenses' clearly states the verb ('Get') and resource ('licenses'), but it's vague about scope and doesn't distinguish from sibling tools like 'get_license_info' which might retrieve details about a specific license. It provides basic purpose but lacks specificity about what kind of list (e.g., all licenses, filtered, paginated).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like 'get_license_info' or other list tools. The description doesn't mention prerequisites, context, or exclusions. With many sibling tools present, this lack of differentiation leaves the agent without clear selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific note or startup script
| Name | Required | Description | Default |
|---|---|---|---|
| noteId | Yes | The ID of the note to retrieve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. While 'Get' implies a read operation, it doesn't specify permissions needed, rate limits, whether it returns structured data or raw content, or error conditions. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately front-loaded with the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a retrieval tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'detailed information' includes, the format of the response, or how it differs from similar sibling tools. Given the complexity implied by retrieving 'detailed information,' more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with the single parameter 'noteId' well-documented in the schema. The description adds no additional parameter context beyond what the schema already provides, so it meets the baseline for high schema coverage without adding value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('detailed information about a specific note or startup script'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_note_list' or 'get_apprun_info', which would require more specific scope definition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With siblings like 'get_note_list' (likely listing notes) and 'get_apprun_info' (likely for app runs), the description offers no context about when this specific retrieval is appropriate versus those other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get list of notes and startup scripts
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it's a read operation ('Get list of'), implying non-destructive behavior, but doesn't cover aspects like pagination, rate limits, authentication needs, or return format, which are critical for a list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, clearly front-loaded with the tool's purpose. It's appropriately sized for a simple list tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimal. It states what it does but lacks details on behavior (e.g., pagination, format) and usage context, making it incomplete for effective agent use without additional assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter information is needed. The description doesn't add param details, but this is acceptable given the lack of parameters, warranting a baseline score of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get list of') and the resources ('notes and startup scripts'), which is specific and unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_note_info' or other list tools, 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.
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 'get_note_info' for detailed information or other list tools for different resources. It lacks context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific private host
| Name | Required | Description | Default |
|---|---|---|---|
| privateHostId | Yes | The ID of the private host to retrieve |
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 retrieves information, implying a read-only operation, but does not disclose behavioral traits like authentication requirements, rate limits, error conditions, or what 'detailed information' includes (e.g., format, fields). This leaves significant gaps for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that is front-loaded with the core purpose. There is no wasted wording, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It does not explain what 'detailed information' entails (e.g., JSON structure, key fields) or address potential complexities like error handling. For a tool with no structured support, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the parameter 'privateHostId' clearly documented. The description adds no additional meaning beyond the schema, such as examples or constraints (e.g., ID format). Since the schema does the heavy lifting, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'detailed information about a specific private host', which is specific and unambiguous. However, it does not explicitly differentiate from sibling tools like 'get_server_info' or 'get_appliance_info', which follow similar patterns for different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 such as prerequisites (e.g., needing a valid private host ID) or comparisons to sibling tools like 'get_privatehost_list' (if it existed) for listing versus retrieving details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about specific product offerings
| Name | Required | Description | Default |
|---|---|---|---|
| productType | Yes | The type of product to retrieve (server, disk, internet, license) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. While 'Get detailed information' implies a read-only operation, it doesn't specify authentication requirements, rate limits, error conditions, or what format the information will be returned in. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core purpose without unnecessary words. It's appropriately sized for a simple retrieval tool and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, plus the existence of many similar-looking sibling tools, the description is insufficiently complete. It doesn't clarify the relationship to other 'get_*_info' tools, doesn't describe the return format, and provides minimal behavioral context for a tool that presumably queries product data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'productType' fully documented including its enum values. The description doesn't add any parameter semantics beyond what the schema already provides, so it meets the baseline score of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get detailed information') and resource ('specific product offerings'), making the purpose understandable. However, it doesn't differentiate this tool from its many sibling 'get_*_info' tools (like get_server_info, get_disk_info, etc.), which appear to serve similar purposes for specific product types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With numerous sibling tools like get_server_info, get_disk_info, and get_license_info that appear to retrieve information about specific product types, there's no indication whether this tool is a general-purpose alternative, a superset, or serves a different scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get public pricing information for Sakura Cloud services
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is a 'Get' operation, implying a read-only action, but doesn't specify if it requires authentication, has rate limits, returns structured data, or handles errors. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's front-loaded with the core action and resource, making it efficient and easy to parse, which is ideal for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no annotations, and no output schema, the description is minimally adequate but lacks depth. It doesn't explain what the pricing information includes (e.g., rates, tiers, regions) or the return format, which could help the agent use it effectively. For a read-only tool with no structured context, it's passable but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here, but it could have mentioned if any implicit parameters (like service names) are required, though not strictly necessary. Baseline is 4 for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('public pricing information for Sakura Cloud services'), making the purpose unambiguous. However, it doesn't distinguish this tool from its many sibling 'get_*' tools, which all retrieve information but for different resources, so it misses the opportunity to clarify why this specific pricing tool exists separately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'get_product_info' that might relate to pricing, there's no indication of whether this tool is for general pricing, product-specific pricing, or other 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.
Get detailed information about a specific region
| Name | Required | Description | Default |
|---|---|---|---|
| regionId | Yes | The ID of the region to retrieve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Get' implies a read-only operation, the description doesn't mention authentication requirements, rate limits, error conditions, or what format the detailed information will be returned in. For a tool with no annotation coverage, this is insufficient 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point with no wasted words. It's appropriately sized for a simple retrieval tool and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with one well-documented parameter and no output schema, the description is minimally adequate. However, it doesn't explain what constitutes 'detailed information' or provide any context about the data structure returned, which would be helpful given the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'regionId' clearly documented. The description doesn't add any additional parameter semantics beyond what's already in the schema, so it meets the baseline score of 3 for high schema coverage situations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'detailed information about a specific region', making the purpose understandable. However, it doesn't distinguish this tool from its sibling 'get_region_list' which presumably lists regions rather than providing detailed information about one specific region.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'get_region_list' available, there's no indication of when to retrieve detailed information about a single region versus listing all regions, nor any mention of prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get list of regions
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only states the action ('Get list') without mentioning permissions, rate limits, response format, or whether it's a read-only operation. This is a significant gap for a 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded and appropriately sized for a simple tool, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 params, no output schema), the description is minimal but incomplete. It lacks behavioral context (e.g., read-only nature, response structure) and doesn't differentiate from siblings, making it insufficient for full agent understanding without additional inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add param info, which is appropriate here. Baseline is 4 for zero parameters, as it avoids unnecessary detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get list of regions' clearly states the verb ('Get') and resource ('regions'), making the basic purpose understandable. However, it doesn't differentiate from sibling tools like 'get_region_info' or other list tools, nor does it specify what kind of regions (e.g., geographic, cloud, administrative). This makes it adequate but vague in context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'get_region_info' and many other list tools, there's no indication of differences in scope, filtering, or context. This leaves the agent without explicit or implied usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific router
| Name | Required | Description | Default |
|---|---|---|---|
| routerId | Yes | The ID of the router to retrieve |
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 retrieves 'detailed information' but doesn't specify what that includes (e.g., configuration, status, metrics), whether it's a read-only operation, potential errors, or response format. This leaves significant gaps for a tool with unknown behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and resource. There is no wasted verbiage or unnecessary elaboration, making it highly concise and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is insufficiently complete. It doesn't explain what 'detailed information' entails, potential return values, or behavioral aspects like error handling. For a tool with no structured context, more descriptive detail is needed to adequately inform usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the parameter 'routerId' fully documented in the schema. The description adds no additional parameter semantics beyond implying it targets a 'specific router', which aligns with the schema but doesn't provide extra value. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('detailed information about a specific router'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_router_list' or 'get_appliance_info', which would require more specific scope or resource distinction for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 'get_router_list' for listing routers or 'get_appliance_info' for other resources, nor does it specify prerequisites or contextual usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get list of routers
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Get list of routers', implying a read-only operation, but does not cover aspects like whether it requires authentication, if there are rate limits, what the return format is (e.g., JSON array), or if it supports pagination. This leaves significant gaps for an agent to understand how to invoke it effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise ('Get list of routers'), consisting of a single, clear sentence that front-loads the essential action and resource. There is no wasted verbiage or redundancy, making it efficient for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description is minimal. It states the purpose but lacks context on behavior (e.g., read-only nature, return format, any constraints) and does not relate to sibling tools. For a tool in a server with many similar list operations, more guidance on usage and output would improve completeness, but the description does not provide this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, meaning no parameters are documented in the schema. The description does not mention any parameters, which is appropriate since there are none. It adds no semantic detail beyond the schema, but with zero parameters, the baseline is 4 as the description does not need to compensate for missing parameter info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get list of routers' clearly states the verb ('Get') and resource ('routers'), making the purpose understandable. However, it lacks specificity about what 'list' entails (e.g., all routers, filtered by some criteria) and does not differentiate from sibling tools like 'get_router_info', which might retrieve details about a single router versus this list operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. For example, it does not specify if this should be used for listing all routers versus using 'get_router_info' for details on a specific router, or how it relates to other list tools like 'get_appliance_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.
Get detailed information about a specific server
| Name | Required | Description | Default |
|---|---|---|---|
| serverId | Yes | The ID of the server to retrieve | |
| zone | No | The zone to use (e.g., "tk1v", "is1a", "tk1a"). Defaults to "tk1v" if not specified. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. While 'Get' implies a read operation, it doesn't specify authentication requirements, rate limits, error conditions, or what 'detailed information' includes (e.g., status, configuration, metrics). 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized for a simple retrieval operation and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read operation with no output schema and no annotations, the description is minimally adequate but incomplete. It identifies the resource but doesn't cover return format, error handling, or differentiation from similar tools. Given the context of many sibling tools and no structured output documentation, more completeness would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both parameters (serverId and zone). The description adds no additional parameter semantics beyond implying retrieval of a specific server, which is already clear from the schema. Baseline 3 is appropriate when the schema does all the parameter documentation work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('detailed information about a specific server'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'get_server_list' or 'get_appliance_info', which would require specifying what makes server information distinct from other get_info operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling 'get_info' tools (e.g., get_appliance_info, get_zone_info), there's no indication of what distinguishes server information from other entity types or when to prefer this over general listing tools like get_server_list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get list of servers
| Name | Required | Description | Default |
|---|---|---|---|
| zone | No | The zone to use (e.g., "tk1v", "is1a", "tk1a"). Defaults to "tk1v" if not specified. |
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 only states the action ('Get list') without any information about permissions required, rate limits, pagination, return format, or error conditions. For a read operation with zero annotation coverage, this leaves critical behavioral traits unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at three words, with no wasted language. It's front-loaded with the core action and resource. Every word earns its place, making it efficient for quick scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, no output schema) and lack of annotations, the description is incomplete. It doesn't explain what the returned list contains (e.g., server IDs, names, statuses) or any behavioral context like filtering options beyond the zone parameter. For a list tool in a system with many similar tools, more guidance would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 100% description coverage, clearly documenting the 'zone' parameter with examples and a default. The description adds no parameter information beyond what's in the schema. According to the rules, with high schema coverage (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get list of servers' clearly states the verb ('Get') and resource ('servers'), making the basic purpose understandable. However, it lacks specificity about what constitutes a 'server' in this context and doesn't differentiate from sibling tools like 'get_server_info' (which presumably gets details of a specific server). The description is functional but vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_server_info' for detailed information or other list tools (e.g., 'get_appliance_list'), leaving the agent to infer usage based on naming conventions alone. No explicit when/when-not instructions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific SSH key
| Name | Required | Description | Default |
|---|---|---|---|
| sshkeyId | Yes | The ID of the SSH key to retrieve |
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 'Get detailed information' implies a read-only operation, it doesn't specify authentication requirements, rate limits, error conditions, or what constitutes 'detailed information' (format, fields included). This leaves significant behavioral 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for a simple retrieval tool and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with one well-documented parameter and no output schema, the description is minimally adequate. However, without annotations or output schema, it should ideally provide more context about what information is returned, authentication needs, 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage, with the single parameter 'sshkeyId' clearly documented as 'The ID of the SSH key to retrieve.' The description adds no additional parameter semantics beyond what the schema already provides, which meets the baseline expectation when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get detailed information') and target resource ('about a specific SSH key'), which is a specific verb+resource combination. However, it doesn't distinguish this from its sibling 'get_sshkey_list' which presumably lists SSH keys rather than retrieving details about a specific one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 'get_sshkey_list' or other information-retrieval tools. It doesn't mention prerequisites, appropriate contexts, 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.
Get list of SSH keys
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 ('Get list of') but does not describe any behavioral traits such as whether this is a read-only operation, if it requires authentication, rate limits, pagination, or what the return format looks like. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence ('Get list of SSH keys') with zero waste. It is appropriately sized and front-loaded, clearly stating the purpose without unnecessary elaboration, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema) and lack of annotations, the description is incomplete. It does not address behavioral aspects like return format, pagination, or authentication needs, which are important for an agent to use the tool effectively. The description is too minimal for adequate contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, meaning there are no parameters to document. The description does not need to add parameter semantics beyond what the schema provides, so it meets the baseline expectation. No additional value is required or provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get list of SSH keys' clearly states the verb ('Get list of') and resource ('SSH keys'), making the purpose immediately understandable. However, it does not differentiate from sibling tools like get_sshkey_info (which likely retrieves details of a specific SSH key) or other list tools (e.g., get_server_list), so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention when to use get_sshkey_list versus get_sshkey_info or other list tools, nor does it specify prerequisites or exclusions. This leaves the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific switch
| Name | Required | Description | Default |
|---|---|---|---|
| switchId | Yes | The ID of the switch to retrieve | |
| zone | No | The zone to use (e.g., "tk1v", "is1a", "tk1a"). Defaults to "tk1v" if not specified. |
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 retrieves 'detailed information' but doesn't specify what that includes, whether it's a read-only operation, potential errors, or any rate limits. This leaves significant gaps for a tool that likely interacts with network infrastructure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's front-loaded with the core purpose and appropriately sized for a simple retrieval tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is insufficient. It doesn't explain what 'detailed information' includes, potential error conditions, or how this tool differs from siblings in a server with 40+ tools. For a network resource tool, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both parameters (switchId and zone). The description adds no additional parameter semantics beyond implying retrieval for a 'specific switch', which aligns with the schema. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('detailed information about a specific switch'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_switch_list' or 'get_bridge_info', which reduces its score from a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 'get_switch_list' for listing switches or 'get_bridge_info' for related network resources, 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.
Get list of switches
| Name | Required | Description | Default |
|---|---|---|---|
| zone | No | The zone to use (e.g., "tk1v", "is1a", "tk1a"). Defaults to "tk1v" if not specified. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. 'Get list' implies a read-only operation, but it doesn't specify whether this requires authentication, has rate limits, returns paginated results, or what format the output takes. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just three words, which is appropriate for a simple list operation. However, it could benefit from slightly more context to distinguish it from sibling tools while maintaining brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and multiple similar sibling tools, the description is insufficient. It doesn't explain what data is returned, how results are formatted, or when to choose this over alternatives like 'get_switch_info'. The minimal description leaves significant gaps for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage for the single parameter 'zone', the schema already documents its purpose, format, and default value. The description adds no additional parameter information beyond what's in the schema, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get list of switches' clearly states the action (get) and resource (switches), but it's vague about scope and doesn't differentiate from sibling tools like 'get_switch_info' or 'get_bridge_list'. It provides basic purpose but lacks specificity about what kind of switches or what information is included.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. With sibling tools like 'get_switch_info' (likely for single switch details) and 'get_bridge_list' (potentially similar networking resources), the description offers no context about appropriate use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific zone
| Name | Required | Description | Default |
|---|---|---|---|
| zoneId | Yes | The ID of the zone to retrieve |
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 retrieves 'detailed information' but doesn't disclose behavioral traits such as whether it's a read-only operation, requires authentication, has rate limits, or what the output format might be. This leaves significant gaps for an agent to understand how to use it effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse quickly without unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, and the tool's role in a complex server with many siblings, the description is incomplete. It doesn't explain what 'detailed information' includes, how it differs from other info tools, or any behavioral aspects, leaving the agent with insufficient context for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'zoneId' clearly documented in the schema. The description adds no additional meaning beyond implying retrieval for a 'specific zone', which aligns with the schema. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('detailed information about a specific zone'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'get_zone_list' or other 'get_*_info' tools, which would require mentioning what makes zone information unique or how it differs from other info-retrieval tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With siblings like 'get_zone_list' and many other 'get_*_info' tools, the description lacks context on prerequisites (e.g., needing a zone ID) or comparisons (e.g., use this for a single zone vs. 'get_zone_list' for multiple zones).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get list of zones
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 ('Get list') but doesn't describe what the list includes (e.g., zone names, IDs, statuses), whether it's paginated, requires authentication, or has 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just three words: 'Get list of zones'. It's front-loaded and wastes no words, making it easy to parse quickly. Every word earns its place by specifying the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema), the description is minimal but incomplete. It lacks details on what the list contains, how it's formatted, or any behavioral traits. With no annotations and no output schema, the description should provide more context about the return value and usage to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the input schema has 100% description coverage (though empty). The description doesn't need to explain any parameters, so it appropriately avoids redundancy. A baseline of 4 is justified as the description doesn't add param info but doesn't need to compensate for any gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get list of zones' clearly states the verb ('Get') and resource ('zones'), making the purpose understandable. However, it doesn't distinguish this tool from its sibling 'get_zone_info' (which presumably retrieves details about a specific zone rather than listing all zones), leaving room for ambiguity. It's not vague, but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. Given the sibling tool 'get_zone_info', there's a clear need to differentiate between listing zones and getting detailed information about a specific zone, but this is not addressed. No context or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start an AppRun application
| Name | Required | Description | Default |
|---|---|---|---|
| appId | Yes | The ID of the AppRun application to start | |
| zone | No | The zone to use (e.g., "tk1v", "is1a", "tk1a"). Defaults to "tk1v" if not specified. |
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 ('Start') but doesn't describe what starting entails (e.g., booting a virtual machine, launching a service), potential side effects (e.g., resource consumption, billing implications), error conditions, or response format. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with zero wasted words. It front-loads the key action and resource, making it immediately understandable. Every part of the sentence earns its place by conveying the essential purpose without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of starting an application (a mutation operation), the lack of annotations and output schema, and the description's minimalism, it is incomplete. It doesn't cover behavioral aspects, error handling, or return values, which are critical for an agent to use the tool effectively. The high schema coverage for parameters doesn't compensate for these broader gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear documentation for both parameters ('appId' and 'zone'), including default values. The description adds no additional parameter semantics beyond what the schema provides, such as format examples for 'appId' or implications of zone selection. Given the high schema coverage, a baseline score of 3 is appropriate as the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Start') and the resource ('an AppRun application'), which is specific and unambiguous. It distinguishes from sibling tools like 'stop_apprun' and 'create_apprun' by focusing on initiating an existing application. However, it doesn't explicitly differentiate from other tools that might involve application management, such as 'update_apprun', which slightly limits its clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., the application must exist and be stopped), contrast with 'stop_apprun' or 'update_apprun', or specify scenarios for usage. This lack of context leaves the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop an AppRun application
| Name | Required | Description | Default |
|---|---|---|---|
| appId | Yes | The ID of the AppRun application to stop | |
| zone | No | The zone to use (e.g., "tk1v", "is1a", "tk1a"). Defaults to "tk1v" if not specified. |
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 stops an application, implying a mutation, but doesn't cover critical aspects like whether this is reversible, requires specific permissions, affects running processes, or has side effects. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words, making it easy to parse and front-loaded with the core action. It efficiently communicates the essential purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It lacks information on behavior, side effects, return values, and usage context, leaving significant gaps for an agent to understand how to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both parameters (appId and zone). The description adds no additional parameter information beyond what's in the schema, resulting in the baseline score of 3 for adequate but no extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Stop') and target resource ('an AppRun application'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'start_apprun' or 'delete_apprun' beyond the verb, missing explicit comparison that would earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'start_apprun' or 'delete_apprun', nor any prerequisites or context for stopping an application. 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.
Update an existing AppRun application
| Name | Required | Description | Default |
|---|---|---|---|
| appId | Yes | The ID of the AppRun application to update | |
| name | No | New name of the AppRun application | |
| description | No | New description of the AppRun application | |
| dockerImage | No | New Docker image to use for the AppRun application | |
| planId | No | New plan ID for the AppRun application | |
| environment | No | New environment variables for the AppRun application | |
| zone | No | The zone to use (e.g., "tk1v", "is1a", "tk1a"). Defaults to "tk1v" if not specified. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but offers minimal information. It states this is an update operation (implying mutation) but doesn't cover permissions needed, whether changes are reversible, side effects (e.g., downtime), rate limits, or what the response contains. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized and front-loaded with the essential information, though it could benefit from additional context in subsequent sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 7 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what happens during an update (e.g., whether the app restarts), error handling, or typical use cases. Given the complexity and lack of structured data, more descriptive content is needed to guide the agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 7 parameters. The description adds no parameter-specific information beyond what's in the schema (e.g., it doesn't explain relationships between parameters or provide examples). This meets the baseline for high schema coverage but doesn't enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and resource ('existing AppRun application'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its sibling 'create_apprun' beyond the obvious 'existing' vs 'new' distinction, nor does it specify what aspects can be updated versus what requires other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'create_apprun' or 'delete_apprun'. It doesn't mention prerequisites (e.g., needing an existing appId), error conditions, or typical workflows. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Most tools are clearly distinct by resource type (e.g., disk, server, router) and action (get, create, delete), with minimal overlap. However, some tools like get_bill_detail and get_bill_info could be confused due to similar naming and purpose, and the AppRun tools (create, delete, update, start, stop) are well-separated but form a tight cluster that might require careful selection.
Tool names follow a highly consistent verb_noun pattern throughout, using snake_case uniformly. All tools start with verbs like 'get', 'create', 'delete', 'start', 'stop', or 'update', followed by a specific resource name, making them predictable and easy to parse.
With 46 tools, the count is excessive for a cloud management server, likely overwhelming for agents and indicating poor scoping. While Sakura Cloud has many resource types, the server could benefit from consolidation or categorization to reduce cognitive load and improve usability.
The tool set provides comprehensive coverage for Sakura Cloud's domain, including CRUD operations for key resources like AppRun and extensive 'get' functions for various cloud components (servers, disks, networks, billing, etc.). Minor gaps exist, such as missing update/delete operations for many resources beyond AppRun, but core workflows are well-supported.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
An MCP server that integrates with Discord to provide AI-powered features.
MCP server for AI dialogue using various LLM models via AceDataCloud
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
Cloud-hosted MCP server for durable AI memory
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/hidenorigoto/sacloud-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
