Spotinst MCP Server

Server Quality Checklist

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

Latest release: v0.7.0
Disambiguation4/5
Most tools have distinct purposes, but there is some overlap (e.g., detach_instances vs. remove_instances, list_clusters vs. list_all_clusters). However, descriptions clearly differentiate them, and the cloud-specific variants (AWS vs. Azure) are well-labeled.
Naming Consistency4/5
The naming follows a consistent verb_noun pattern overall, but there are minor inconsistencies like mix of prefixes (list_, get_, filter_, etc.) and some tools lacking _azure suffix while others have it. Still, the pattern is predictable and readable.
Tool Count3/5
37 tools is on the higher side for a single server, but given the breadth of resources (Ocean clusters, Elastigroups, Stateful Nodes, VNGs) and cloud providers (AWS, Azure), it is not excessive. Some tools could be consolidated, but overall scope justifies the count.
Completeness2/5
The tool set covers many read and some destructive operations, but notable lifecycle gaps exist: no create/delete for Ocean clusters, Elastigroups, or Stateful Nodes. This forces agents to work around missing CRUD operations, limiting autonomous workflows.
Average 4/5 across 37 of 37 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on May 5, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, required permissions, or error handling. The description is limited to the basic purpose, leaving the agent uninformed about side effects or constraints.
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 with two sentences plus an Args list, all front-loaded with the main purpose. No extraneous information is present, and the structure is clear, though it could be slightly more streamlined.
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 (2 params, output schema present), the description covers the basics. However, it lacks information on expected outputs, error cases, or prerequisite conditions, which would improve completeness for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds meaning by explaining each parameter: cluster_id with an example (o-390ef886) and account_id as 'Account ID for an Azure account.' However, these descriptions are minimal and lack details on how to obtain or format the 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 explicitly states 'Get details of a specific Azure Ocean cluster,' which is a clear verb+resource pair. It distinguishes from sibling tools like list_clusters_azure and other get tools (e.g., get_cluster_costs) by specifying 'Azure Ocean cluster'.
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 get_cluster_costs or get_cluster_health. It only describes what it does, without any context on appropriate usage scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It only states 'Get details', missing information on mutability, permissions, rate limits, or response characteristics. The read-only nature is obvious but not explicitly stated.
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 very short and front-loaded, with no wasted words. However, its brevity sacrifices clarity and completeness, which prevents a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description lacks context about what details are returned, how to interpret them, or how to use the tool effectively. Sibling tools are not mentioned, and the parameter semantics are insufficient.
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%, meaning the schema has no descriptions for parameters. The description only lists parameter names without adding any meaning beyond the schema. For example, it does not indicate the format of node_id or the role of account_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get details of a specific Azure Stateful Node', specifying the verb and resource. However, it does not differentiate from sibling tools like 'get_stateful_node' or 'get_cluster_azure', so it loses the top score.
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?
Usage is implied by the tool name and description, but there is no explicit guidance on when to use this tool versus alternatives like 'list_stateful_nodes_azure' or 'get_stateful_node'. No exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state whether the operation is read-only, what permissions are needed, or any side effects. The description merely says 'Get details,' which lacks sufficient transparency for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one line for the purpose and two lines for parameter descriptions. It is front-loaded with the core action and contains no superfluous 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?
The tool has an output schema (not shown but reported), so return value description is not required. However, the description lacks behavioral transparency and usage guidance, which are important for a tool with no annotations and a relatively specific purpose. For a simple 'get' tool, the level of completeness is adequate but not thorough.
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 an example format for node_id ('e.g. smi-abc12345') and explains the default behavior for account_id ('Defaults to SPOTINST_ACCOUNT_ID env var'). This provides useful context beyond the schema, but both parameters could benefit from more detail (e.g., valid patterns, constraints).
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 it 'Get details of a specific AWS Stateful Node (Managed Instance).' It specifies the resource ('Stateful Node', 'Managed Instance'), action ('Get details'), and scope ('specific'), which distinguishes it from the sibling tools 'list_stateful_nodes' and 'get_stateful_node_azure'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. While the name and purpose imply you need a node_id and should use list_stateful_nodes for browsing, the description does not mention this or provide any context about prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states that it 'gets a list'—no information about safety, idempotency, mutation, or rate limits is given.
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 with two sentences for purpose and a bullet list for args. No wasted words, but the structure could be slightly improved with clearer separation of purpose and parameters.
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 presence of an output schema, the lack of return value explanation is acceptable. However, the description omits usage context and behavioral details, leaving gaps for a simple but potentially important 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?
Although schema description coverage is 0%, the description adds meaningful context: an example value for cluster_id and a default for account_id via environment variable. This helps the agent understand usage beyond 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 action: 'Get the list of allowed EC2 instance types for an AWS Ocean cluster.' It uses a specific verb and resource, and the context distinguishes it from sibling tools like get_cluster or get_vng.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites, scenarios, or exclusions, which is important given the many sibling get tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It fails to mention side effects (none expected), authentication requirements, rate limits, or potential empty results. The description only lists parameters and defaults, omitting critical behavioral traits for a read-only log tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured as a clear docstring with a one-line summary followed by an enumerated Args list. It is concise, uses consistent formatting, and includes examples inline. No redundant sentences, though the Args block could be slightly more streamlined (e.g., merging defaults into one line).
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 output schema exists, return values need not be explained. However, the description lacks context about log severity meanings, date range boundaries, or pagination behavior. For a tool with 7 parameters and no output schema details, completeness is adequate but not thorough.
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's parameter explanations add significant value. It provides format examples for dates (YYYY-MM-DD), a cluster ID example (o-abc12345), severity options (ALL, INFO, WARN, ERROR), default values, and the account_id fallback to environment variable. This compensates well for the schema's lack of descriptions.
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 'Get scaling and activity log events for an Ocean cluster', specifying both AWS and Azure. It identifies the resource (cluster logs) and action (get), distinguishing it from siblings like get_cluster (cluster details) or get_cluster_health (health status).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus other log or monitoring tools. The description does not mention when it's appropriate to query logs, nor does it exclude alternatives like get_cluster_costs or get_cluster_scheduling. The agent must infer usage from 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 exist, so description carries full burden. It only implies read-only by 'Get details' but doesn't explicitly state permissions, side effects, or return format. Minimal behavioral disclosure.
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?
Extremely concise: one sentence for purpose, two lines for args. No redundant words, front-loaded with essential info.
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?
Adequate for a simple get tool, but missing explicit mention that vng_id is required (implied by schema), and no error or usage context. Output schema exists but not referenced.
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 coverage is 0%, but description adds value by providing examples (vng-14e08b61) and clarifying that account_id is an Azure account ID. Could note optionality of account_id.
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 it retrieves details of a specific Azure VNG, using strong verb-resource pairing. It distinguishes from siblings like list_vngs_azure (list all) and get_vng (likely for non-Azure).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like list_vngs_azure or get_vng. No when-not or context cues provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full disclosure burden. It reveals basic behavioral traits (30-day summary, fields returned) but omits important details such as whether the operation is read-only, required permissions, error handling, or rate limits. The description does not contradict annotations as 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, starting with a clear one-sentence summary followed by a structured parameter list. Every sentence serves a purpose, and no redundant information is present. It is well-organized but could be slightly more streamlined by integrating the parameter descriptions into the main text.
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?
For a simple query tool with three parameters and an existing output schema, the description provides adequate purpose and parameter details. It does not need to explain return values due to the output schema. However, the lack of behavioral transparency and usage guidance reduces completeness, though it remains sufficient for an AI agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description fully compensates by explaining each parameter: cluster_id is exemplified with 'o-abc12345', account_id is optional with default from env var, and cloud specifies allowed values 'aws' or 'azure' with default. This adds critical semantic meaning beyond the schema's minimal titles and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a 30-day cost/savings summary for an Ocean cluster, specifying the verb, resource, and scope. It mentions total spend, spot savings, and cost breakdown, making the purpose clear. However, it does not explicitly differentiate from sibling tools like get_cluster_costs or get_cost_trending, 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a 30-day cost/savings summary is needed, but provides no explicit guidance on when to use this tool versus alternatives (e.g., get_cluster_costs for more detailed costs). No prerequisites, exclusions, or context-specific instructions are given, limiting clarity on appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It only states a read-like export action but omits error handling, permissions, or side effects. With zero annotation support, 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 mostly concise with a clear sentence and a structured param list, though the docstring style adds slight verbosity for a simple tool.
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?
The description covers the purpose and parameters well. It doesn't explain output schema usage (but it exists) or how the YAML relates to other tools like create_vng, but overall is sufficient for an agent.
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 provides detailed parameter explanations (e.g., vng_id format, account_id default, cloud options), adding significant meaning beyond the schema's basic fields.
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 'Export a VNG configuration as YAML' with specific verb and resource, and the context of GitOps/backup distinguishes it from siblings like 'get_vng' (likely JSON) and 'export_cluster_yaml'.
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 via 'Useful for GitOps comparison or backup' but does not explicitly state when not to use or alternatives like 'get_vng' for non-YAML needs.
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?
Without annotations, the description covers key behaviors: returns compact summaries by default, verbose mode for full configs, and parameter defaults. However, it does not mention potential side effects, safety, or error handling, which is acceptable for a read-like operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficient: a single introductory sentence followed by a clear, bullet-style parameter list. No extraneous information; every sentence adds value.
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 complexity and presence of an output schema, the description covers the essential aspects: filtering criteria, cloud support, and result format. It could benefit from mentioning that the operation is read-only and non-destructive, but overall it is sufficient.
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?
The description provides thorough explanations for all 6 parameters, including default values, examples, and usage notes (e.g., tag_value matches any if empty, cloud defaults to aws). This compensates for the 0% schema description coverage and adds significant semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool filters VNGs by tag key and optionally value, specifying supported cloud providers. However, it does not explicitly differentiate from sibling tools like 'list_vngs' or 'filter_clusters_by_tag', which may lead to ambiguity in selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives such as 'list_vngs' or 'filter_clusters_by_tag'. The description implies usage for tag-based filtering but lacks recommendations 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?
The description indicates a simple read operation with no side effects. No additional behavioral traits beyond the obvious are disclosed, which is acceptable but minimal.
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?
Efficient: two-line purpose followed by bullet-point parameter descriptions. No redundant information.
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?
Adequate for a simple retrieval tool with output schema. Lacks differentiation from related get_* tools, but overall covers purpose and parameters well.
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?
Adds significant meaning beyond schema: provides example value for cluster_id and explains account_id default behavior. Schema coverage was 0%, so description fully compensates.
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 retrieves details of a specific AWS Ocean cluster, distinguishing it from list operations. However, it could be more specific about what 'details' include.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus siblings like get_cluster_health or get_cluster_nodes. Usage is implied only by the description.
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, the description must fully disclose behavioral traits. It explains that the tool returns compact summaries by default and full configurations when verbose is true, and lists example fields in verbose mode. However, it does not mention permissions, rate limits, pagination, or other potential side effects. The behavioral description is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences for the main purpose plus a brief parameter list. Every sentence provides necessary information without redundancy. The structure front-loads the core functionality, then details the optional verbose mode and parameters. No wasted words.
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 existence of an output schema, the description does not need to detail return values but covers the key distinction between compact and verbose output. It lists example fields for verbose mode (compute, networking, persistence). It lacks notes on pagination or data volume, but for a list tool with output schema, the description is mostly complete.
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?
The input schema has 0% description coverage, so the description must compensate. It includes an 'Args' section explaining both parameters: 'account_id' as the Azure account ID and 'verbose' with usage notes and default value. This adds significant meaning beyond the schema's titles and defaults, satisfying the parameter documentation fully.
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 'List all Azure Stateful Nodes in an account,' specifying the verb, resource, and scope. It distinguishes from sibling tools by including 'Azure' in the name and mentioning 'Stateful Nodes.' However, it does not explicitly contrast with siblings like 'list_stateful_nodes' (for other clouds) or 'get_stateful_node_azure' (single node).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on when to use the 'verbose' parameter ('Use when analyzing node settings, troubleshooting, or comparing configs'), but it does not indicate when to use this tool versus alternative tools such as 'list_stateful_nodes' (for other clouds) or 'get_stateful_node_azure' (for a single node). No when-not or exclusion criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The 'get' verb implies read-only, but no annotations are provided to confirm. The description lacks explicit mention of side effects, idempotency, or error handling. Acceptable but minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus parameter list, no fluff. Front-loaded purpose, efficient and structured.
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?
Covers purpose and parameters well. Output schema exists, so return documentation is not needed. Lacks error or edge case behavior, but acceptable for a simple retrieval 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?
Both parameters are described with examples and default behavior (e.g., 'e.g. sig-abc12345' for group_id, 'Defaults to SPOTINST_ACCOUNT_ID env var' for account_id). Adds significant value over zero schema descriptions.
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?
Clearly states 'Get details of a specific Elastigroup', providing a specific verb and resource. Distinguishes from siblings like list_elastigroups which lists all groups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. Does not mention when not to use or suggest sibling tools like list_elastigroups for listing all groups.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 'Get details' but does not disclose behavioral traits such as whether it is a read-only operation, any authentication requirements, rate limits, side effects, or what constitutes 'details.' The description is insufficient for a tool that should convey safety and impact.
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 concise: a one-line purpose followed by an efficiently structured args list. Every sentence is justified and adds value. The format is front-loaded and clear.
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 moderate complexity (4 parameters, 2 required, output schema present), the description covers parameter semantics well. It explains optionality and defaults. However, it does not explicitly note that cluster_id and roll_id are required (though that is inferable) or describe what the output contains. Overall, it is sufficiently complete with the output schema fill.
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?
The input schema has 0% description coverage, but the description's docstring provides clear semantics for each parameter: cluster_id and roll_id with example formats, account_id with default behavior (env var), and cloud with default value and allowed options. This adds significant meaning beyond the schema's bare properties.
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: 'Get details of a specific Ocean cluster roll (AWS or Azure).' The verb 'Get details' and resource 'specific Ocean cluster roll' are precise and distinguish it from siblings like list_rolls (listing) and initiate_roll (creating).
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 does not explicitly state when to use this tool versus alternatives. Usage is implied by the requirement of cluster_id and roll_id, but no guidance is given on when to choose this over list_rolls or initiate_roll, nor any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses that the tool returns compact summaries by default and full configs when verbose=true. It mentions account_id optionality but lacks details on pagination, rate limits, or authentication. Acceptable but incomplete.
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?
Two paragraphs: first clearly states purpose and default behavior, second lists arguments with concise explanations. No wasted words, efficient and front-loaded.
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 an output schema exists (details unknown), the description explains return value distinction (compact vs verbose). However, with many sibling tools, it omits guidance on how this differs from list_all_clusters, leaving room for confusion.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema: account_id defaults to env var, verbose=false default, and its use cases. Schema coverage is 0%, so the description compensates well for the 2 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists AWS Ocean Kubernetes clusters in a Spotinst account, specifying default compact summaries and an option for verbose. It also differentiates from siblings like list_clusters_azure by mentioning AWS Ocean.
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 hints at when to use verbose=true (analyzing, troubleshooting, comparing configs) but does not explicitly state when to use this tool over siblings like list_all_clusters or list_clusters_azure. No when-not-to-use or exclusions 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?
Discloses 'DESTRUCTIVE' nature and confirm guard, which is good given no annotations. But lacks details on permissions, side effects, error handling, or output behavior. The burden is fully on description, yet it only provides minimal safety context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Highly concise: 5 lines with clear front-loading of 'DESTRUCTIVE'. Every sentence serves a purpose without redundancy. Easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, parameter semantics, and safety, but lacks details on updates_json structure and error conditions. With an output schema, return values are not needed, but some behavioral context is missing.
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 adds significant meaning: vng_id format example, updates_json as JSON string, confirm as safety guard requiring true, and account_id for Azure account. All parameters are explained effectively.
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?
Clearly states verb 'Update' and resource 'Azure VNG', distinguishing from siblings like delete_vng, create_vng, and update_vng (non-Azure). The 'DESTRUCTIVE' prefix and specific parameter mentions reinforce purpose.
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?
Implied usage for updating Azure VNG configurations, with safety guard (confirm=true) and parameter requirements. However, no explicit guidance on when to use vs. alternatives or when not to use, leaving it to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses destructive behavior, requires confirmation, and explains defaults for termination and capacity decrement. It lacks details on error handling or side effects beyond termination.
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 bold header and bullet-pointed arguments, making it easy to scan. It could be slightly more concise by removing redundant phrasing like 'DESTRUCTIVE' repeated in context.
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 complexity of 6 parameters and destructive nature, the description covers purpose, parameters, and safety. It does not address error conditions or prerequisites, but the output schema is present so return values are not required.
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?
Schema coverage is 0%, so description must add meaning. It thoroughly explains each parameter: cluster_id, instance_ids (comma-separated), confirm (must be true), should_terminate (default true), should_decrement_capacity (default true), and account_id (optional, env var default). This provides significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it detaches and optionally terminates instances from an AWS Ocean cluster, specifying the verb and resource. It distinguishes from siblings by using 'Ocean cluster' context, but does not explicitly differentiate from 'remove_instances' which may be similar.
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 highlights the destructive nature and the requirement for confirm=true as a safety guard, implying caution. However, it does not provide explicit guidance on when to use this tool versus alternatives like 'remove_instances' or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description implies read-only operation but does not explicitly state safety, auth needs, or side effects. It adds param defaults but lacks deeper behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: a single-sentence purpose followed by structured Args list. No fluff, every sentence adds value.
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?
Output schema exists, so return details are covered. Description mentions returns (nodes, errors, rolls) sufficiently for a health check tool. Minor gap: no mention of error behavior.
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 has 0% description coverage. Description adds meaning: cluster_id example, account_id defaults to env var, cloud lists aws/azure defaults. This significantly compensates for schema gaps.
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 it performs a 'composite health check for an Ocean cluster' and lists returns (node status, recent errors, active rolls), which is specific and distinguishes from siblings like get_cluster or get_cluster_nodes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for a quick health overview but does not explicitly state when to use versus alternatives like get_cluster or get_cluster_log.
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, description carries full burden. It implies a read operation ('Get configuration'), but doesn't disclose permissions, rate limits, or error behavior (e.g., missing cluster). Adequate but not comprehensive.
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?
Concise: overview sentence then parameter docs in standard format. No unnecessary phrases. Front-loaded with purpose.
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 3 parameters and output schema existence, description covers what the tool returns (shutdown hours, tasks, settings). Could mention output structure more, but output schema is available.
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 has 0% description coverage, but description adds meaningful detail: cluster_id example, account_id explanation with env var, cloud options. Good compensation for missing schema descriptions.
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?
Description clearly states 'Get scheduling and auto-scaler configuration for an Ocean cluster (AWS or Azure).' It specifies the action (get), resource (cluster scheduling config), and scope, distinguishing it from sibling tools like get_cluster or get_cluster_health.
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?
No explicit when-to-use or when-not-to-use guidance. While the purpose is clear, it doesn't provide context for when this tool should be chosen over alternatives like get_cluster or list_clusters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a read-only operation, but with no annotations provided, it does not disclose additional behavioral traits such as authentication requirements, rate limits, or whether the listing includes account details or just IDs. The simplicity of the tool (no parameters) mitigates some concern, but more context would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that is front-loaded with the action and resource. It is concise with no wasted words.
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 extreme simplicity (no parameters, straightforward operation) and the existence of an output schema to describe return values, the description is adequately complete. It could optionally hint at the output structure, but this is not necessary.
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 no parameters, so the description adds no parameter information, which is appropriate. According to the guidelines, for 0 parameters the baseline is 4, and the description does not need to compensate.
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 action 'list' and the resource 'Spotinst accounts', with a specific scope 'accessible with the current token'. This makes the tool's purpose unambiguous and distinguishes it from sibling list tools like list_clusters or list_vngs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing accounts accessible with the current token, but it does not provide explicit guidance on when to use this tool versus alternatives such as 'probe_token_capabilities' or other list tools. A brief comparative note would improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains output format (compact vs full configs) and mentions account_id usage. However, it does not disclose whether the tool is read-only (likely), pagination behavior, or authentication requirements. The default for account_id is empty, but description implies it's needed without clarifying behavior when omitted.
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 concise, well-structured with a summary line and parameter breakdown. Every sentence adds value, no redundancy or fluff.
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 is a simple list operation with an output schema, the description covers key aspects: purpose, parameters, return format differences. Minor gaps like pagination or account_id default behavior are not critical for typical use.
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?
Schema has 0% description coverage, so description must compensate. It does so thoroughly: account_id includes an example value, verbose explains effect, default, and use cases. This adds significant meaning beyond the raw 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 lists Azure Ocean clusters in a Spotinst account, with specific detail on return format (compact vs verbose). This distinguishes it from sibling tools like list_clusters (likely for other clouds) and list_all_clusters (cross-cloud).
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 guidance on when to use verbose=true (analyzing settings, troubleshooting), but does not explicitly advise when to use this tool over alternatives like list_clusters or list_all_clusters. The intent is implied by naming but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description bears full burden. It only states the basic listing capability without disclosing pagination, filtering, rate limits, or other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a concise docstring with a clear purpose line followed by parameter details, no redundant information.
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 presence of an output schema, the description sufficiently covers tool purpose and parameters. Slightly lacking in edge-case or error behavior, but adequate for a list operation.
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?
All three parameters are explained with examples, defaults, and environment variable reference, adding full meaning beyond the schema (which had 0% coverage).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and the resource 'deployment rolls for an Ocean cluster', and distinguishes from siblings like 'get_roll' (single roll) and 'initiate_roll' (create roll).
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 required and optional parameters, but does not explicitly state when to use this tool vs. alternatives like 'get_roll'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses sorting by savings potential (CPU delta), truncation to limit, default values, and parameter defaults; no annotations exist, so description covers behavioral traits well, though authentication requirements or side effects are unaddressed but appropriate for a read-only tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One-sentence purpose followed by a clear, bulleted parameter list; no redundancy, front-loaded, and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, description covers all necessary details: purpose, all parameters, sorting, truncation, and cloud support; no gaps for agent invocation.
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 coverage, description fully explains each parameter including example for cluster_id, optional namespace, account_id with env var fallback, cloud choices, and limit with all-results behavior; adds significant meaning beyond 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?
Clearly states it retrieves right-sizing suggestions for Ocean clusters on AWS/Azure, distinguishing it from other get tools like get_cluster or get_cost_trending.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives; does not specify when not to use or mention related tools for comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses behavior for verbose vs. compact output but does not mention read-only nature, authorization needs, or potential performance implications. Adequate but not exceptional.
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?
Well-structured with main purpose first, then explanation of verbose mode, then parameter list. Could be slightly more concise, but all sentences add value. No fluff.
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?
Describes default output (compact summaries with fields) and verbose output (full configs). Covers parameters and their defaults. Does not mention pagination or limits, but for a list tool with no required params, this is fairly complete.
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?
Schema coverage is 0%, but description adds detailed explanations for all three parameters: ocean_id with example, account_id with default behavior, and verbose with use-case guidance. 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'List AWS Ocean Virtual Node Groups' with a specific verb and resource. Distinguishes from siblings like get_vng (single) and filter_vngs_by_tag by focusing on listing all VNGs with optional filters.
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?
Provides clear context for when to use verbose mode ('analyzing VNG settings, troubleshooting, or comparing configs'). Also explains optional filters (ocean_id, account_id). Does not explicitly mention alternative tools like get_vng for single VNG or filter_vngs_by_tag for tag-based filtering, but the usage is inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description clearly explains the tool's behavior: compact summaries by default, verbose returns full configurations. It lacks disclosure of side effects or safety (e.g., read-only), but for a list operation this is sufficient. The parameter use is well described.
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 front-loaded and uses a clear structure with an Args section. Every sentence adds value, though it could be slightly more concise by merging some lines. Overall, it is efficient without waste.
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 (list operation with 3 params) and the presence of an output schema, the description covers the main behaviors: default vs verbose output, filter by ocean_id. It omits potential details like pagination or constraints on account_id, but is largely complete for common use cases.
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?
The schema had 0% description coverage, so the description compensates fully. It explains each of the 3 parameters: ocean_id for filtering by cluster ID, account_id for Azure account, verbose for full configurations. This adds significant meaning beyond the schema's type and title.
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 starts with 'List Azure Ocean Virtual Node Groups', clearly stating the verb and resource. It distinguishes from siblings like 'list_vngs' (likely for AWS) and 'get_vng_azure' (single VNG). The addition of default and verbose behaviors further clarifies the tool's purpose.
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 guidance on when to use the verbose parameter ('Use when analyzing VNG settings...'), but does not explicitly compare this tool to alternatives like 'get_vng_azure' or when not to use it. The usage context 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, the description should disclose safety and behavior. It explains parameter defaults (account_id env var, cloud defaults to aws) but does not state whether the operation is read-only, idempotent, or what happens on invalid input.
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 concise: one sentence for purpose, then a clean Args section with clear parameter explanations. Every sentence adds value, no redundancy.
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?
The description covers purpose, parameters, and use case. Since an output schema exists, detailed return value documentation is not needed. However, it lacks information about error handling or edge cases.
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?
Schema has 0% description coverage, but the description adds valuable meaning: example for cluster_id ('e.g. o-abc12345'), explains account_id fallback to environment variable, and lists valid cloud providers ('aws or azure'). This significantly compensates for the schema gap.
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 action ('Export') and the resource ('Ocean cluster configuration as YAML'), with a specific use case ('GitOps comparison or backup'). This distinguishes it from sibling tools like get_cluster which likely return JSON.
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 mentions specific use cases ('GitOps comparison or backup') but does not explicitly exclude alternatives or provide when-not-to-use guidance. It implies usage context well.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses important behaviors: aggregation by namespace, sorting by cost descending, limit behavior, and that only 'namespace' is supported for group_by. This helps the agent understand side effects and constraints.
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 uses a clear 'Args' list structure but is somewhat long. It front-loads the purpose then details parameters. Every sentence provides value, though some parameter explanations could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description need not explain return values. It covers all seven parameters, their defaults, and special behaviors (e.g., limit=0). For a tool with this complexity, the description is fully sufficient.
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?
Schema coverage is 0%, but the description fully documents each parameter with examples, defaults, allowed values (e.g., cloud: 'aws or azure'), and behavioral notes (e.g., group_by only supports 'namespace', limit=0 returns all). This adds significant value beyond 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 'Get aggregated cost breakdown for an Ocean cluster (AWS or Azure).' It specifies the resource (Ocean cluster), action (get aggregated cost breakdown), and cloud support, distinguishing it from sibling tools like get_cluster or get_cost_trending.
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 parameter details and implies usage (e.g., when needing cost breakdown by namespace for a specific cluster), but lacks explicit guidance on when to use this tool versus alternatives like get_cost_trending or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behavioral details: supported values for group_by (only namespace), defaults, and optional parameters. No annotations exist to contradict. Could mention read-only nature but not required.
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?
Well-structured with a clear opening sentence and labeled Args section. Slightly verbose but every sentence adds value; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, schema descriptions, or output schema details in context, the description covers all parameters, constraints, and usage context comprehensively. Adequate for an agent to use correctly.
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?
Schema description coverage is 0%, but description compensates fully by explaining each parameter's meaning, giving an example for cluster_id, clarifying period defaults, and noting the group_by restriction.
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?
Clearly states the tool retrieves cost trends over multiple time periods for an Ocean cluster. Specifies 'week-over-week or custom period cost changes', differentiating it from siblings like get_cluster_costs or get_savings_summary.
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?
Provides parameter details and defaults, implying usage context. However, lacks explicit guidance on when to use this tool versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It correctly implies a read-only operation (get details) but does not explicitly state safety or side effects. The absence of contradictions is noted.
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 concise: one sentence for purpose followed by bullet-like parameter explanations. No fluff, and the most important information (what the tool does) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema (handling return value details) and only two parameters, the description sufficiently covers the input semantics. No missing information for correct 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 coverage is 0%, so the description adds critical meaning: provides an example for vng_id and explains the default behavior of account_id. This goes beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get details of a specific AWS VNG (launch spec)', using a specific verb and resource. It distinguishes from sibling tools like list_vngs (list all) and create_vng/delete_vng/update_vng (mutations).
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 context is clear: use this tool when you have a VNG ID and want its details. However, it does not explicitly state when not to use it or mention alternatives, which would be helpful for disambiguation among sibling tools like get_vng_azure.
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?
Discloses destructive nature, confirm requirement, and auto-encoding of userData. With no annotations, the description carries full burden; it lacks details on synchronous/asynchronous behavior, return format, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Succinctly front-loaded with 'DESTRUCTIVE' and purpose, followed by a structured parameter list. Every sentence provides value, no redundancy.
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?
Covers essential aspects including destructive nature, confirm guard, encoding, and optional parameters. Minor gaps: no mention of output despite presence of output schema, and no error handling or prerequisites.
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?
Schema coverage is 0%, but the description exhaustively explains all 6 parameters with example values and behaviors, fully compensating for missing schema descriptions.
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?
Clearly states 'Update an AWS VNG (launch spec) configuration' with a prominent 'DESTRUCTIVE' label. Distinguishes from siblings like create_vng, delete_vng, and get_vng.
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?
Provides instructions on required confirm=true, JSON string updates, and encoding behavior. Does not explicitly contrast with alternatives but context from sibling names clarifies when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 discloses the destructive nature, the safety guard (confirm), and details the behavior of delete_nodes (drain+detach+terminate) and force_delete (delete even if last non-template VNG). It does not mention reversibility or all side effects, but covers key behaviors.
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 bold warning, then bullet points for parameters. It is front-loaded with purpose. While slightly verbose with 'Args:' formatting, every sentence adds value, so it earns its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no annotations, and destructive action, the description covers purpose, parameters, and edge cases (force_delete condition). It lacks explanation of return values, but an output schema exists to fill that gap. Overall complete.
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?
Schema description coverage is 0%, so the description must compensate. It explains each parameter beyond the schema: confirm as safety guard, account_id optional with env var default, delete_nodes behavior, force_delete condition. This adds significant value for correct tool invocation.
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 'Delete an AWS VNG (launch spec)' with a 'DESTRUCTIVE' warning, immediately identifying the action and resource. It distinguishes from sibling tools like create_vng, update_vng, get_vng.
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 explains that confirm=true is required for execution and provides conditions for force_delete. However, it does not explicitly state when to use this tool versus alternatives, though the destructive nature and parameter details offer implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 explains that limit=0 returns all results, specifies defaults (cloud: aws), and gives an example for cluster_id. Although it does not explicitly state that the operation is read-only, the verb 'List' strongly implies no side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: a one-line purpose followed by a bulleted list of parameters. Each sentence is informative without redundancy. It is well-front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (and likely describes the return format), the description covers the operation's purpose, all parameters with examples and defaults, and the limit behavior. It is sufficient for an AI agent to understand and use the tool correctly without additional context.
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?
Schema description coverage is 0%, so the description must compensate fully. It provides meaningful details for all 4 parameters: explains cluster_id with example, account_id with env var default, cloud with allowed values, and limit with special value 0 behavior. This adds significant value beyond the raw 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 'List all nodes in an Ocean cluster (AWS or Azure)', which is a specific verb (List) and resource (nodes in a cluster). This distinguishes it from sibling tools like list_clusters (which lists clusters) or get_cluster (which gets cluster details).
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 context (when you need nodes for a specific cluster) but does not explicitly state when to use this tool versus alternatives like get_cluster or list_clusters. It provides parameter guidance but no explicit when-not-to or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description prominently labels the tool as 'DESTRUCTIVE' and explains the behavior (drain and replace nodes in batches). It also warns about accidental rolls with the confirm parameter. Without annotations, it carries the full burden and does so adequately, though it could mention if the action is synchronous or asynchronous.
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 warning and bullet-pointed arguments. It is somewhat lengthy but every sentence adds value. Minor redundancy (e.g., 'Requires confirm=true' could be part of the confirm description).
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 no annotations, the description covers behavior, all parameters, and a safety warning. It does not discuss error conditions or prerequisites (e.g., permissions), but the output schema may handle return values. Overall comprehensive for initiating a roll.
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 explaining all 9 parameters: providing examples (e.g., cluster_id: 'o-abc12345'), clarifying the confirm guard, and stating defaults. This goes well beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Initiate a rolling restart'), the resource ('nodes in an Ocean cluster'), and the process ('drain and replace nodes in batches'). It distinguishes itself from siblings like get_roll or list_rolls by focusing on initiation.
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 explains when to use (for rolling restart), explicitly requires confirm=true as a safety guard, and mentions default values. However, it does not explicitly compare to alternatives like get_roll for monitoring or list_rolls for existing rolls, but the instructions are clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes default compact summaries vs. verbose full configs, and works for AWS/Azure. No annotations provided, so description carries full burden; it adequately discloses behavior without contradictions.
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?
Well-structured with a brief intro followed by bullet-point argument descriptions. Slightly longer than necessary but earns its length with valuable detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Completely covers use case, parameter behavior, output options, and cloud support. Output schema exists, so no need to detail return values.
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 coverage, description explains each parameter (tag_key, tag_value, account_id, cloud, verbose) with examples and usage context, far exceeding schema's minimal info.
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?
Clearly states it filters Ocean clusters by tag key and optionally tag value, specifying the resource and action. Distinguishes from sibling 'filter_vngs_by_tag' by targeting clusters.
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?
Provides context for when to use (filtering by tag) and guidance for verbose mode (analyzing cluster settings, troubleshooting). Lacks explicit 'when not to use' or direct alternatives, but sibling names imply differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description reveals key behavior: parallel scanning across accounts, default compact summaries, and verbose mode for full configs. However, it omits potential performance or rate-limit implications.
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 brief, front-loads the core purpose, and organizes parameter details in a clear Args section. No redundant text.
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 an output schema exists and the tool is simple, the description covers purpose, behavior, and parameter. It could explicitly differentiate from sibling cluster listing tools, but overall is adequate.
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?
The single parameter 'verbose' has no schema description (0% coverage), but the description adds full meaning: it controls compact vs full configs, and provides use cases like troubleshooting. This compensates well.
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 'List ALL Ocean clusters across ALL accounts and cloud providers (AWS + Azure)', with specific verb 'list' and resource 'clusters', and the scope distinguishes it from sibling tools like list_clusters which are likely per-account.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (for a global view) but does not explicitly compare to siblings like list_clusters or list_clusters_azure, nor mention when not to use it. The 'verbose' parameter guidance is good.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: returns compact summaries by default, full configs with verbose=true. It explains the output modes and parameter effects. Missing details on pagination or limits, but acceptable for a list operation with two parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured: a concise opening sentence, followed by clear bullet-point style for output modes, and a structured Args section. Every sentence adds value without redundancy.
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?
The description covers input parameters, default behavior, and output variations. It is sufficient for a list tool with two parameters and an output schema. However, it does not mention pagination or limits, and could explicitly reference sibling tools for singular retrieval (get_elastigroup) for complete context.
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?
Schema has 0% description coverage, so the description compensates fully. It explains that account_id is optional and defaults to an environment variable, and verbose returns full configurations with specific use cases. This adds significant meaning beyond the schema's bare types and defaults.
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 'List all Elastigroups in a Spotinst account' with specific verb and resource. It distinguishes between compact summaries and full configurations via the verbose parameter, and contrasts with sibling tools like get_elastigroup (singular) through implication.
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 guidance on when to use verbose=true ('analyzing Elastigroup settings, troubleshooting, or comparing configs'). However, it lacks explicit differentiation from sibling tools like get_elastigroup (for a single group) or list_accounts, and does not state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states it returns a report of accessible vs denied endpoints, disclosing output behavior. With no annotations provided, it carries the full burden and does so adequately, though it could explicitly note it is non-destructive (implied by 'probe').
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?
Three concise sentences, each adding value: purpose, usage guidance, output description. No wasted words. Front-loaded with the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and a simple output (accessible vs denied endpoints), the description is fully complete. It covers purpose, when to use, and what to expect. No output schema needed as description defines it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100% by default, so the description adds no parameter information. Baseline 4 is appropriate for no-parameter tools.
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 probes token capabilities against Spot.io API endpoints. It uses a specific verb (probe) and resource (token capabilities), and distinguishes well from siblings which are CRUD or operational tools.
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 explicitly advises to call this first to understand what tools will work with the token, providing clear context for when to use it. It doesn't list when-not or alternatives, but for a diagnostic tool this is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses default compact summaries and full configs with verbose, indicating read-only operation. No annotations exist, so description carries burden; lacks details on pagination, ordering, or limits.
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?
Efficient, front-loaded main purpose, uses bullet-style formatting for args with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a list tool with output schema: covers both parameters, default behavior, and two output modes. No missing critical details given low complexity.
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?
Adds significant meaning beyond schema: explains account_id default behavior (env var) and verbose intent, with 0% schema description coverage. Both parameters well-documented.
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 action (list) and resource (Stateful Nodes/Managed Instances in AWS account), and the name distinguishes it from siblings like get_stateful_node and list_stateful_nodes_azure.
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?
Provides guidance on when to use verbose mode ('analyzing node settings, troubleshooting, comparing configs') but does not explicitly exclude other similar list tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/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 explicitly labels the tool as 'DESTRUCTIVE' and explains required confirmation, auto-encoding of userData, and immediate node launch via initial_nodes.
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 warning, paragraph explanations, and bullet points for parameters. It is slightly verbose but every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite missing annotations, the description covers behavioral traits, parameter details, prerequisites, and side effects. The presence of an output schema likely covers return values, making the description complete.
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?
Schema description coverage is 0%, so the description must compensate. It thoroughly explains all 6 parameters, adding critical context like oceanId exclusion from spec_json, requirement for confirm=true, and default behavior of encode_user_data.
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 explicitly states 'Create a new AWS VNG (launch spec) under an Ocean cluster.' with a specific verb and resource, and it distinguishes from sibling 'update_vng' by referencing its similarity.
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 instructions: requires confirm=true, oceanId is injected, and userData encoding is automatic. It does not explicitly list when not to use, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fully discloses behavioral traits: it starts with 'DESTRUCTIVE', details how each strategy affects instances (graceful drain vs. abrupt kill vs. permanent removal), mentions safety guard confirm, and notes cloud-specific restrictions. This goes beyond typical transparency expectations.
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 well-structured with a warning header, recommendation line, strategy bullets, and parameter list. Every sentence adds value without redundancy, and key points are front-loaded (destructive nature, recommended, confirm requirement).
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?
The description covers usage, parameters, and strategies thoroughly. However, it does not describe the return value or output schema (which exists), leaving a minor gap for agents expecting result details. Otherwise, it is complete for the tool's destructive purpose.
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?
Despite 0% schema coverage, the description adds complete semantics for all 7 parameters: format examples, defaults, strategies list, batch size context, cloud provider limits, and environment variable fallback. This compensates fully for the sparse 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 verb 'remove instances', resource 'Ocean cluster', and method 'using a named strategy'. It also distinguishes itself from siblings by claiming 'this is the RECOMMENDED tool for instance removal', making its purpose unambiguous.
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 explicit guidance on when to use each strategy (e.g., drain_and_replace for production safety, replace for speed, remove_permanently for downsizing), and requires confirm=true. It does not compare with sibling tools like detach_instances, but the recommendation serves as a clear usage directive.
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:

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

Score Badge

Copy to your README.md:

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

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/arnstarn/mcp-server-spotinst'

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