sacloud-mcp

Official

by sacloud

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools are clearly distinct by resource type and action, such as create_server vs. get_server_list. However, some potential confusion exists between get_manual_outline and get_api_manual_outline, which both fetch manual outlines but for different documentation sets, and between get_loadbalancer and attach_servers, which both involve load balancers but with overlapping purposes. Overall, the descriptions help clarify distinctions, but minor ambiguities remain.
Naming Consistency5/5
The tool names follow a highly consistent verb_noun pattern throughout, such as create_server, get_server_list, delete_router, and start_server. All tools use snake_case uniformly, with verbs like create, get, delete, start, stop, and read applied predictably across resources. This consistency makes the tool set easy to navigate and understand.
Tool Count2/5
With 41 tools, the count is excessive for a single server, making it overwhelming and difficult for agents to manage. While the domain (Sakura Cloud API) is broad, the tool set includes many specialized or redundant tools, such as multiple manual-reading tools and separate billing/coupon tools, which could be consolidated. This high number detracts from usability and coherence.
Completeness4/5
The tool set provides comprehensive coverage for core cloud infrastructure operations, including CRUD for servers, disks, routers, switches, and load balancers, along with monitoring, billing, and documentation tools. Minor gaps exist, such as missing update operations for some resources (e.g., update_server) and limited object storage management beyond listing, but agents can likely work around these with the available create/delete and read tools.
Average 3/5 across 41 of 41 tools scored.
See the Tool Scores section below for per-tool breakdowns.
This repository is archived. Archived repositories automatically receive an F maintenance tier.
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states this is a deletion operation (implying destructive behavior) but doesn't disclose critical details: whether deletion is permanent/reversible, authentication requirements, rate limits, or error conditions. The return type mention adds minimal value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the core purpose. The Args/Returns sections are structured but could be more integrated. No wasted sentences, though the parameter explanations are insufficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations, 0% schema coverage, and no output schema, the description is incomplete. It misses behavioral details (permanence, side effects), parameter guidance, and error handling, leaving significant gaps for safe agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only lists parameter names in Japanese without explaining their meaning, valid values, or format. For example, 'zone' and 'internet_id' lack context about what zones are available or how router IDs are obtained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'さくらのクラウドAPIでルータを削除します' (deletes a router using the Sakura Cloud API). It specifies the verb (削除/delete) and resource (ルータ/router), but doesn't explicitly differentiate from sibling tools like 'delete_bridge' beyond the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. While sibling tools include 'create_router' and 'get_router_list', the description doesn't mention prerequisites (e.g., router must exist), consequences, or when to choose deletion over other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions this is a creation operation but doesn't specify permission requirements, whether this is idempotent, rate limits, error conditions, or what happens if the load balancer already exists. For a mutation tool with zero 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably structured with purpose statement, Args section, and Returns section. However, the Japanese purpose statement could be more concise, and the overall description could benefit from better organization. It's not overly verbose but could be more efficiently organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter mutation tool with no annotations and no output schema, the description provides adequate parameter documentation but lacks behavioral context and output details. The Returns section mentions 'JSON response' but doesn't describe its structure or content. Given the complexity, it's minimally complete but with significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates well by providing clear parameter documentation in the Args section. Each of the 4 parameters is named and briefly explained in Japanese, adding meaningful semantics beyond the bare schema. The parameter information is comprehensive and helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'creates a load balancer' in Japanese, which is a specific verb+resource combination. However, it doesn't distinguish this tool from sibling 'create_loadbalancer' - both appear to create load balancers, creating confusion about their differentiation. The purpose is clear but sibling distinction is missing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like 'create_loadbalancer'. The description doesn't mention prerequisites, constraints, or appropriate contexts for using this specific tool. It simply states what the tool does without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that the tool creates a server and disk, implying a write/mutation operation, but doesn't disclose critical behavioral traits such as permissions required, whether this is a destructive operation, rate limits, error handling, or what happens if creation fails. The description adds some context about the creation process but lacks comprehensive behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three sentences, but it's not optimally front-loaded. The first sentence states the purpose, but the second and third sentences provide procedural guidance that might be better placed elsewhere. The structure includes an 'Args' and 'Returns' section, which is helpful, but the main description could be more focused on the tool's core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a server creation tool with 6 parameters, no annotations, and no output schema, the description is incomplete. It lacks details on behavioral aspects (e.g., permissions, side effects), parameter meanings, error handling, and the return value structure (only vaguely mentions 'サーバ一覧のJSONレスポンス'). For a mutation tool with zero annotation coverage, this description does not provide sufficient context for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the lack of parameter documentation in the schema. The description does not explain any of the 6 parameters beyond what's in the schema (e.g., what 'zone' represents, valid values for 'gen', or units for 'mem'). It mentions CPU and memory in the context of checking plans but doesn't clarify parameter semantics. This is inadequate given the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a server using the Sakura Cloud API ('さくらのクラウドAPIからサーバを作成します'), which is a specific verb+resource combination. It distinguishes itself from siblings like 'create_disk' or 'get_server_list' by focusing on server creation. However, it doesn't explicitly differentiate from other creation tools like 'create_bridge' or 'create_router' beyond the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance by mentioning that users should check server plans and select one before creation, and that a disk should be created after server creation. However, it doesn't explicitly state when to use this tool versus alternatives (e.g., 'get_server_plan' for planning or 'create_disk' separately), nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it indicates this is a read operation ('取得します'), it doesn't describe authentication requirements, rate limits, error conditions, response format, or whether the operation is idempotent. For a read tool with zero annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient Japanese sentence that directly states the tool's purpose. There's no wasted language or unnecessary elaboration. It's appropriately sized for what it communicates.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read tool with 1 parameter, no annotations, and no output schema, the description is insufficient. It doesn't explain what a disk plan is, what information it returns, how results are formatted, or provide any context about the API. The agent would need to guess about the tool's behavior and output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 1 parameter with 0% description coverage, and the tool description provides no information about parameters. The description doesn't mention the 'zone' parameter at all, nor does it explain what values are valid or what the parameter controls. With low schema coverage, the description fails to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('取得します' - retrieve/get) and resource ('ディスクプラン一覧' - disk plan list) from a specific API ('さくらのクラウドAPI' - Sakura Cloud API). It's specific about what it retrieves but doesn't explicitly differentiate from sibling tools like get_server_plan or get_archive_list beyond the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context, or exclusions. It simply states what the tool does without indicating when it's appropriate to call it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is a deletion operation, implying it's destructive, but doesn't specify if it's irreversible, requires specific permissions, has side effects (e.g., on attached resources), or includes confirmation steps. The mention of a JSON response hints at an outcome, but details like error handling or rate limits are absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with the core purpose stated first in a single sentence. The Args and Returns sections are structured clearly, though the inclusion of 'dict: 削除結果のJSONレスポンス' is somewhat redundant as it repeats 'JSONレスポンス' from the sentence above. Overall, it's efficient with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a deletion tool with no annotations and no output schema, the description is incomplete. It lacks critical information such as the irreversible nature of deletion, potential dependencies (e.g., bridges must be empty), error scenarios, or response structure details. The tool's destructive nature requires more context than provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds semantic meaning for both parameters: 'zone' is described as '削除対象のゾーン' (the target zone for deletion) and 'bridge_id' as 'ブリッジID' (bridge ID). However, it doesn't provide format examples, constraints, or guidance on how to obtain these values, leaving gaps despite the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'さくらのクラウドAPIでブリッジを削除します' (deletes a bridge using Sakura Cloud API). It specifies the verb ('削除します' - deletes) and resource ('ブリッジ' - bridge), and distinguishes it from siblings like 'create_bridge' and 'get_bridge_list'. However, it doesn't explicitly differentiate from other deletion tools like 'delete_router' beyond the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing bridge), exclusions, or comparisons to sibling tools like 'get_bridge_list' for verification or 'create_bridge' for creation. The only implied usage is deletion, but no context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states this is a retrieval operation from an API, implying it's likely read-only and non-destructive, but doesn't explicitly confirm safety, permissions required, rate limits, error behavior, or pagination. For a tool with zero annotation coverage, this leaves significant behavioral gaps unaddressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, Args, Returns) and uses minimal sentences. The Japanese purpose statement is direct, and the parameter/return documentation is efficiently formatted. No wasted words, though the return value documentation could be slightly more informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0% schema coverage, and no output schema, the description provides basic purpose and parameter semantics but lacks behavioral details, usage guidelines, and comprehensive return value explanation. It's minimally adequate for a simple retrieval tool but doesn't fully compensate for the missing structured data, 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description includes an Args section explaining 'zone (str): 取得対象のゾーン' (zone: target zone to retrieve), which adds meaningful context about the single required parameter. However, it doesn't specify zone format, valid values, or examples, leaving some semantic gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'さくらのクラウドAPIからアーカイブ一覧を取得します' (retrieves archive list from Sakura Cloud API). It specifies the verb (取得します - retrieves) and resource (アーカイブ一覧 - archive list), but doesn't explicitly differentiate from sibling tools like get_disk or get_icon_list beyond the resource type. 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context for archive retrieval, or comparisons to other list tools like get_server_list or get_disk. Usage is implied only by the tool name and description, with no explicit when/when-not instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool retrieves data (implying read-only) and outlines the return structure, but lacks critical behavioral details: authentication requirements, rate limits, error handling, pagination, or whether it's idempotent. For a billing tool with no annotations, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the core purpose, followed by structured Args and Returns sections. No extraneous information is included. However, the mix of Japanese and English in the structure slightly affects readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0% schema coverage, and no output schema, the description provides basic purpose and return structure but lacks sufficient context for safe and effective use. It covers the essentials (what it does and what it returns) but misses operational details like authentication, error cases, and sibling tool differentiation, which are important for a billing API tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description adds minimal semantics: it explains 'account_id' as 'プロジェクトID（アカウントID）' (project ID/account ID), clarifying its purpose. However, it does not detail format constraints, examples, or validation rules. With only one parameter, this partial explanation meets baseline expectations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'さくらのクラウドAPIから指定プロジェクトIDの請求一覧を取得します' (retrieves billing list from Sakura Cloud API for a specified project ID). It specifies the verb '取得します' (retrieves) and resource '請求一覧' (billing list), but does not explicitly differentiate from its sibling 'get_bill_list_by_month', which appears to be a similar billing-related tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions retrieving billing list for a project ID but does not specify scope (e.g., all bills vs. filtered), prerequisites, or contrast with 'get_bill_list_by_month'. Usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the API source ('さくらのクラウドAPI') but doesn't disclose behavioral traits like authentication requirements, rate limits, error handling, pagination, or what happens if no databases exist. The description is minimal and lacks operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the main purpose in the first sentence. The Args and Returns sections are structured but could be more integrated. No wasted sentences, though it could be slightly more fluent in English context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 1 parameter with 0% schema coverage and no output schema, the description provides minimal but adequate basics: purpose, parameter hint, and return type. However, it lacks details on authentication, error cases, or output structure, which are important for a read operation with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description adds basic semantics for the single parameter 'zone' ('取得対象のゾーン' - target zone for retrieval), but doesn't explain what zones are available, their format, or examples. It compensates partially but not fully for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'さくらのクラウドAPIからデータベース一覧を取得します' (retrieves database list from Sakura Cloud API). It specifies the verb ('取得します' - retrieves) and resource ('データベース一覧' - database list), but doesn't explicitly differentiate from sibling tools like 'get_server_list' or 'get_router_list' beyond the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention any prerequisites, constraints, or comparison with sibling tools like 'get_disk' or 'get_loadbalancer' that might retrieve different resource types. It simply states what the tool does without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool retrieves data (implying read-only), but doesn't disclose behavioral traits like authentication requirements, rate limits, error handling, pagination, or response format details beyond 'JSONレスポンス' (JSON response). For a tool with zero annotation coverage, this is inadequate transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the core purpose, followed by structured Args and Returns sections. There's no wasted text, and the information is organized clearly. However, the Japanese-only content might limit accessibility in some contexts, slightly reducing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 1 parameter, no annotations, no output schema, and low schema coverage, the description is minimally complete. It covers the basic action and parameter intent but lacks details on authentication, error cases, response structure, or sibling differentiation. For a simple read operation, it's adequate but has clear gaps in providing full context for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds minimal semantics: 'zone (str): 取得対象のゾーン' (zone: target zone to retrieve). This clarifies the parameter's purpose but lacks details like zone format, valid values, or examples. With 1 parameter and low coverage, it provides basic meaning but not enough for full understanding, aligning with baseline expectations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'さくらのクラウドAPIからディスク一覧を取得します' (retrieves disk list from Sakura Cloud API). It specifies the verb '取得します' (retrieve) and resource 'ディスク一覧' (disk list), distinguishing it from siblings like create_disk or get_server_list. However, it doesn't explicitly differentiate from other list-retrieval tools like get_archive_list or get_icon_list, 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication), compare to siblings like get_disk_plan, or specify use cases (e.g., for inventory management). The only implied context is retrieving disk lists from Sakura Cloud, but no explicit usage rules are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the API source and return format (JSON response), but lacks critical information: authentication requirements, rate limits, pagination behavior, error handling, or whether this is a safe read-only operation. The description provides basic context but misses important operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (main description, Args, Returns). It's appropriately sized for a simple retrieval tool. Every sentence serves a purpose: the first states what it does, the second documents the parameter, the third describes the return. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter retrieval tool with no output schema, the description covers the basics: purpose, parameter, and return format. However, with no annotations and missing behavioral details (auth, pagination, errors), it's incomplete for reliable agent usage. The description does what's minimally required but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description explicitly documents the single 'zone' parameter in the Args section, explaining it's the target zone for retrieval. This adds meaningful semantics beyond the bare schema, though it doesn't elaborate on zone format or valid values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('取得します' - retrieve) and resource ('ロードバランサ一覧' - load balancer list) from a specific API ('さくらのクラウドAPI'). It distinguishes itself from sibling tools like 'create_loadbalancer' by being a read operation. However, it doesn't explicitly differentiate from other 'get_' tools that retrieve different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. While the description implies it's for retrieving load balancer lists, there's no mention of prerequisites, when not to use it, or how it differs from other list-retrieval tools in the sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that the tool retrieves data (implied read-only) and describes the return format, but lacks details on authentication requirements, rate limits, error handling, or whether it's safe for repeated use. This is insufficient for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with the main purpose stated first followed by return details. The Japanese text is concise, and the English translation is clear, though the mix of languages might slightly affect readability for non-Japanese speakers.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description is moderately complete. It explains the purpose and return format but lacks parameter documentation and behavioral context like authentication or error handling. This is adequate but has clear gaps for a tool with no structured data support.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention the 'site_id' parameter at all, despite it being required and having 0% schema description coverage. However, since there is only one parameter, the baseline is 4, but the score is reduced to 3 because the description fails to add any semantic context for the parameter, leaving it entirely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: retrieving a list of object storage access keys from the Sakura Cloud API. It specifies the resource ('object storage access keys') and the action ('retrieve'), but does not explicitly differentiate it from sibling tools like 'get_objectstorage_bucket_list' or 'get_objectstorage_site_list', which handle different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, such as authentication or API access, or specify scenarios where this tool is appropriate compared to other object storage-related tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states this is a read operation ('取得します' - get/retrieve), which implies it's non-destructive, but doesn't disclose behavioral traits like authentication requirements, rate limits, pagination, error handling, or what 'サーバ一覧' (server list) specifically includes. The return format is mentioned ('JSONレスポンス' - JSON response), but without details on structure or content.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the purpose clearly, followed by structured Args and Returns sections. However, the Args section could be more integrated into the flow, and some redundancy exists (e.g., 'JSONレスポンス' is implied by 'dict').
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 1 parameter, no annotations, and no output schema, the description is minimally complete. It covers the basic purpose and parameter, but lacks behavioral context (e.g., authentication, rate limits) and detailed return value explanation. For a simple read tool, this is borderline adequate but could be more informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds minimal semantics: 'zone (str): 取得対象のゾーン' (zone: target zone to retrieve from). This clarifies the parameter's purpose but doesn't provide format details, valid values, or examples. With 1 parameter and low schema coverage, this is adequate but leaves gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'さくらのクラウドAPIからサーバ一覧を取得します' (Get server list from Sakura Cloud API). It specifies the verb ('取得します' - get/retrieve) and resource ('サーバ一覧' - server list), but doesn't explicitly differentiate from sibling tools like 'get_server_power_status' or 'get_server_plan', which also retrieve server-related information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention sibling tools like 'get_server_power_status' (for power status) or 'get_server_plan' (for plan details), nor does it specify prerequisites or context for usage beyond the basic function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is a retrieval operation but doesn't mention whether it's read-only, safe, requires authentication, has rate limits, returns paginated results, or what format the output takes. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Japanese that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded with the core action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations, no output schema, and 0% schema description coverage for its one required parameter, the description is incomplete. It doesn't explain what a server plan is, what the output looks like, or provide any behavioral context, making it inadequate for an agent to use confidently without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description doesn't mention any parameters, and schema description coverage is 0% (the 'zone' parameter has no description in the schema). However, with only one parameter, the baseline is 4, but it's reduced to 3 because the description provides no context about what 'zone' means or why it's required, leaving the agent to guess based on the tool name and sibling tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('取得します' - retrieve/get) and resource ('サーバプラン一覧' - server plan list) from a specific API source ('さくらのクラウドAPI' - Sakura Cloud API). It's specific about what it retrieves, though it doesn't explicitly differentiate from sibling tools like get_disk_plan or get_server_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context, or comparisons with sibling tools like get_server_list or get_disk_plan, leaving the agent to infer usage based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a retrieval operation ('取得します') which implies read-only behavior, but doesn't explicitly confirm safety, permissions required, rate limits, pagination, error conditions, or what 'JSONレスポンス' contains. For a read operation 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear purpose statement followed by Args and Returns sections. Every sentence serves a purpose: the first states what the tool does, the second documents the parameter, and the third describes the return format. No redundant information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read operation with no annotations, no output schema, and minimal parameter documentation, the description is incomplete. It doesn't explain what the JSON response contains, how results are structured, whether there are limitations or pagination, or error scenarios. The agent lacks sufficient context to properly interpret results or handle edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes an Args section that documents the single parameter 'zone' with a brief Japanese explanation ('取得対象のゾーン' - target zone for retrieval). With 0% schema description coverage, this adds meaningful context beyond the bare schema. However, it doesn't explain zone format, valid values, or provide examples, leaving the parameter only partially documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('取得します' - get/retrieve) and resource ('VPNルータ一覧' - VPN router list) from a specific API ('さくらのクラウドAPI'). It distinguishes itself from sibling tools like 'get_router_list' by specifying VPN routers specifically. However, it doesn't explicitly contrast with other list tools like 'get_router_list' or 'get_server_list' beyond the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, appropriate contexts, or compare with similar sibling tools like 'get_router_list' or 'get_vpn_monitor'. The agent must infer usage solely from the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes the conversion to markdown and content extraction but lacks critical details: error handling (e.g., invalid URLs), rate limits, authentication needs, output format specifics beyond 'str', or whether it's a read-only operation. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence clearly states the purpose, followed by structured 'Args' and 'Returns' sections. There's minimal redundancy, though the 'Returns' section slightly repeats information from the first sentence. Overall, it's efficient and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (involving URL processing and markdown conversion), no annotations, and no output schema, the description is partially complete. It covers the basic purpose and parameters but lacks details on behavioral traits, error handling, and output specifics. It's adequate as a minimum viable description but has clear gaps for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes an 'Args' section that documents the single parameter 'url' as a string for the Sakura Cloud API manual URL. With 0% schema description coverage, this adds essential meaning beyond the bare schema. However, it doesn't provide examples, format constraints (e.g., URL validation), or details on what constitutes a valid manual URL, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: it takes a Sakura Cloud API manual URL, converts it to markdown, and extracts main content. It specifies the verb ('受け取り、markdownに変換し、取得します'), resource ('さくらのクラウドのAPIマニュアル'), and transformation process. However, it doesn't explicitly differentiate from sibling tools like 'read_manual' or 'read_object_storage_api_manual' beyond the URL specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_api_manual_outline' or 'read_manual', nor does it specify prerequisites, constraints, or typical use cases. The only implicit context is the URL requirement, but no explicit usage guidelines are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions conversion to markdown and extraction of main content, but doesn't disclose important behavioral traits: whether it requires authentication, rate limits, error handling, what 'main content' means, or how the conversion process works. The description is insufficient for a tool that processes external content.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise with three sentences that each serve a purpose: stating the tool's function, describing the parameter, and describing the return value. It's front-loaded with the core functionality. The Args/Returns formatting is clear though slightly verbose for a single parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that fetches and processes external content with no annotations and no output schema, the description is incomplete. It doesn't explain authentication requirements, rate limits, error conditions, what 'main content' extraction entails, or the format/structure of the returned markdown. The agent lacks sufficient information to use this tool reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains that the 'url' parameter should be a Sakura Cloud manual URL with the specific format 'https://manual.sakura.ad.jp/cloud/~', which adds meaningful context beyond the bare schema. However, it doesn't provide examples, validation rules, or what happens with invalid URLs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: it takes a Sakura Cloud manual URL, converts it to markdown, and extracts the main content. It specifies the verb ('read'), resource ('manual'), and transformation process. However, it doesn't explicitly differentiate from sibling tools like 'read_api_manual' or 'get_manual_outline' beyond the URL source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'read_api_manual' or 'get_manual_outline'. It mentions the specific URL format but doesn't explain why one would choose this tool over others for accessing Sakura Cloud documentation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this creates a load balancer (implying a write/mutation operation) but doesn't mention required permissions, rate limits, costs, or what happens on failure. The Returns section mentions a JSON response but doesn't describe its structure or what success/failure looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized but not optimally structured. The main purpose statement is clear, but the parameter documentation uses inconsistent formatting (some have type hints, some don't) and contains a typo ('netwrok_mask' vs schema's 'network_mask'). The Returns section is minimal but adequate. Overall functional but could be cleaner.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with 8 parameters, no annotations, and no output schema, the description provides adequate parameter semantics but lacks behavioral context. It covers what parameters mean but not how the tool behaves operationally. Given the complexity of creating infrastructure resources, more guidance on permissions, costs, or error handling would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates well by providing Japanese explanations for all 8 parameters, including constraints like name length (1-64 characters), description max length (512 characters), vrid range (1-255), and network mask range (8-29). It also indicates which parameters are optional (description, default_router). This adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('作成します' - creates) and resource ('ロードバランサ' - load balancer) in the Sakura Cloud API context. It distinguishes from siblings like create_router or create_switch by specifying load balancer creation. However, it doesn't explicitly differentiate from other creation tools beyond naming the resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like create_router or create_switch. There's no mention of prerequisites, dependencies, or typical use cases. The agent must infer usage from the tool name and parameter list alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but provides minimal behavioral context. It states the tool creates something (implying mutation) and shows the return structure, but doesn't mention authentication requirements, rate limits, error conditions, or what happens if creation fails. The description doesn't contradict annotations since none exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized but not optimally structured. The initial sentence states the purpose clearly, but the detailed parameter and return documentation could be more integrated. The information is valuable but presented in a somewhat segmented format rather than flowing naturally.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with no annotations and no output schema, the description provides basic parameter documentation and return structure, which is adequate but minimal. It covers what the tool does and what it returns, but lacks important context about authentication, error handling, and integration with other tools in the ecosystem.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates well by documenting all 3 parameters in the Args section with clear explanations of each parameter's purpose, constraints (1-64 characters for name, max 512 for description), and optionality. This adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a switch using the Sakura Cloud API, specifying both the action and resource. It distinguishes from siblings like create_bridge or create_router by focusing on switches, but doesn't explicitly differentiate from other network creation tools beyond naming.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. While the description mentions it's for creating switches, there's no mention of prerequisites, when this is appropriate versus other network components, or how it relates to tools like get_switch_list or attach_servers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While it states this is a read operation ('取得します' - get/retrieve), it doesn't mention authentication requirements, rate limits, error conditions, pagination behavior, or whether the operation has side effects. The Returns section describes output structure but doesn't cover behavioral aspects like what happens with invalid project IDs or API failures.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized but not optimally structured. The main purpose statement is clear, but the Args/Returns sections use a documentation-style format that duplicates what could be in structured schemas. The Japanese/English mixing creates some redundancy. However, every sentence adds value, and there's no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with one parameter and no output schema, the description provides adequate coverage of what the tool does and what it returns. However, without annotations and with sibling tools that handle related financial data, it should ideally provide more context about when this specific coupon information is needed versus other billing tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for the single parameter, the description compensates well by explaining that 'account_id' represents the project ID ('プロジェクトID（アカウントID）'). This adds meaningful semantic context beyond what the bare schema provides, though it doesn't elaborate on format requirements or validation rules.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'さくらのクラウドAPIから指定プロジェクトIDのクーポン一覧を取得します' (Get coupon list from Sakura Cloud API for specified project ID). It specifies the verb ('取得します' - get/retrieve) and resource ('クーポン一覧' - coupon list), but doesn't explicitly differentiate from sibling tools like get_bill_list or get_price, which are related but distinct financial tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, timing considerations, or compare it to sibling tools like get_bill_list or get_price that might provide related financial information. The only contextual clue is that it requires a project ID, but this is already in the parameter documentation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states this is a retrieval operation (取得します), implying read-only behavior, but doesn't disclose authentication requirements, rate limits, pagination behavior, error conditions, or whether this lists all interfaces or requires specific permissions. The return format is described, but operational behavior is minimally covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized but not optimally structured. The purpose statement is clear, but the detailed return format (which belongs in an output schema) occupies most of the text. While helpful, this information could be more efficiently presented if an output schema existed. The Args/Returns sections are organized but verbose for a description field.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and low schema coverage, the description provides basic purpose and parameter explanation plus detailed return format. However, for a read operation with many sibling tools, it lacks context about when to use it, behavioral constraints, and differentiation from alternatives. The return format detail partially compensates for missing output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and only 1 parameter, the description compensates well by explaining the 'zone' parameter in Japanese: '取得対象のゾーン' (target zone for retrieval). This adds meaningful context beyond the schema's bare 'zone' title. However, it doesn't provide format examples or enumeration of possible zone values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'さくらのクラウドAPIからネットワークインターフェース一覧を取得します' (retrieves network interface list from Sakura Cloud API). It specifies the verb (取得します/retrieves) and resource (ネットワークインターフェース一覧/network interface list), but doesn't explicitly differentiate from sibling tools like get_switch_list or get_router_list beyond the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context for usage, or comparison with sibling tools like get_server_list (which might include interface information) or get_switch_list. Only the basic function is stated without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes the output format (a nested dictionary with URLs) but does not mention any behavioral traits such as rate limits, authentication requirements, error conditions, or whether it's a read-only operation. 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, but it mixes Japanese and English, which may reduce clarity for some agents. The structure is front-loaded with the main purpose, but the second sentence redundantly restates the return value in a less clear format. Some sentences could be more efficient in conveying information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simple read operation with no parameters) and lack of annotations and output schema, the description is partially complete. It explains the output format but lacks details on behavioral aspects like error handling or performance. For a zero-parameter tool, this is adequate but leaves gaps in operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, with 100% schema description coverage (since there are no parameters to describe). The description does not need to add parameter semantics, and it appropriately focuses on the output. A baseline score of 4 is applied for zero-parameter tools, as there is no parameter information to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to return a dictionary of the Sakura Cloud manual's table of contents with item names and corresponding URLs. It specifies the verb ('返します'/'returns') and resource ('さくらのクラウドの使い方のマニュアルの目次'). However, it does not explicitly differentiate from sibling tools like 'get_api_manual_outline' or 'read_manual', which appear related to manual access, so it misses full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention sibling tools such as 'get_api_manual_outline' or 'read_manual', nor does it specify any context or prerequisites for usage. This lack of guidance leaves the agent to infer usage from tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves data (a read operation) and describes the return format in detail, which is helpful. However, it lacks information on potential side effects, error conditions, rate limits, authentication requirements, or pagination behavior. For a read operation with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, but the detailed return format listing (14 items) is extensive and could be more concise. While the return details are valuable, they might be better summarized or structured to avoid verbosity. The mix of Japanese and English in the return fields also adds minor complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is moderately complete. It clearly explains what the tool does and provides a detailed return format, which compensates for the lack of output schema. However, it misses behavioral context (e.g., error handling, auth needs) and usage guidelines, making it adequate but not fully comprehensive for an API call tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description correctly omits parameter details, focusing instead on the return value. This aligns with the baseline expectation for tools without parameters, as the schema fully handles the input specification.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'さくらのクラウドAPIからオブジェクトストレージのサイト一覧を取得します' (Get object storage site list from Sakura Cloud API). It specifies the verb '取得します' (get/retrieve) and the resource 'オブジェクトストレージのサイト一覧' (object storage site list), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_objectstorage_accesskey_list' or 'get_objectstorage_bucket_list', which target different resources within the same API.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, context for usage, or comparisons with sibling tools (e.g., 'get_objectstorage_accesskey_list' or 'get_objectstorage_bucket_list'). The absence of such information leaves the agent without explicit direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It states it retrieves data (implying read-only) and mentions the API source, but doesn't cover authentication needs, rate limits, error conditions, pagination, or what happens if the zone is invalid. The Returns section describes output structure but not 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized but not optimally structured. The first sentence clearly states the purpose, but the Args and Returns sections use a code-like format that mixes documentation styles. While informative, it could be more streamlined as plain text. No wasted sentences, but the formatting slightly hinders readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 1 parameter with 0% schema coverage and no output schema, the description provides basic purpose and parameter semantics but lacks behavioral context. It explains what the tool does and the zone parameter, but doesn't cover authentication, errors, or usage guidelines. For a simple read operation, it's minimally adequate but incomplete for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates well by explaining the single parameter 'zone' as '取得対象のゾーン' (target zone for retrieval). It adds meaningful context beyond the schema's bare 'Zone' title, clarifying it's the zone from which to fetch packet filters. For a single parameter tool, this is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('取得します' - retrieves) and resource ('パケットフィルタ一覧' - packet filter list) from a specific API ('さくらのクラウドAPI'). It distinguishes from siblings by specifying it retrieves packet filters, unlike other get_* tools that retrieve different resources like servers, disks, or routers. However, it doesn't explicitly contrast with non-get siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, appropriate contexts, or comparisons with other tools like get_router_list or get_switch_list that might retrieve related network resources. Usage is implied only by the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states it 'gets' prices, implying a read-only operation, but doesn't disclose behavioral traits like authentication requirements, rate limits, error handling, or whether it fetches real-time or cached data. The description focuses on the return format but lacks operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose in the first sentence, but the detailed return format (占쏙옙 of the text) might be excessive for a description, especially without an output schema. It could be more concise by summarizing the return structure or omitting it if not critical for tool selection. However, it's not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, no annotations, and no output schema, the description provides the purpose and detailed return format. This is adequate for a simple read operation, but it lacks context on usage guidelines and behavioral transparency, which are important for an AI agent to invoke it correctly in a broader toolset.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter semantics, but that's acceptable here. A baseline of 4 is appropriate as there are no parameters to explain, and the schema fully covers this aspect.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'さくらのクラウドの利用料金を取得します' (Get usage fees for Sakura Cloud). It specifies the verb '取得します' (get) and resource '利用料金' (usage fees), making the action clear. However, it doesn't explicitly differentiate from sibling tools like 'get_bill_list' or 'get_coupon_list', which might also relate to billing/costs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_bill_list' (which might list invoices) or 'get_coupon_list' (which might list discounts), nor does it specify prerequisites or contexts for usage. The agent must infer usage from the tool 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the API source and return format, but lacks critical details: whether this is a read-only operation, if it requires authentication, rate limits, pagination behavior, error handling, or what happens if no switches exist. 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with a clear purpose statement followed by structured Args and Returns sections. However, the Returns section is overly detailed with nested field explanations that might be better suited for an output schema. The front-loaded purpose is good, but some information could be more efficiently organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 1 parameter with 0% schema coverage and no output schema, the description provides adequate parameter documentation and detailed return format explanation. However, it lacks behavioral context (authentication, errors, etc.) and doesn't reference sibling tools. For a simple read operation, it's minimally complete but could be more comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides explicit parameter documentation in the Args section, detailing that 'zone' is the target zone for retrieval. With 0% schema description coverage and only 1 parameter, this compensates well by explaining the parameter's purpose and meaning beyond the bare schema, though it doesn't specify zone format or valid values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'さくらのクラウドAPIからスイッチ一覧を取得します' (Get switch list from Sakura Cloud API). It specifies the verb ('取得します' - get) and resource ('スイッチ一覧' - switch list), but doesn't explicitly differentiate it from sibling tools like get_router_list or get_bridge_list, which have similar list-retrieval patterns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context for usage, or comparisons with sibling tools like get_switch (singular) if it existed. It simply states what the tool does without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the core behavior (converting a URL to markdown and extracting content) but lacks details on permissions, rate limits, error handling, or output format beyond a string. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, stating the purpose in two sentences without unnecessary details. However, the second sentence about the return value is somewhat redundant, as it restates the purpose rather than adding new information, slightly reducing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 0 parameters, the description is incomplete. It explains the basic function but lacks details on behavioral traits, error cases, or what the returned string contains. For a tool that processes external content, more context on limitations or output structure would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameters are documented. The description implies the tool takes a URL as input, but this isn't reflected in the schema. Since there are no parameters, the baseline is 4, as the description doesn't need to compensate for missing param info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: it takes a specific URL for Sakura Cloud's object storage API manual, converts it to markdown, and extracts main content. It specifies the resource (API manual) and the action (convert to markdown and extract content), though it doesn't explicitly differentiate from sibling tools like 'read_api_manual' or 'read_manual' beyond the URL specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions the URL but doesn't explain when to choose this over other manual-reading tools like 'read_api_manual' or 'read_manual', or whether there are prerequisites or specific contexts for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool creates a bridge but lacks critical details: it doesn't mention permissions required, whether this is a mutating operation (implied but not explicit), rate limits, costs, or error conditions. The Returns section describes the output format, which is helpful but doesn't cover 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, Args, Returns) and uses minimal sentences. The Japanese purpose statement is direct, and the parameter documentation is organized efficiently, though the Returns section is somewhat detailed for a description (better suited to an output schema).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a creation operation with 3 parameters), no annotations, and no output schema, the description is moderately complete. It covers the purpose, parameters, and return format, but lacks behavioral context (e.g., side effects, auth needs) and usage guidelines, which are important for a mutation tool in a cloud API context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes an Args section that documents all three parameters (zone, name, description) with types and optionality, adding meaningful semantics beyond the input schema (which has 0% description coverage). It clarifies that 'description' is optional and provides context for 'zone' as the target zone, though it could elaborate on format or constraints (e.g., valid zones).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'さくらのクラウドAPIでブリッジを作成します' (creates a bridge using Sakura Cloud API). It specifies the verb (作成します/create) and resource (ブリッジ/bridge), though it doesn't explicitly differentiate from sibling tools like 'create_router' or 'create_switch' beyond the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context (e.g., networking setup), or comparisons to sibling tools like 'create_router' or 'create_switch', leaving the agent to infer usage based on the resource name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool returns a dictionary mapping item names to URLs, which is basic behavioral information. However, it doesn't disclose important traits like whether this is a read-only operation (implied but not stated), potential rate limits, authentication requirements, error conditions, or whether the data is cached/fresh. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences: one stating the purpose in Japanese, one clarifying the return type. Both sentences earn their place. However, the structure could be slightly improved by front-loading the English translation or combining the two sentences more seamlessly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, no annotations, and no output schema, the description provides basic completeness: it states what the tool does and the return format. However, it lacks context about when to use it versus sibling tools, doesn't explain the scope of the manual (e.g., which API version), and doesn't mention behavioral aspects like error handling. For a simple read-only tool, this is minimally adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100% (empty schema is fully described). With no parameters to document, the description doesn't need to add parameter semantics. The baseline for 0 parameters is 4, as there's nothing missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'さくらのクラウドのAPIマニュアルの目次を項目名と対応するurlを辞書型で返します' (returns the table of contents of the Sakura Cloud API manual as a dictionary mapping item names to URLs). It specifies the verb '返します' (returns) and resource 'APIマニュアルの目次' (API manual table of contents), but doesn't explicitly differentiate from sibling tools like 'get_manual_outline' or 'read_api_manual', which appear related.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are several sibling tools that seem related to manuals (get_manual_outline, read_api_manual, read_manual, read_object_storage_api_manual), but the description doesn't explain how this tool differs from them or when it should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a retrieval operation but doesn't mention authentication requirements, rate limits, error conditions, pagination behavior, or whether this is a read-only operation. The description adds minimal behavioral context beyond the basic operation purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (description, Args, Returns) and uses minimal sentences. The Japanese description is direct, and the parameter documentation is organized efficiently. No unnecessary information is included.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with no annotations and no output schema, the description provides adequate basic information but has significant gaps. It documents parameters well and describes the return structure, but lacks behavioral context (auth, errors, limits) and doesn't clarify the relationship with the sibling 'get_bill_list' tool. The return format documentation helps compensate for the missing output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates well by documenting all 3 parameters in the Args section with clear Japanese explanations: account_id as project ID, year in YYYY format, and month in MM format. This provides essential semantic context that the schema lacks entirely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'さくらのクラウドAPIから指定プロジェクトIDの特定年月の請求一覧を取得します' (Retrieves billing list for a specific month/year from Sakura Cloud API for a given project ID). It specifies the verb '取得します' (retrieves) and resource '請求一覧' (billing list). However, it doesn't explicitly differentiate from sibling 'get_bill_list' (without month/year filtering), which could cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. While it mentions retrieving billing for a '特定年月' (specific month/year), it doesn't clarify when to use this versus the sibling 'get_bill_list' tool (which appears to be a more general billing list tool). No prerequisites, exclusions, or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a retrieval operation, implying read-only behavior, but doesn't mention authentication requirements, rate limits, pagination, error conditions, or whether the operation is idempotent. The description adds 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized. It begins with the core purpose, then clearly sections Args and Returns with bullet-point details. The Japanese text is concise, and every sentence serves a purpose, though the Returns section could be more streamlined given there's no output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with one parameter and no output schema, the description is moderately complete. It covers the basic action, parameter meaning, and return structure. However, without annotations and with multiple similar list-retrieval siblings, it lacks context about authentication, error handling, and differentiation from alternatives that would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides clear parameter semantics despite 0% schema description coverage. It explains that 'zone' is '取得対象のゾーン' (the target zone for retrieval), which adds meaningful context not present in the schema. With only one parameter, this is sufficient to understand its purpose, though it doesn't specify zone format or valid values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'さくらのクラウドAPIからブリッジ一覧を取得します' (retrieves bridge list from Sakura Cloud API). It specifies the verb '取得します' (retrieves) and resource 'ブリッジ一覧' (bridge list), making the action clear. However, it doesn't explicitly differentiate from sibling tools like 'get_switch_list' or 'get_router_list' beyond the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are multiple list-retrieval siblings (get_switch_list, get_router_list, get_server_list, etc.), but no indication of when bridges specifically are needed versus other network components. No prerequisites, exclusions, or comparison to other tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it retrieves data (implying a read-only operation) and mentions the API source, but doesn't disclose other traits like authentication requirements, rate limits, error handling, or whether it's idempotent. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior beyond the basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the purpose clearly, and the subsequent section details the return structure. While the return details are somewhat lengthy, they are relevant for understanding the output since there's no output schema. There's minimal waste, though it could be slightly more concise in the Returns section.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters (simple), no annotations, and no output schema, the description does an adequate job by stating the purpose and detailing the return values. However, it lacks information on behavioral aspects like authentication or error handling, which would be important for completeness in a real-world API context. The return structure is helpful but doesn't fully compensate for the missing annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so the schema fully documents that no inputs are required. The description doesn't need to add parameter details, and it correctly doesn't mention any parameters. This meets the baseline for tools with no parameters, as the schema already provides complete information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'さくらのクラウドAPIからアイコン一覧を取得します（全ゾーン共通）' which translates to 'Retrieves icon list from Sakura Cloud API (common to all zones).' It specifies the verb ('取得します' - retrieves) and resource ('アイコン一覧' - icon list), and distinguishes it from siblings by mentioning it's for icons specifically. However, it doesn't explicitly differentiate from 'get_icon_tag_list' which might be a related sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions '全ゾーン共通' (common to all zones), which could imply a scope, but doesn't specify prerequisites, exclusions, or compare it to other icon-related tools like 'get_icon_tag_list'. There's no explicit when-to-use or when-not-to-use information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the return format (Name and CreationDate fields) which is helpful, but doesn't disclose important behavioral traits like authentication requirements, rate limits, error conditions, pagination behavior, or whether this is a read-only operation. For a tool with zero annotation coverage, this leaves significant gaps in understanding how to use it correctly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences: one stating the purpose and one describing the return format. Both sentences earn their place by providing essential information. The structure is front-loaded with the main purpose first. Minor improvement could be adding a period after the first sentence for better formatting.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, no annotations, and no output schema, the description provides the basic purpose and return format. However, for an API tool with no structured safety information, it should ideally mention that this is a read operation and any authentication requirements. The return format description is helpful but doesn't fully compensate for the lack of behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, and instead focuses on the return values. This is efficient and correct for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('取得します' - retrieves) and resource ('オブジェクトストレージのバケット一覧' - object storage bucket list) from a specific API ('さくらのクラウドAPI'). It distinguishes from siblings by focusing on object storage buckets rather than servers, disks, routers, etc. However, it doesn't explicitly differentiate from get_objectstorage_accesskey_list or get_objectstorage_site_list which are related object storage tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description doesn't mention prerequisites, authentication requirements, or compare it to other object storage tools like get_objectstorage_accesskey_list or get_objectstorage_site_list. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is a read operation (取得/get), which implies it's likely non-destructive, but doesn't explicitly confirm safety, permissions required, rate limits, or error handling. The description mentions the return is a JSON response from the API but lacks details on structure or potential side effects, leaving significant gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement, Args section with parameter details, and Returns section. It's appropriately sized and front-loaded with the main functionality. Minor improvements could include briefer formatting, but overall it's efficient with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0% schema description coverage, and no output schema, the description does a decent job covering basics: purpose, parameters, and return type. However, it lacks details on error cases, authentication needs, rate limits, and the exact structure of the returned JSON. For a monitoring tool with 4 parameters, this leaves some gaps in contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides clear semantics for all parameters: zone (取得対象のゾーン/target zone), internet_id (ルータID/router ID), start (開始時刻/start time with ISO format and default), and end (終了時刻/end time with ISO format and default). This adds substantial value beyond the bare schema, though it doesn't explain possible zone values or internet_id format, preventing a perfect score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'さくらのクラウドAPIからルータのネットワーク流量のリソースモニタ情報を取得します' (Get router network traffic resource monitor information from Sakura Cloud API). It specifies the verb (取得/retrieve) and resource (ルータのネットワーク流量のリソースモニタ情報/router network traffic resource monitor info). However, it doesn't explicitly differentiate from sibling tools like get_vpn_monitor or get_router_list, which is why it doesn't achieve a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, context for usage, or comparisons with sibling tools like get_vpn_monitor or get_router_list. The only implicit usage hint is that it's for monitoring router traffic, but this is insufficient for effective tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is a read operation (取得/get), implying it's non-destructive, but doesn't cover important aspects like authentication requirements, rate limits, error handling, or whether it's idempotent. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, Args, Returns) and uses minimal Japanese text efficiently. It avoids redundancy, though the English translations in the Returns section could be more concise. Overall, it's appropriately sized and front-loaded with the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no annotations, no output schema), the description is partially complete. It covers the purpose and parameters well but lacks usage guidelines, behavioral details, and output format explanations beyond a basic JSON structure. This makes it adequate but with clear 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes an 'Args' section that documents both parameters (zone and server_id) with their types and purposes, adding meaningful context beyond the input schema, which has 0% description coverage. This compensates well for the schema's lack of descriptions, though it doesn't provide examples or constraints (e.g., valid zone values).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'さくらのクラウドAPIからサーバーの電源状態を取得します' (Get server power status from Sakura Cloud API). It specifies the verb (取得/retrieve) and resource (サーバーの電源状態/server power status), making the action clear. However, it doesn't explicitly differentiate from sibling tools like get_server_list or get_server_plan, which lowers it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing server_id and zone), compare it to related tools like start_server or stop_server, or indicate any constraints. This leaves the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a retrieval operation (取得), which implies read-only behavior, but doesn't explicitly confirm it's non-destructive. It doesn't mention authentication requirements, rate limits, error conditions, or what happens when parameters are invalid. The return format is mentioned ('VPNルータ一覧のJSONレスポンス'), but this is vague and potentially misleading since the tool retrieves monitor data, not a list of VPN routers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized. It starts with a clear purpose statement, then has organized sections for Args and Returns. Each sentence earns its place by providing essential information. It could be slightly more concise by integrating the parameter explanations into a single paragraph, but the current structure is clear and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 parameters, no output schema, no annotations), the description is partially complete. It excels at explaining parameters but lacks important behavioral context. The return value description is potentially misleading ('VPNルータ一覧' suggests a list of routers, but the tool retrieves monitor data for a specific router). Without annotations or output schema, more detail about the response structure and error handling would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides excellent parameter semantics beyond the schema. The schema has 0% description coverage (only titles), but the description explains each parameter: zone is the target zone, vpn_id is the resource ID, start is the start time in ISO format with default behavior, and end is the end time in ISO format with default behavior. This fully compensates for the schema's lack of descriptions. The only minor gap is not explaining what specific zone values are valid.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'さくらのクラウドAPIからVPNルータ一のネットワーク流量のリソースモニタ情報を取得します' (retrieves VPN router network traffic resource monitor information from Sakura Cloud API). It specifies the verb (取得/retrieve), resource (VPN router), and type of data (network traffic monitor information). However, it doesn't explicitly differentiate from sibling tools like 'get_vpn_router_list' or 'get_router_monitor', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are several sibling tools that might be related (get_vpn_router_list, get_router_monitor), but the description doesn't mention any of them or explain the specific use case for this tool. The only contextual information is the parameter descriptions, which don't constitute usage guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the API context and describes the return structure, but doesn't address critical behavioral aspects like required permissions, whether this is a destructive operation, potential side effects, error handling, or rate limits. The description provides basic functional information but lacks important operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Args, Returns) and efficiently presents information. The Japanese introductory sentence is direct, though some might argue the detailed return structure could be simplified. Overall, it's appropriately sized with minimal wasted space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description provides adequate functional information but lacks important operational context. It explains parameters and return values well, but doesn't address permissions, side effects, or error conditions that would be crucial for safe tool invocation. The presence of detailed return structure helps but doesn't fully compensate for missing behavioral guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates well by explaining all three parameters: 'zone' as the target zone, 'server_id' as the server identifier, and 'force' as an optional flag for forced stopping with default value. This adds meaningful semantic context beyond the bare schema, though it doesn't elaborate on zone format or server_id constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('停止します' - stops) and resource ('サーバー' - server) in the context of the Sakura Cloud API. It distinguishes from sibling tools like 'start_server' by specifying the opposite action. However, it doesn't explicitly differentiate from other server-related tools like 'get_server_power_status' beyond the action verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. While the presence of 'start_server' as a sibling implies this is for stopping rather than starting, there's no explicit comparison or context about prerequisites, error conditions, or when force stopping might be appropriate versus normal stopping.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a retrieval operation, implying it's read-only, but doesn't explicitly confirm this or mention any other behavioral traits like authentication requirements, rate limits, error conditions, or pagination behavior. The description adds minimal context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Args, Returns) and uses bullet points for the return value details. It's appropriately sized - the main purpose statement is front-loaded, and the additional details are organized efficiently. The only minor improvement would be integrating the purpose statement more seamlessly with the parameter documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, no output schema, no annotations), the description provides good contextual completeness. It explains the purpose, documents the single parameter's meaning, and provides detailed return value information that substitutes for an output schema. For a straightforward retrieval tool, this is reasonably complete, though it could benefit from more behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides excellent parameter semantics despite 0% schema description coverage. It clearly explains that 'zone' is the target zone for retrieval and documents the detailed return structure with specific fields like ID, Name, BandWidthMbps, etc. This fully compensates for the lack of schema descriptions and provides meaningful context for both input and output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'さくらのクラウドAPIからルータ一覧を取得します' (retrieves router list from Sakura Cloud API). It specifies the verb '取得します' (retrieve) and resource 'ルータ一覧' (router list), making the action clear. However, it doesn't explicitly differentiate from sibling tools like 'get_router_monitor' or 'get_vpn_router_list', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are several sibling tools related to routers (create_router, delete_router, get_router_monitor, get_vpn_router_list), but the description doesn't mention any of them or explain when this specific list retrieval is appropriate versus other router-related operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states this is a creation operation but doesn't disclose behavioral traits like required permissions, whether this is a paid service, rate limits, or what happens on failure. The description only covers basic functionality without important operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Args, Returns) and efficiently presents information. The Japanese purpose statement is concise, though the detailed parameter explanations are necessary given the lack of schema descriptions. Every sentence serves a clear purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with 5 parameters, 0% schema coverage, and no output schema, the description provides good parameter documentation and return format details. However, it lacks important context about authentication requirements, error conditions, cost implications, or integration with sibling tools like 'get_router_list' or 'delete_router'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by providing detailed parameter information. It explains all 5 parameters with constraints (e.g., '1-64文字' for name length, '28または27' for network_mask_len options, '100、500、または1000 Mbps' for bandwidth), optional status, and character limits. This adds substantial value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'さくらのクラウドAPIでルータを作成します' (creates a router using Sakura Cloud API). It specifies the verb ('作成します' - creates) and resource ('ルータ' - router). However, it doesn't explicitly differentiate from sibling tools like 'create_switch' or 'create_bridge' beyond the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. While sibling tools include 'create_switch', 'create_bridge', and 'delete_router', the description offers no context about when a router is appropriate versus other network components or when deletion might be needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context about potential timeouts during startup, which is a critical behavioral trait not inferable from the schema. However, it lacks details on permissions required, rate limits, error conditions, or whether the operation is idempotent. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, warning, Args, Returns) and uses bullet points in the Returns section for readability. It's appropriately sized—each sentence adds value, such as the timeout warning and parameter explanations. However, the Japanese text might require translation for some users, and the Returns section is somewhat detailed but necessary given no output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation operation with potential timeouts), no annotations, no output schema, and low schema coverage (0%), the description does an adequate job. It covers the purpose, parameters, and return structure, and adds a behavioral warning. However, it lacks information on error handling, authentication needs, or interaction with sibling tools (e.g., 'stop_server'), making it incomplete for full contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It includes an 'Args' section that documents both parameters ('zone' and 'server_id') with brief explanations in Japanese, adding meaning beyond the bare schema. However, it doesn't specify format constraints (e.g., zone codes, server ID patterns) or provide examples, leaving some ambiguity. Given the low schema coverage, this partial compensation justifies a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'さくらのクラウドAPIでサーバーを起動します' (start a server using Sakura Cloud API). It specifies the verb ('起動します' - start) and resource ('サーバー' - server), and distinguishes it from sibling tools like 'stop_server' and 'create_server'. However, it doesn't explicitly differentiate from other power-related operations beyond the obvious name contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage context by mentioning that 'サーバの起動には時間がかかるため、リクエストがタイムアウトする場合があります' (server startup takes time, so requests may timeout). This suggests when to use it (for starting servers) and hints at a constraint (potential timeouts). However, it doesn't explicitly state when to use this versus alternatives like 'create_server' or 'stop_server', nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It specifies the data source (Sakura Cloud API) and scope (common across all zones), which adds useful context beyond a basic 'get' operation. However, it doesn't disclose behavioral traits like rate limits, authentication needs, error handling, or whether it's read-only (though implied by 'get'). This leaves 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured: a single sentence stating the purpose and scope, followed by a clear breakdown of the return value. Every sentence adds value—the first explains what the tool does, and the second details the output format—with no redundant or wasted information. It's front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no annotations, no output schema), the description is reasonably complete. It explains the purpose, source, scope, and return format in detail. However, for a tool with no annotations, it could better address behavioral aspects like safety or performance, slightly reducing completeness. The output description compensates for the lack of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100% (empty schema). The description doesn't need to compensate for any parameter gaps, so it meets the baseline of 4 for no parameters. It appropriately focuses on output semantics instead, describing the return structure in detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('取得します' - retrieve/get) and resource ('アイコンタグ一覧' - icon tag list) from a specific API source ('さくらのクラウドAPI' - Sakura Cloud API). It distinguishes itself from siblings like get_icon_list (which retrieves icons rather than tags) and other get_* tools for different resources. However, it doesn't explicitly contrast with all siblings, 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when icon tags are needed, mentioning it's '全ゾーン共通' (common across all zones), which provides some context about scope. However, it doesn't explicitly state when to use this tool versus alternatives (e.g., get_icon_list for icons vs. tags) or any prerequisites. The guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It clearly indicates this is a creation/mutation operation ('作成します'), but doesn't mention permission requirements, rate limits, error conditions, or whether the operation is idempotent. It does add useful context about prerequisite steps (checking plans/archives), which provides some behavioral insight beyond basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, usage instructions, Args, Returns). The Japanese purpose statement is concise, and the parameter documentation is organized. However, the bandwidth_mbps parameter appears in the description but not in the input schema, creating some confusion that slightly reduces efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter mutation tool with no annotations and no output schema, the description provides adequate but incomplete coverage. It explains the creation process and parameter semantics reasonably well, but lacks information about error handling, authentication requirements, and the structure of the return value (only stating it's a JSON response). Given the complexity, more behavioral context would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate for undocumented parameters. It provides specific guidance for 5 of 7 parameters: plan values (4 for standard, 2 for SSD), size_mb examples (20480 for 20GB), source_archive_id sourcing (from archive list), bandwidth_mbps options (100, 500, or 1000 Mbps), and name length constraints (1-64 chars). However, zone and server_id lack additional context beyond what's in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'さくらのクラウドAPIでディスクを作成して、サーバーに接続します' (Create a disk using Sakura Cloud API and connect it to a server). It specifies both the action (create) and resource (disk), and distinguishes itself from siblings like create_server or create_router by focusing on disk creation with server attachment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool: it instructs to first retrieve disk plans and archive lists for user selection, and specifies that source_archive_id should come from an archive list. However, it doesn't explicitly state when NOT to use it or mention alternatives like get_disk for reading existing disks, which prevents a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/sacloud/sacloud-mcp'

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