Gcore MCP Server

Official

by G-Core

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation3/5
Most tools have distinct purposes, but there is confusion because image-related tools (e.g., cloud_insts_imgs_ls) are nested under the 'insts' prefix, making them appear to be instance operations. Also, cloud_insts_act is a proxy for various actions, which could overlap with specific tools like cloud_insts_resz.
Naming Consistency2/5
Naming is inconsistent: abbreviations like 'insts' and 'placegrps' mix with full words like 'projects' and 'regions'. Verb forms vary (new, del, upd, act, resz, add_placegrp, rm_placegrp) and the 'cloud_insts_' prefix is reused for flavors and images, violating the pattern.
Tool Count2/5
42 tools is excessive for a coherent set. Many are narrowly scoped sub-operations (e.g., assign/unassign security group, add/remove placement group) that could be merged. A typical well-scoped server has 3-15 tools.
Completeness2/5
The tool surface covers instances, projects, regions, quotas, and tasks but lacks fundamental resources: no volume CRUD, no security group lifecycle, no network/subnet/router management. Agents would likely fail when needing those operations.
Average 3.4/5 across 42 of 42 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 2 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden of behavioral disclosure. It only states 'get' without detailing authentication requirements, potential side effects, rate limits, or the scope of data returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but lacks necessary detail. It does not waste words, but it fails to provide adequate context for a tool with no annotations and generic parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete: it omits what the output looks like, how quotas are structured, and any prerequisites. With no output schema, the description must compensate, but it does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% coverage, and the description adds no information about the four parameters (extra_headers, extra_query, extra_body, timeout). An agent has no guidance on how to use these generic HTTP extras for this specific tool.
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 gets combined client quotas, including regional and global quotas. This explicitly distinguishes it from sibling tools like cloud_qotas_get_by_region and cloud_qotas_get_global, which retrieve only those subsets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For instance, it does not mention that if only regional or global quotas are needed, the specific siblings should be used.
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, the description must convey behavioral traits. It only states 'Get task' without disclosing whether the operation is read-only, has side effects, or requires any permissions. There is no mention of rate limits or data freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short ('Get task') followed by a parameter list. It is concise but under-specified. The parameter list could be formatted more efficiently, but there is no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should provide more context about the return value or behavior. It fails to explain what the tool returns (e.g., task object) or any edge cases (e.g., task not found). Incomplete for a simple retrieval tool.
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%. The description adds minimal value by restating parameter names with trivial clarifications (e.g., 'task_id: Task ID' is redundant). For 'extra_headers', 'Send extra headers' offers no additional meaning beyond the name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get task' clearly indicates the action and resource. It distinguishes from siblings like 'cloud_tsks_ls' (list tasks) by implying retrieval of a single task. However, it lacks specificity about what a 'task' represents in this context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description does not mention any prerequisites, limitations, or when not to use it. Sibling tools like 'cloud_tsks_ack_all' and 'cloud_tsks_ack_one' are not compared.
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. The phrase 'Get instance console URL' implies a read operation, but there is no explicit statement that the tool does not modify state, and no disclosure of potential failures or limits beyond the ID resolution note.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a one-line purpose, a parameter list, and a note. However, the parameter list is incomplete (missing required params), and the note is lengthy but contains valuable information. It could be more concise if it integrated the required parameter descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description minimally states the output is a console URL but does not elaborate on format. The note aids in parameter resolution but does not cover error conditions, console type values, or behavior when parameters are invalid. The missing required parameter descriptions significantly reduce completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The 'Args' section documents only optional parameters (console_type, extra_headers, etc.) but omits the three required parameters (instance_id, project_id, region_id). The schema covers them but without descriptions, and the description fails to define what these required fields represent, leaving ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Get instance console URL', which clearly states the action and resource. While sibling tools include many instance operations, this one is distinctly about retrieving a console URL. However, it does not explicitly differentiate from siblings or mention that it is a read-only operation.
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 note provides guidance on resolving numeric IDs from names or defaults, which helps the agent understand prerequisites. However, it does not state when to use this tool versus alternatives like 'cloud_insts_get' or 'cloud_insts_act', nor does it mention any exclusion criteria.
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 must disclose behavioral traits, but it only says 'Get global quotas', implying a read-only operation. No details about side effects, permissions, rate limits, or response structure are 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 short and front-loaded with the core purpose. Parameter listing is compact and non-redundant, though it includes typical code-generated docstring format, which is acceptable.
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 description explains the basic purpose and required parameter, but lacks context about return format, error handling, or typical use cases. Given no output schema, more completeness would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. However, it only provides minimal labels like 'Client ID' and generic explanations for extra headers/query/body/timeout, adding little value beyond the schema itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('global quotas') and specifies it's for a specific client via the required client_id parameter. However, it does not differentiate from sibling tools like cloud_qotas_get_all or cloud_qotas_get_by_region, which cover other scopes.
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, nor does it mention any prerequisites or exclusions. It simply states the function without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It does not disclose behavioral traits such as whether the rename is synchronous, any side effects, or prerequisites (e.g., instance state). The note only covers parameter resolution, not runtime behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and organized with parameter list and note. It is concise for 8 parameters, though the note is slightly verbose. Every sentence adds value, no redundancy.
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 complexity (8 params, no output schema), the description explains parameter resolution but omits return value, error scenarios, and side effects. It provides enough for basic usage but leaves gaps for robust agent decision-making.
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 must compensate. It adds context for 'project_id' and 'region_id' (use numeric IDs, resolve names). Other parameters get minimal explanations ('Name.', 'Send extra headers', etc.). Some ambiguity remains (e.g., 'name' could be current or new name). Partial compensation for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Rename instance', identifying the specific verb and resource. It distinguishes from sibling tools like 'cloud_insts_resz' (resize) and 'cloud_insts_del' (delete). However, it could be more explicit that this tool only handles renaming, not other updates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The note about resolving project/region IDs is technical, not usage context. Sibling tools imply different operations, but the description does not clarify when to prefer this tool over them.
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. The description does not disclose behavioral traits such as side effects (e.g., marking tasks as acknowledged), auth requirements, rate limits, or what happens to acknowledged tasks.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and lists parameters in a structured 'Args' block. It is concise but the parameter list is somewhat lengthy, though necessary given no schema descriptions.
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?
Missing output schema and annotations. The description does not explain the return value, error handling, or scope of 'all tasks' (e.g., whether it acknowledges only pending tasks). The parameter resolution notes are useful but insufficient for full understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds value for `project_id` and `region_id` by explaining resolution from names or defaults, but does not clarify the purpose or constraints of `extra_headers`, `extra_query`, `extra_body`, or `timeout`.
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 acknowledges all tasks, but does not differentiate it from the sibling tool `cloud_tsks_ack_one`, which acknowledges a single task.
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 `ack_all` vs `ack_one` or any alternative. The description only explains how to resolve project and region IDs.
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, the description carries full burden but fails to disclose behavioral traits such as whether acknowledgment is destructive, idempotent, or requires specific permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is minimal but includes a parameter list that is redundant with the schema. It is not verbose, but could be more structured or front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a mutation (acknowledge) with no output schema and no annotations, the description lacks details on return values, error handling, or side effects, making it incomplete for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%. The description lists parameters with generic text (e.g., 'Send extra headers') that adds little beyond the schema's type and property names. No meaningful semantic enrichment.
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 'Acknowledge one task' clearly states the verb (acknowledge) and resource (task), and distinguishes from the sibling 'cloud_tsks_ack_all' which handles all tasks.
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 like 'cloud_tsks_ack_all' or 'cloud_tsks_get'. The description implies single-task usage but lacks context 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?
No annotations are provided, so the description carries the full burden. It discloses that the tool expects numeric IDs and explains how to resolve them via other tools. However, it does not mention authentication, rate limits, side effects, or idempotency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise but has an unstructured 'Args' list and a long note that could be condensed. The main action sentence is clear, but the extra details could be better organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 9 parameters (3 required), no output schema, and no annotations, the description leaves gaps: no description for 'instance_id', vague explanation of 'ports_security_group_names', and no information about return values or error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It describes only 6 of 9 parameters, missing the required 'instance_id'. The description for 'ports_security_group_names' is vague ('Port security groups mapping'). The note about project and region IDs is helpful but incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Un-assign the security group to the server.' This distinguishes it from the sibling tool 'cloud_insts_assign_secgrp'. However, the phrasing could be more precise ('from the server' instead of 'to the server'), and it does not explicitly mention the instance resource.
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 one specific usage instruction: using NULL port_id to unassign from all ports. It does not discuss when to avoid this tool or compare it with alternatives beyond the implied opposite action.
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; the description does not disclose side effects, permissions, pagination behavior, or what happens with include_deleted. Extra parameters like extra_headers are listed without explanation of impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description includes a main sentence and a parameter list, which is structured but not extremely concise. It could be more front-loaded by prioritizing the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 10 parameters and no output schema, the description lacks details on return format, pagination limits, error handling, and how filtering by name works. It does not compensate for the missing output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description provides brief explanations for each parameter in the Args block. For limit and offset, it explains their roles. However, extra_headers, extra_query, extra_body are only minimally described.
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 'Retrieve a list of projects for a client', specifying the verb (retrieve) and resource (projects). It mentions filtering and ordering, and distinct from sibling tools like cloud_projs_del, cloud_projs_get, and cloud_projs_new.
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. There is no mention of when not to use it or comparison with siblings. The client_id filter is mentioned as for administrators but no further context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'Create a new project' (a write operation) and a prerequisite, but does not disclose return values, error conditions, idempotency, rate limits, or side effects. The note about each client having one 'default' project is a useful constraint but insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a purpose sentence, a prerequisite, then a parameter list. However, the parameter list dominates and could be shortened. Some lines like 'Send extra headers' are redundant with the parameter name. It is adequately concise but not front-loaded enough.
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?
With 8 parameters, 0% schema coverage, no output schema, and no annotations, the description is incomplete. It does not describe the return value (e.g., the created project ID or success message), error scenarios, or detailed behavior for each parameter. The tool is a creation operation, and such details are crucial for proper invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the parameter descriptions add value. Each parameter gets a brief comment (e.g., 'Unique project name for a client' for name, 'ID associated with the client' for client_id). However, these are minimal and lack detail on constraints, format, or allowed values (e.g., state has no enum).
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 creates a new project for a client, using a specific verb and resource. The tool name 'new' aligns with creation, but it does not explicitly differentiate from sibling tools like cloud_projs_get or cloud_projs_ls.
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?
It mentions a prerequisite (project management must be enabled) but does not provide guidance on when to use this tool over alternatives or when not to use it. The context of sibling names (e.g., cloud_projs_del, cloud_projs_upd) implies that for other operations one would use those, but this is not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It mentions disabling but omits side effects, required permissions, reversibility, or instance state prerequisites for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with 'Args:' and 'Note:' sections, making it organized. It is appropriately sized, though the note mixes parameter advice with procedural steps.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should explain return values, confirmations, or side effects. It lacks these, and fails to mention prerequisites for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. Notes on project_id and region_id (numeric, resolution) add value, but port_id is not described, and extra_* parameters lack explanation.
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 'Disable port security for instance interface', which specifies the action and resource. However, it does not explicitly differentiate from sibling tool 'cloud_insts_en_portsec' (presumably enable), relying on naming convention alone.
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 resolution guidelines (numeric IDs, fallback to defaults) but does not explain when to use this tool versus alternatives like enabling or managing security 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, and the description does not disclose the side effects of attaching an interface (e.g., mutation, permissions, or potential consequences). For a write operation, this lack of transparency is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at three sentences, front-loading the proxy nature. However, it could be more structured by adding a clear action statement. It avoids fluff but omits crucial details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 16 parameters, no output schema, and no annotations, the description fails to provide a complete picture. It only covers ID resolution, leaving the tool's purpose, parameter usage, and outcome unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description only addresses project_id and region_id, ignoring the other 13 parameters (e.g., instance_id, ddos_profile, security_groups). No meaning is added beyond the schema's structural information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Proxy for cloud.instances.interfaces.attach', which coupled with the tool name implies attaching an interface to an instance. However, it does not explicitly state the action, relying on the proxy reference. This is clear but not fully self-contained.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit, actionable guidance on resolving project_id and region_id, including fallback steps to default project and region. It distinguishes when to use resolution tools versus this tool.
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 fully disclose behavioral traits. It only states the basic action (detaching) without mentioning side effects, prerequisites (e.g., instance state), or consequences. This is insufficient for an agent to assess impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise but mixes an informal parameter list with a separate note, lacking structured formatting. It could be streamlined by listing all parameters clearly, though it avoids excessive verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters, 5 required, no output schema, and no annotations, the description should provide comprehensive guidance. It misses documenting key required parameters and behavioral aspects, leaving significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description lists some parameters (ip_address, port_id, extra_*) but omits required ones like instance_id, project_id, and region_id from the parameter list. The note about ID resolution helps but does not cover the missing parameter names, leaving the agent confused about required inputs.
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 tool name and the first sentence 'Detach interface from instance' clearly state the specific action and resource. This distinguishes it from sibling tools like cloud_insts_ifaces_att (attach) and cloud_insts_ifaces_ls (list).
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 note provides guidance on resolving project and region IDs, which aids in parameter usage. However, it does not explicitly state when to use this tool over others (e.g., detach vs list) or include when-not conditions. Usage context is implied but not fully elaborated.
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, the description must disclose behavioral traits. It states 'Update' but does not clarify whether it performs a partial or full update, what happens to unset fields, or if the operation is destructive. It also omits required permissions, rate limits, or return values. The note about resolving IDs hints at multi-step behavior, but key operational details are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description front-loads the purpose but then includes a long list of parameter descriptions. The note about resolving IDs is important but blocks together as a paragraph. For 14 parameters, some conciseness is lost, but it remains readable. Could be trimmed by merging redundant phrases (e.g., 'extra_headers' and 'extra_query' definitions).
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 covering all parameters and ID resolution, the description lacks information on the return value (no output schema), error handling, or permissions. Given the tool's complexity and absence of an output schema, the description should at least hint at what the response contains (e.g., updated image object). It also doesn't place the tool in the broader workflow context relative to sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates by explaining each parameter in plain language (e.g., 'hw_firmware_type: Specifies the type of firmware...'). The tags parameter gets a thorough explanation about read-only keys and cost integration. This adds significant value beyond the raw schema, which has no descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Update image properties and tags', clearly stating the action and resource. The tool name 'cloud_insts_imgs_upd' aligns with this purpose. However, it does not explicitly distinguish itself from sibling tools like 'cloud_insts_imgs_get' or 'cloud_insts_imgs_del', relying on the name and first sentence to imply the update function.
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 detailed instructions on resolving project_id and region_id when not provided, including fallback to defaults. It tells the agent how to prepare the required parameters. However, it does not specify when to use this tool over alternatives (e.g., when to update vs. delete), nor does it mention any prerequisites or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It does not mention whether actions are destructive, what permissions are needed, or what side effects occur (e.g., stopping, rebooting). The phrase 'Proxy for cloud.instances.action' is vague and lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph of four sentences. While it is not overly long, it could be better structured with bullet points or separate sections for parameter resolution. It is concise but lacks clear organization.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters, 4 required, and no output schema, the description is incomplete. It fails to explain the action parameter's valid values, other optional parameters, or the return value. The tool's complexity demands more comprehensive coverage to be fully useful.
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 coverage is 0%, so the description must explain parameters. It only addresses project_id and region_id resolution, leaving instance_id, action, activate_profile, extra_headers, extra_query, extra_body, and timeout unexplained. Users get no help on how to set these or what values are valid beyond the schema 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 states it is a proxy for cloud.instances.action, implying it performs actions on instances. It explains resolution of project_id and region_id, which clarifies the scope. However, it does not explicitly list the actions or distinguish them from sibling tools like cloud_insts_ls or cloud_insts_del.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on how to pass project_id and region_id, including resolving from names using other tools and defaulting when not provided. This helps the agent know how to use the tool correctly and which alternative tools to call for resolution.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only mentions 'change flavor' but does not disclose behavioral traits like whether the instance is rebooted, if it's destructive, or if any states are required. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a purpose statement, an 'Args' list, and a 'Notes' paragraph. The 'Args' section is redundant as it only lists parameter names without descriptions. Could be more concise by integrating parameter explanations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (8 parameters, 4 required, no output schema, no annotations), the description lacks crucial context: behavior during resize, prerequisites, error handling, and return value. It is insufficient for an agent to reliably invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning for project_id and region_id (explains resolution), but does not describe instance_id, flavor_id, or the extra_* parameters beyond their names. The notes add some value but are incomplete.
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 'Change flavor of the instance', which is a specific verb+resource. The tool name 'resz' implies resize, distinguishing it from siblings like cloud_insts_upd (update) or cloud_insts_act (action).
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 notes provide guidance on resolving project and region IDs (e.g., pass numeric, resolve names via other tools). However, it does not explicitly state when to use this tool over alternatives like cloud_insts_upd or prerequisites (e.g., instance must be stopped).
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 present, so the description must carry the full burden. It does not disclose what happens upon deletion (e.g., cascading effects, reversibility, authorization needs).
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 a clear purpose statement first, followed by parameter list and a note. No superfluous information, though the note is somewhat lengthy.
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?
Lacking annotations and output schema, the description partially compensates with ID resolution guidance. However, it omits explanation of required group_id and overall deletion behavior, leaving gaps 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?
Schema coverage is 0%, but the description documents extra_headers, extra_query, extra_body, timeout. The required parameters group_id, project_id, region_id are not described except for resolution of project/region IDs in the note, which adds partial value.
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 begins with 'Delete placement group', which clearly states the action and resource. Sibling tools include get, list, new, making it distinct.
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 does not explicitly state when to use this tool versus alternatives. It only provides ID resolution instructions, not usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose all behavioral traits. It only covers parameter resolution but does not mention that the tool is read-only, whether pagination exists, error handling, or the nature of the response. The description lacks transparency about the tool's behavior beyond parameter requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is approximately 100 words, structured with an 'Args:' section listing parameters. While it contains necessary resolution guidance, it is somewhat verbose with repetitive notes. A more concise version could separate the core purpose from parameter details, but it is acceptably structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters (2 required), no output schema, and no annotations. The description only addresses parameter resolution and does not cover the output format, pagination, error handling, or typical usage scenarios. Given the complexity, the description is incomplete and leaves important gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds valuable meaning for the required parameters (project_id and region_id) by explaining their resolution logic. However, optional parameters (extra_headers, extra_query, extra_body, timeout) are only listed with their names and types, adding no semantic value beyond the schema. The description partially compensates for the required parameters but not for the optional ones.
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 starts with 'List placement groups', which clearly states the action and resource. However, it does not distinguish this tool from siblings like 'cloud_placegrps_get' (for getting a specific group) or 'cloud_placegrps_new' (for creating). The purpose is clear but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on resolving project_id and region_id, including fallbacks to default project/region and referral to other tools (cloud.projects.list, cloud.projects.get, cloud.regions.list, cloud.regions.get). This helps the agent use the tool correctly. However, it does not indicate when to use this tool versus alternatives like 'cloud_placegrps_get' 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, so description carries full burden. It discloses defaults (limit 10, max 1000), deprecated param (`sorting`), and filtering details. However, it does not mention pagination behavior, response structure, or whether tasks of all states are included.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long and somewhat verbose, especially the parameter list. It front-loads with 'List tasks' but then dives into extensive details. The structure is clear but could be more concise.
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 15 parameters, no output schema, and no annotations, the description covers parameter details thoroughly. However, it lacks any description of the return value or error states, which are important for a listing 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?
Schema description coverage is 0%, so description must compensate. It does so well, explaining each parameter's purpose, format, defaults, and constraints (e.g., ISO datetime, limit range, array support, resolution hints). 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List tasks' and then details filtering parameters. However, it does not differentiate from sibling tool `cloud_tsks_get` (which likely gets a single task), so purpose is clear but not fully distinctive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus `cloud_tsks_get` or `cloud_tsks_ack_*`. The note about resolving project_id and region_id is useful for parameter preparation but not for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It does not state whether the operation is read-only, any side effects, or permission requirements. The note about ID resolution is useful but does not address the tool's behavior post-execution.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise. It starts with the core purpose, lists parameters, and adds a note. The note is necessary but could be more organized. Overall, it avoids redundancy and front-loads the primary action.
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?
No output schema is provided, so the description should explain return values, but it does not. The tool likely returns a placement group object; omitting this leaves agents without expected response format. The parameter resolution notes help, but the description is incomplete for a 'get' tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description adds meaning by specifying that project_id and region_id should be numeric and provides resolution steps. However, it does not elaborate on group_id or the optional parameters (extra_headers, etc.) beyond their names, leaving 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?
Description clearly states 'Get placement group', a specific verb and resource. Among sibling tools (cloud_placegrps_del, ls, new), 'Get' distinctly indicates retrieval of a single placement group, making the 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving a specific placement group but does not explicitly guide when to use this tool over siblings like cloud_placegrps_ls. The note provides resolution steps for project and region IDs, but lacks when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It only states the action but does not disclose side effects, reversibility, required permissions, or behavior if port security is already enabled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with 'Args:' and bullet points, but the parameter descriptions for extra_headers, extra_query, extra_body, and timeout are redundant with the schema. The key information on project/region resolution is valuable but could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, 3 required, and no output schema, the description is incomplete. It does not explain what port security is, what the tool returns, error conditions, or the meaning of port_id.
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?
Despite 0% schema coverage, the description adds semantic meaning for project_id and region_id (e.g., resolution rules). However, it does not explain port_id or the optional parameters beyond generic phrases like 'Send extra headers'.
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 'Enable port security for instance interface', clearly stating the action and resource. It is distinguishable from sibling tools like cloud_insts_dis_portsec which disables port security.
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 how to pass numeric project_id and region_id, including fallback resolution via other tools. However, it does not mention when to use this tool versus alternatives or prerequisites beyond parameter resolution.
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?
Describes pricing behavior for trial mode and disabled parameter default, but does not disclose other behavioral aspects like read-only nature, error handling, or potential side effects. Without annotations, description carries full burden but is partially adequate.
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?
Key information is front-loaded (purpose, pricing note). The Args list and Note are organized but somewhat verbose, especially with extra_headers/query/body which are typical. Could be shortened without losing value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers most parameters but lacks descriptions for output, pagination, sorting, or error conditions. Given 10 parameters and no output schema, more detail on expected results and edge cases would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description compensates for 0% schema coverage by explaining each parameter in the Args list. However, there is inconsistency between described defaults (e.g., disabled default true) and schema defaults (null), reducing reliability. Extra parameters lack deep explanation.
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 states it retrieves a list of available instance flavors, which is clear and specific. However, it does not explicitly differentiate from sibling tools like other list tools, though the name implies flavors.
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 guidance on when to use (to list flavors), includes details about include_prices and trial mode, and offers note on resolving project and region IDs. Lacks exclusion criteria or direct comparison to alternatives.
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 carries full behavioral disclosure burden. It explains that the instance must not already be in a server group and that bare metal is unsupported. It also details parameter resolution for project and region. However, it omits side effects, return value, permissions, and error cases, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a main sentence, constraints, args list, and note. It is somewhat lengthy but each part adds information. The args list partially duplicates the schema but adds context. Could be trimmed, but overall acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters (4 required), no output schema, and no annotations, the description should cover more. It lacks any description of return values, error conditions, or success behavior. It does address project/region resolution, but missing instance_id explanation and full behavioral details make it incomplete for an agent to fully understand the tool's usage and effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains servergroup_id as an affinity type and provides resolution notes for project_id and region_id. However, it fails to describe the required instance_id parameter at all, and extra_* parameters only get superficial descriptions ('Send extra headers'). This leaves significant meaning absent.
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 'Add an instance to a server group,' specifying the verb and resource. It distinguishes from sibling 'cloud_insts_rm_placegrp' by the opposite operation. Additional constraints like instance must not already be in a group and bare metal exclusion further clarify purpose.
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 includes when to use (add to server group) and conditions (instance not already in group, not bare metal). It provides guidance on resolving project_id and region_id via sibling tools. However, it does not explicitly list alternatives or when not to use beyond the stated constraints.
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 carry the burden of behavioral disclosure. It states 'List' without confirming it is read-only, and does not mention any side effects, error conditions, or limitations (e.g., pagination). This is minimal disclosure for a non-destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description starts with a clear purpose sentence, followed by a parameter list with mostly tautological definitions (e.g., 'extra_headers: Send extra headers'), and a long note. The note is valuable but verbose. It is adequately structured but could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters (3 required) and no output schema, the description explains how to resolve the key parameters but does not describe the output format or error behavior. It is sufficient for basic use but lacks completeness for an AI agent to fully understand the tool's behavior and return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It provides basic definitions for extra_headers, extra_query, extra_body, and timeout. Crucially, the note explains that project_id and region_id should be numeric and how to resolve names via other tools. However, instance_id lacks any description beyond being required.
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 network interfaces attached to the specified instance,' which specifies the verb (list), the resource (network interfaces), and distinguishes it from sibling tools like cloud_insts_ifaces_att (attach) and cloud_insts_ifaces_det (detach).
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 includes a long note on resolving project_id and region_id, which helps with correct parameter usage, but it does not explicitly state when to use this tool versus alternatives or provide any exclusionary guidance. The purpose is implied but not fully contextualized among siblings.
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 disclose behavior. It indicates a read operation ('Retrieve') and mentions a cookie parameter affecting output. However, it does not describe error handling, permissions, or return value structure. Given the lack of annotations, more detail 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured into sections but is verbose, including markdown formatting for cookie parameters. It could be more concise by integrating the notes into the main description. Front-loading is present but the length reduces efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 7 parameters, no output schema, and no annotations. The description provides parameter resolution context but lacks expected return values, error scenarios, or scope of 'detailed information'. This leaves gaps for an AI agent to fully understand tool behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description adds meaning. It explains the three required parameters (project_id, region_id, instance_id) with resolution rules. Optional parameters (extra_headers, extra_query, extra_body, timeout) are listed but not explained beyond names. Semantics for required params are well-addressed, but optional ones lack context.
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 detailed information about a specific instance, using specific verb 'Retrieve' and resource 'instance'. It distinguishes from sibling tools like cloud_insts_ls (list) and cloud_insts_get_con (console), making the 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 instructions on how to provide project_id, region_id (pass numeric, resolve names via other tools, use defaults). It guides the agent on when to use this tool after resolving names, though it does not explicitly 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.
Behavior3/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 explains the necessary ID resolution logic for project and region, but does not disclose authentication requirements, rate limits, or whether the operation is read-only (implied by 'get'). It lacks information about the return format or 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose and structured with an Args list and note. The Args list is somewhat verbose for generic parameters like extra_headers, but overall it is organized and reasonably concise.
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 8 parameters, no annotations, and no output schema, the description covers the ID resolution logic but fails to document the required image_id parameter and does not explain what the tool returns (e.g., fields, structure). This leaves the agent with incomplete context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains most optional parameters (include_prices, extra_headers, etc.) and the required project_id and region_id in the Note. However, the required image_id parameter is not described at all, leaving a 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 'Retrieve detailed information about a specific image,' which is a specific verb+resource. This distinguishes it from sibling tools like cloud_insts_imgs_ls (list images) and cloud_insts_imgs_del (delete images).
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 getting a single image's details, but it does not explicitly provide when to use this tool vs alternatives like listing or deleting images. No exclusions or alternative tool names are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description lacks disclosure of behavioral traits such as idempotency, error conditions, side effects (e.g., whether the volume is affected), or execution duration. It only describes the action and parameters without 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a brief intro, parameter list, and a note. However, some parameter descriptions are verbose (e.g., tags), and the note about project/region resolution is lengthy. It could be more concise without losing essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 16 parameters, no output schema, and no annotations, the description lacks key context such as return value format, error handling, or behavioral notes. It does not explain the purpose of 'extra_headers' or 'extra_body' adequately, leaving gaps for an AI 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%, so the description must compensate. It provides inline descriptions for each parameter (e.g., 'Image CPU architecture type: aarch64, x86_64'), adding meaning beyond the schema's type/enum constraints. Some descriptions are vague ('Send extra headers'), but overall it adds significant value.
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 starts with 'Create a new image from a bootable volume,' clearly specifying verb, resource, and source. It distinguishes from sibling tools like cloud_insts_imgs_del, cloud_insts_imgs_ls, and cloud_insts_imgs_upl, which handle deletion, listing, and updating images respectively.
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?
Explicit prerequisite: 'The volume must be bootable to create an image from it.' The note about resolving project/region IDs via other tools provides context on when to use this tool vs. auxiliary tools like cloud_projs_get and cloud_rgns_get. However, it does not explicitly state alternatives for creating images from other sources (e.g., upload).
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, yet the description does not disclose any behavioral traits such as safety, idempotency, or rate limits. It is a read operation but lacks explicit assurance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is moderately structured with clear sections but contains some redundancy and could be more concise. The docstring format is functional but not optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters and no output schema, the description does not explain return format, properly handle optional parameters like extra_headers, or provide comprehensive usage context. Gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides a docstring-style list of all parameters with brief descriptions, adding semantics to the schema. The note adds significant context for project_id and region_id. However, descriptions are terse.
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 instance metrics' and enumerates specific metric types (cpu, memory, network, disk). Sibling tools cover actions, flavors, images, etc., making this tool's purpose distinct.
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?
Description includes explicit note on resolving project_id and region_id via other tools, guiding when to use auxiliary calls. However, it does not explicitly state when to avoid or what alternatives exist.
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 implies a read operation ('Get') with no destructive behavior. It explains the region_id requirement but lacks details on authorization, error conditions, or response format. This is adequate but not rich.
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 a short line for purpose, a bullet list of parameters, and a note. It is front-loaded with the main action. The parameter list could be omitted if the schema were descriptive, but it still serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does not explain what the tool returns (e.g., quota values, format). For a complex tool with 6 parameters, more detail on expected output or behavior is needed for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists parameter names with minimal explanations (e.g., 'Send extra headers') that add little beyond the names themselves. The note about region_id is helpful, but overall parameter semantics are weak.
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 quotas for a specific region and client', specifying the verb, object, and scope. This distinguishes it from sibling tools like cloud_qotas_get_all and cloud_qotas_get_global by indicating it is region- and client-specific.
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 how to obtain the numeric region_id using cloud.regions.list or cloud.regions.get, and advises to get the default region if none is mentioned. However, it does not contrast with sibling quota tools or specify 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.
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 'Get region' without mentioning side effects, read-only nature, rate limits, or response format. This is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short but includes an Args section that largely repeats the schema. The note is useful. Could be more concise by removing redundant 'Get region' and integrating Args into a single sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Parameters are explained and usage note is given, but no output schema exists and the description does not describe the return value or behavior. For a simple GET-like tool, this is a gap.
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 adds meaning: region_id must be numeric, show_volume_types behavior (replaces null with list), and extra headers/query/body/timeout. This compensates well.
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?
Description states 'Get region' — a clear verb+resource. It implicitly differentiates from sibling like cloud_rgns_ls (list regions) but does not explicitly distinguish itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Note provides explicit guidance: pass numeric region_id, resolve names with list/get, and obtain default region if none mentioned. This clearly tells when and how to use the tool.
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 fully disclose behavioral traits. It fails to mention the return value, whether upload is synchronous or async, any failure modes, or authentication requirements. The note on project/region resolution is the only behavioral context, leaving significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy (30+ lines) with a parameter list and usage note. It is structured with a clear intro, args section, and note, but some parameter descriptions are verbose and could be condensed. The front-loading is adequate but not optimal.
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 18 parameters, no output schema, and no annotations, the description covers parameter details and project/region resolution well. However, it omits critical context like the return value (e.g., image ID), completion behavior (sync/async), error handling, and permissions. Thus, it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the tool's description provides detailed parameter explanations, including allowed values for enums (e.g., architecture, hw_firmware_type) and meanings (e.g., cow_format, tags). This adds substantial meaning beyond the bare schema. However, parameters like extra_headers, extra_query, extra_body remain vague.
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 'Upload an image from a URL,' which is a specific verb+resource. It distinguishes from sibling tools like cloud_insts_imgs_ls, cloud_insts_imgs_del, etc., which perform different actions on images. The title, though absent, is not needed for clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a detailed note on how to resolve project_id and region_id from names or defaults, providing explicit guidance for using these required parameters. However, it does not specify when not to use this tool versus other image tools (e.g., cloud_insts_imgs_new_vol), but the purpose is clear enough.
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 transparency. It does not disclose that this is a read-only operation (safe side effect), nor does it mention authentication requirements, rate limits, or output behavior. For a list tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose but becomes lengthy due to the extensive parameter list and note. While the detail is necessary given 32 parameters, it could be more succinct by grouping related filters or using tables. The structure is logical but verbose.
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 complexity (32 parameters, no output schema, no annotations), the description covers parameter semantics well and provides a helpful resolution note. However, it lacks information about output format, pagination (limit/offset behavior), error handling, and default values for optional parameters, leaving minor gaps.
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 fully compensates with a detailed docstring for each parameter. It explains partial matching (ip, name), dependencies (profile_name etc. require with_ddos), and filtering nuances. This adds substantial meaning 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 begins with a clear verb+resource statement: 'List all instances in the specified project and region.' It specifies scope and resource, and distinguishes from sibling tools like cloud_insts_get (single instance) and cloud_insts_act (actions). The extensive parameter list further clarifies the filtering capability.
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 includes a note on resolving project_id and region_id, offering guidance on parameter preparation. However, it does not explicitly state when to use this tool versus alternatives (e.g., cloud_insts_get for a single instance) or when not to use it, missing clear usage boundaries.
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 discloses the constraint about protected snapshots and details the resolution process for project and region identifiers. Lacks mention of return values or irreversibility, but is sufficient for a deletion operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose, especially the 'Args:' section which duplicates schema information. The important resolution note is long but could be more succinct. Front-loading is adequate but not optimized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers the core action and constraints. It does not explain return values or success indications, but for a simple delete operation, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0% description coverage. The description explains the resolution for project_id and region_id but only lists extra_headers, extra_query, extra_body, and timeout without adding meaning beyond the schema. Partially compensates 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?
The description clearly states 'Delete a specific image' with a specific verb and resource. It distinguishes from sibling tools like cloud_insts_imgs_ls (list), cloud_insts_imgs_get (get), etc., by the action of deletion.
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 explicit guidance on resolving project_id and region_id, and notes that deletion is blocked if image is used by protected snapshots. Does not explicitly state when to use this tool over alternatives, but the context is helpful.
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 the full burden. It discloses important behavioral traits: the effect of NULL port_id for multiple groups, and the resolution logic for project and region identifiers. However, it lacks details on idempotency, error handling, or response behavior. Still, the described nuances add significant value beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a brief main statement, a usage tip, a parameter list, and a separate note. It is front-loaded with the core action, but the parameter list is somewhat verbose, and the note on project/region resolution is lengthy but necessary. A more concise formatting (e.g., bullet points for usage guidelines) would improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters, 3 required, no output schema, and no annotations, the description covers the main action, parameter usage, and important resolution details. However, it does not describe the return value, error conditions, or idempotency. For a tool with many generic extra_* parameters, the description is adequate but lacks some behavioral context to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description must compensate. It explains key parameters like name ('applies to all ports') and ports_security_group_names ('Port security groups mapping'), and provides a detailed note on project_id and region_id resolution. However, generic parameters (extra_headers, etc.) are only listed without further explanation, and the schema's PortsSecurityGroupName structure is not described in prose. The description adds moderate semantic value but is not exhaustive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Assign the security group to the server.' It uses a specific verb ('Assign') and resource ('security group to server'), and the sibling tool 'cloud_insts_unassign_secgrp' provides a clear opposite, aiding differentiation.
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 usage guidance, such as using NULL for port_id to assign multiple security groups to all ports, and detailed instructions for resolving project_id and region_id. While it doesn't explicitly contrast with sibling tools, the context implies when to use (assigning security groups) vs unassigning. The guidance is actionable and clear.
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 the full burden. It discloses key behaviors: limit defaults to 100 with max 1000, offset skips records, order_by uses field/direction, product filtering, show_volume_types modifies output, and parameters for extra headers/query/body/timeout. However, it omits higher-level details like idempotency, safety, or rate limits.
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 bullet list with a one-line purpose. It is reasonably concise, though some parameter details (e.g., limit defaults) could be more succinctly integrated. Overall, it communicates effectively without excessive verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, no output schema, no annotations), the description covers parameter behaviors but lacks explanation of return values, pagination beyond limit/offset, error handling, and authentication needs. This gap reduces completeness for an agent seeking full 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?
With 0% schema description coverage, the description compensates thoroughly. It explains the meaning and constraints for limit, offset, order_by, product, show_volume_types, extra_headers, extra_query, extra_body, and timeout, adding substantial value beyond the schema's type/enum definitions.
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 regions', providing a specific verb ('list') and resource ('regions'). This clearly distinguishes it from sibling tools like cloud_rgns_get (which retrieves a single region) and other list operations acting on different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives like cloud_rgns_get or other list tools. It does not mention prerequisites, scenarios, or exclude conditions.
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 discloses that the tool deletes an instance and lists parameters like delete_floatings and volumes, hinting at side effects. But it does not explicitly state irreversibility, required permissions, or other behavioral traits, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly concise given the tool's complexity, with an Args list and a note block. It is front-loaded with the basic purpose, but could be more streamlined.
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 parameters and input resolution well, but lacks information about return values, error handling, or idempotency. Given the high complexity and no output schema, these omissions are notable but not critical.
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 description coverage is 0%, but the description provides clear, meaningful explanations for all 11 parameters, including constraints like 'Can't be used with `floatings`' for delete_floatings and resolution logic for project_id and region_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 'Delete instance' and lists specific parameters, indicating the action and resource. The tool name 'cloud_insts_del' and its siblings (e.g., cloud_insts_get, cloud_insts_new) help distinguish it from other operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a note on resolving project_id and region_id with fallback behaviors, which implicitly guides usage. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention prerequisites or permissions.
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 carries the full burden. It states the tool creates a placement group (write operation) and explains ID resolution steps, but does not disclose permissions, error conditions, or side effects like duplicate group handling.
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 moderately concise: a purpose sentence, a structured Args list, and a Note. The Note could be more streamlined, but overall it's well-organized 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?
The description covers purpose and parameter resolutions but lacks details about the return value (no output schema). It does not mention pagination, error handling, or the response format, leaving some gaps for a creation 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?
Schema description coverage is 0%, so the description compensates by listing and describing all parameters. It adds meaning to name and policy beyond the schema, but extra_* fields get generic explanations. The Note adds crucial context for project_id and region_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 the action ('Create') and the resource ('placement group') with specific policy types (affinity, anti-affinity, soft-anti-affinity). This distinguishes it from sibling tools like cloud_placegrps_del (delete) and cloud_placegrps_ls (list).
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 resolving project_id and region_id when names are given, including which sibling tools to use for resolution. It does not include when-not-to-use or alternatives for the tool itself, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavior. It mentions that removal requires the instance to be in a group and that bare metal servers are unsupported, but it does not disclose potential side effects, permissions, or reversibility. The notes on ID resolution add context but leave gaps in behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a clear purpose first, followed by constraints, parameter list, and resolution notes. It is somewhat verbose but each section adds value. The list of optional parameters (extra_headers, etc.) could be more concise, but overall it is well-organized.
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 output schema and no annotations, the description covers the core functionality, constraints, and parameter resolution. It lacks details on return values or error handling, but for a removal tool this is acceptable. The context signals (7 params, 3 required) are adequately addressed.
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 must explain parameters. It adds meaning for the required parameters (project_id and region_id) by specifying they must be numeric and how to resolve names. However, it does not describe the purpose of instance_id beyond the tool's name, and extra parameters are only listed without semantic explanation.
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 ('Remove an instance from its current server group'), specifying the verb (remove) and the resources (instance, server group). This distinguishes it from sibling tools like cloud_insts_add_placegrp (add) and cloud_placegrps_del (delete server group).
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 context for when to use: 'The instance must be in a server group to be removed. Bare metal servers do not support server groups.' It does not explicitly mention alternatives, but the sibling tools indicate when to add or delete groups. The resolution notes for project and region IDs also guide correct usage.
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 parameter interactions (e.g., user_data vs password, name_template placeholders) and platform-specific behavior. It lacks information about failure modes, rate limits, or authentication needs, but the depth of explanation compensates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose and contains repetition (e.g., password and user_data details appear both in the how-to section and parameter descriptions). While structured with headings and bullet-like args, it could be more concise without losing clarity.
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 20 parameters, no output schema, and no annotations, the description is fairly complete. It explains most parameters, covers edge cases, and provides resolution hints for project/region IDs. However, it omits a description of the return value and any prerequisites beyond parameter resolution.
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 explain all parameters. It does so extensively, often with conditional logic (Linux/Windows), examples (e.g., servergroup_id types), and cross-references (e.g., ssh_key_name via /v1/ssh_keys endpoint). This adds significant meaning beyond the schema's type definitions.
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 'Create an instance with specified configuration,' clearly stating the verb (create) and resource (instance). This distinguishes it from sibling tools like cloud_insts_ls (list), cloud_insts_del (delete), and cloud_insts_upd (update).
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 detailed guidance on parameter usage for Linux vs Windows, including inter-parameter dependencies (e.g., user_data ignored when password provided). It also advises resolving project_id and region_id using other tools. However, it does not explicitly state when not to use this tool or list alternatives for specific cases.
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 provided; the description implies a read-only operation through 'Retrieve list' and lacks side-effect language. While not explicitly stating idempotency, the intent is clear and truthful.
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-organized with initial purpose, filtering capabilities, ownership note, then Args list, and Note section. A few generic parameters (extra_headers) add length but structure aids readability.
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 all parameters and essential resolution logic. Lacks explicit return format description, but given no output schema, the mention of 'returned entities' provides enough context for an image list.
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 the description compensates with an Args section explaining every parameter's purpose (e.g., 'include_prices: Show price', 'visibility: Image visibility'). The Note also clarifies project_id and region_id resolution.
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?
Explicitly states 'Retrieve a list of available images' with verb+resource. Differentiates from sibling tools like cloud_insts_imgs_del (delete), cloud_insts_imgs_get (get single), and cloud_insts_imgs_new_vol (create) by focusing on listing.
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 on when to use by detailing how to resolve project_id and region_id, including fallback to default. Does not explicitly exclude alternative list tools, but the note on resolution guides preparation.
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 irreversibility and inability to delete default projects. No annotations, so description carries burden; adequately warns about destructive nature.
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 clear sentences plus a structured note. Every sentence adds value, no fluff. Front-loaded with main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all essential aspects: operation, scope, constraint, parameter usage. Lacks return value description, but no output schema exists.
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?
Adds significant meaning to the key parameter project_id beyond the schema (numeric, resolution logic). Other parameters (extra_headers, etc.) are typical and need no extra explanation.
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 'Delete a project and all its associated cloud resources across all regions', specifying verb and resource. Distinguishes from sibling tools like cloud_projs_get and cloud_projs_ls.
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 explicit instructions on how to provide project_id, including resolution from name or default. Does not mention when not to use or alternatives, but the note gives clear context.
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 the full burden. It discloses that the tool expects numeric ID (not name) and describes fallback behavior for missing ID. However, it does not specify return format or confirm read-only nature, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: purpose sentence, arg list with one-liners, and a crucial note. No redundant text, and the key usage guidance is prominent. Every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for input handling but lacking output information. No output schema exists, and the description does not detail what 'detailed information' comprises (fields, structure). This leaves the agent uncertain about the return value, a notable gap.
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 adds value: it explains extra_headers, extra_query, extra_body, timeout purposes briefly. For project_id, it adds 'numeric' beyond the integer type. This adequately fills gaps in 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 'Retrieve detailed information about a specific project', using a specific verb and resource. It distinguishes from sibling tools like cloud_projs_ls (list) and cloud_projs_del (delete) by focusing on a single project retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The note explicitly guides when to use this tool: requires numeric project_id, but if given a name, resolve via cloud.projects.list/get, and if nothing, fetch default project. This provides clear alternatives and context for invocation.
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:

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

Score Badge

Copy to your README.md:

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

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/G-Core/gcore-mcp-server'

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