MCP-OpenStack-Ops

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation2/5
Multiple tools for instance queries (get_instance, get_instance_details, search_instances, etc.) overlap significantly, causing confusion about which to use. While most other tools are distinct, this redundancy harms overall disambiguation.
Naming Consistency5/5
All tools follow a consistent 'get_<resource>' pattern (e.g., get_availability_zones, get_floating_ip_pools). No mixing of verbs or styles, making the naming highly predictable.
Tool Count4/5
41 tools is on the high side but appropriate given OpenStack's broad service landscape. Redundant instance tools could be consolidated, but the count is not excessive.
Completeness2/5
The tool surface is entirely read-only (all get operations). For an 'Ops' server, this lacks essential create, update, and delete capabilities, leaving significant gaps for management tasks.
Average 4/5 across 41 of 41 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 7 commits in the last 12 weeks
- Last stable release on April 30, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states that it returns a JSON string with availability zones information. It does not disclose read-only behavior, authentication requirements, or any side effects. The description carries the full burden and is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two lines) and front-loaded with the purpose. However, it could be slightly more informative while still concise. It is not bloated, but it lacks detail.
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 that the tool has no parameters and an output schema exists, the description is minimally adequate. However, it could mention that the output returns status information. Compared to the sibling complexity, it is incomplete in guiding the agent on when to use this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema already covers everything. The description adds no extra parameter information, but with no parameters, the baseline is 4. It does not detract but also does not add 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 states 'List availability zones and their status', which clearly indicates the action and resource. However, it does not explicitly differentiate from the sibling tool 'get_load_balancer_availability_zones', which could cause confusion despite being contextually different.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as the load balancer-specific availability zones tool. There is no mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavioral traits. It states the tool returns 'detailed information or error message if not found,' which is minimal. It does not mention any side effects, idempotency, rate limits, or authentication requirements, leaving significant gaps for an unannotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence for purpose plus standard Args/Returns structure. Every sentence is earned and no fluff exists.
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 is simple with one parameter and an implied output schema, the description covers the basics. However, in a context with 40+ sibling tools, it lacks guidance on how this tool relates to similar ones like 'get_instance,' reducing 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?
The schema has 0% coverage (no description for the parameter), but the description's Args section explicitly documents 'instance_name: Name of the instance to retrieve,' adding meaning beyond the schema type. While helpful, it is still minimal and does not provide format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get detailed information for a specific instance by name,' which clearly identifies the action and resource. It is specific enough to distinguish from sibling tools like 'get_instance' (likely by ID) and 'search_instances' (possibly broader search), though it does not explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'search_instances' or 'get_instance'. No prerequisites, use cases, or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description should disclose behavioral traits. It only states it returns a JSON string, but does not indicate if the operation is read-only, requires authentication, or has any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences and no wasted words. It is front-loaded with the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and an existing output schema, the description is minimal but could be more helpful by clarifying the scope relative to the sibling tools and the meaning of availability zones in this 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?
The tool has no parameters, so the schema coverage is 100%. The description adds no additional meaning beyond what the schema already provides, but given the lack of parameters, it is minimally sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'load balancer availability zones', making the purpose apparent. However, it does not differentiate from the sibling tool 'get_availability_zones', which may cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as get_availability_zones. There is no mention of prerequisites or context for use.
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 explains the return value (list of instances) but does not mention pagination, error handling, or performance characteristics. For a simple filter, this is acceptable but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with only three sentences, yet it includes clear 'Args' and 'Returns' sections. Every word is purposeful, and the structure is well-organized, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required parameter, no nested objects) and the presence of an output schema, the description covers the basic purpose. However, it lacks contextual cues about when to prefer this tool over similar ones, limiting completeness for an agent unfamiliar with the domain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must add meaning. It lists example status values (ACTIVE, SHUTOFF, etc.) but does not specify if the list is exhaustive or provide format details. This adds some value but is insufficient for full parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves instances filtered by status, with a specific verb and resource. It distinguishes from siblings like get_instance (single instance) but does not explicitly differentiate from search_instances, which may offer more flexible filtering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of when not to use it or comparison with similar tools like search_instances, leaving the agent to infer optimal usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It only states that the tool returns a JSON string, omitting any side effects, authentication needs, or rate limits. As a read operation, it lacks necessary behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using a single sentence and a line about the return type. It is front-loaded and contains no unnecessary words, earning its place efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description is nearly complete for its simplicity. However, it could briefly explain what load balancer providers are to improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description does not need to add parameter meaning, but it correctly implies no input is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets load balancer providers, with a specific verb and resource. It distinguishes it from sibling tools which target other resources. However, it does not clarify what 'providers' means 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 or context where this tool is appropriate, leaving the agent without decision 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?
No annotations provided and the description only states it returns a JSON string. It lacks disclosure of behavioral traits such as read-only nature, authentication needs, or performance characteristics. The word 'Get' implies read-only, but no explicit details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, front-loading the purpose. It could be slightly more structured but is not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and presence of an output schema, the description is mostly adequate. However, it does not explain what 'flavors' are or how the result relates to other load balancer operations, which could help overall context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and 100% schema coverage, the description adds minimal value but does not need to. Baseline for 0 parameters is 4; the description confirms there are no inputs, which is consistent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Get load balancer flavors', clearly identifying the verb and resource. It distinguishes from sibling tools like get_load_balancer_amphorae or get_load_balancer_availability_zones.
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 specify context, prerequisites, or exclude cases, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral transparency burden. The description adequately implies a read-only operation via the 'get' verb and lists what information is returned, but does not explicitly state that it is safe or describe any 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description includes some redundancy, with bullet points that essentially repeat the main function. It is structured but could be more concise.
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 tool is simple with no parameters and has an output schema (indicated). The description mentions the return format and covers the necessary context for a straightforward list retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so coverage is 100%. The description does not need to add parameter semantics. According to guidelines, zero-parameter tools have a baseline score of 4.
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 that the tool returns a list of floating IPs with associations. However, it does not explicitly differentiate from sibling tools like get_floating_ip_pools, which is a closely related tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage context ('when user requests floating IP information, external connectivity queries, or IP management tasks'), but lacks exclusions or mention of alternative tools for specific scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description only implies a read operation via 'Get' and mentions a JSON return. It lacks explicit disclosure of behavioral traits like read-only nature, performance characteristics, or prerequisites.
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 relatively concise and structured with separate sections for args and returns, though the 'Args' and 'Returns' labels are somewhat redundant when the parameter is already in the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the return type but lacks specifics about what 'details and statistics' are included. It is adequate for a simple tool but could provide more depth.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description compensates by explaining the parameter's meaning: it accepts a specific name/ID or 'all' for all hypervisors, adding value beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'detailed information about hypervisors', distinguishing it from sibling tools that target other resources.
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 explains the parameter usage (specific name or 'all'), but provides no guidance on when to use this tool over alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It describes the return format (JSON string with rule types, values, conditions) but does not disclose whether the operation is read-only, requires special permissions, or has any side effects. It adds moderate context but lacks full behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two short paragraphs (overview and Args/Returns). Every sentence serves a purpose, and the structure is clear. However, it could be slightly more compact by integrating the Args/Returns into prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single required param, no nested objects, existing output schema), the description covers the essential points: what it does, what the parameter means, and what it returns. Minor gaps include no discussion of error cases or empty results, but overall it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only restates that 'policy_name_or_id' is required without providing format hints, examples, or constraints beyond the schema's bare string type. This adds minimal value over the schema itself.
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 L7 rules for a specific L7 policy,' specifying the verb (Get), resource (L7 rules), and constraint (specific policy). This distinguishes it from sibling tools like get_load_balancer_l7_policies which retrieves policies, not rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need L7 rules for a known policy, but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. While it mentions 'specific L7 policy', it doesn't clarify that the policy must be obtained via another tool (e.g., get_load_balancer_l7_policies) first.
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 only states it returns a JSON string without mentioning safety (e.g., read-only), authentication needs, or error handling. The description does not go beyond basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using two sentences plus structured Args/Returns sections. Every word is functional with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and an output schema. The description adequately covers the behavior and return format. It is nearly complete, though missing potential edge cases (e.g., invalid project ID).
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 explains the 'project_id' parameter's behavior (optional, defaults to all projects if empty), adding meaning beyond the schema's type and default. With 0% schema description coverage, this compensates well, though only one parameter is present.
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 load balancer quotas with a specific verb 'Get' and resource 'load balancer quotas', including scoping to a project or all projects. This distinguishes it from siblings like 'get_quota' which may cover different quota types.
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 is provided on when to use this tool versus alternatives. Given the presence of a sibling 'get_quota', the description lacks differentiation or context for when each is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a read operation ('Get') but does not disclose any behavioral details such as data recency, pagination, or side effects. With no annotations, more transparency 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args and Returns sections, concise sentences, and no extraneous information. It is slightly verbose for a tool definition but clear.
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?
While an output schema exists, the description only states 'JSON string with server events information', lacking detail on event structure. Given the tool's simplicity, this is acceptable but not 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?
Despite 0% schema description coverage, the description adds meaning to both parameters: instance_name as 'Name or ID', limit as 'Maximum number of events' with default noted.
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 recent events for a specific server, distinguishing it from sibling tools that focus on other resources like instances, volumes, or load balancers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like get_instance or get_instance_details. It does not specify 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses pagination support, configurable limits, and warns about include_all in large environments. No annotations provided, so this is helpful. It does not explicitly state it is read-only, but that's implied.
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 but includes a bullet list of functions that is somewhat redundant; the core information could be conveyed in fewer words. Still, it is not overly long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 params, many siblings, output schema exists), the description covers purpose, usage, parameters, and return type. It is missing explicit guidance on when to choose this over similar 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?
All 6 parameters are explained in the Args section with descriptions that add meaning beyond the schema. For example, explaining comma-separated lists and the behavior of all_instances and include_all.
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 provides detailed information for OpenStack instances with specific aspects listed (name, ID, status, etc.), making the purpose clear. However, it does not explicitly differentiate from siblings like get_instance or search_instances, which also provide instance details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a use case statement ('Use when user requests specific instance information...'), but does not provide guidance on when not to use it or mention alternatives among the many sibling tools.
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 burden of behavioral disclosure. It explains that the parameter is optional and defaults to the current project, and that the return is a JSON string. However, it does not mention potential errors (e.g., if the project does not exist), required permissions, or whether the operation is read-only (implied but not stated). The transparency is adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear structure including an Args section and a Returns section. The purpose is stated in the first sentence, making it easy to scan. There is no redundant information, and every sentence contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one optional parameter, no nested objects), the description is fairly complete. It covers the parameter, return type, and provides an analogy. However, it could mention error handling or the specific quota categories (compute, storage, etc.), but the output schema presumably covers return details. Overall, it is nearly complete for a simple information retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter (project_name) with 0% schema description coverage. The description compensates by stating the parameter is optional, defaults to the current project, and is the name of the project. This adds semantic value beyond the schema definition, clarifying the default behavior and usage.
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 retrieves quota information for projects, using the verb 'get' with the specific resource 'quota information for projects'. It also provides an analogy to 'openstack quota show', which helps understanding. Although there is a sibling 'get_load_balancer_quotas', the description uniquely identifies this tool for project-level quotas, effectively distinguishing it.
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 provide explicit guidance on when to use this tool versus alternatives like get_load_balancer_quotas or get_usage_statistics. It mentions similarity to openstack quota show but does not explain scenarios where this tool is preferred or when to avoid it. No 'when-not-to-use' or alternative tool mentions are included.
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 does not disclose read-only behavior, authentication needs, error conditions (e.g., server not found), or response structure beyond 'JSON string'. Minimal behavioral context beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: two lines of descriptive text plus standardized Args/Returns sections. Every sentence adds value, no redundancy. The structure is clear and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists (not shown but indicated), the description does not need to detail return values. The single required parameter is well-explained. However, lacks behavioral details like error handling or rate limits, but for a simple query tool it is largely sufficient.
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 schema has no description for instance_name (0% coverage). The description clarifies that the parameter accepts 'Name or ID of the server instance', adding crucial semantic information. This compensates well for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Get all volumes attached to a specific server', which is a specific verb-resource pair. Distinguishes from sibling tools like get_volume_list (which lists all volumes) and get_instance (which retrieves server details).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The context is implied (e.g., needing volumes for a specific server), but no when-not-to-use or prerequisite information is provided. Sibling tools are not mentioned as alternatives.
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 must cover behavioral traits. It lacks any mention of read-only nature, permissions, side effects, or rate limits. Only states it returns JSON format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with functions, usage, args, and returns sections. Slightly verbose but clear and front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers multiple resource types comprehensively. Output schema exists (though not shown), and description explains return format. Adequate for the tool's complexity.
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?
Description adds meaning to the sole parameter 'network_name' by explaining it can be a specific name or 'all' for all networks, with default 'all'. Schema had 0% coverage, so this compensates well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it provides detailed information for OpenStack networks, subnets, routers, and security groups. Lists specific functions, distinguishing it from sibling tools like get_routers or get_security_groups which focus on individual resources.
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?
Explicitly says when to use (network information, subnet details, etc.) but does not mention when not to use or alternatives like get_routers for router-only queries.
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?
As no annotations are provided, the description carries the burden for behavioral disclosure. It implies a read-only operation ('list') but does not mention pagination, error handling, or side effects. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first concisely states purpose, the second notes the return format. Every sentence is necessary; no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and the presence of an output schema, the description is complete. It provides essential information (list all groups, with details) and does not need to explain return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and 100% schema coverage, the description adds no parameter details beyond the schema. Baseline is 4 for no parameters, and no additional information is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'server groups', specifying scope 'all server groups' with details. This distinguishes it from sibling tools, which target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Among many sibling 'get_*' tools, the description does not provide any 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It states the tool returns a comprehensive list with metadata but does not disclose potential volume, pagination, or performance implications. The read-only nature is implied by 'get' but not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat verbose with bullet points and a separate 'Returns' section that largely duplicates the initial sentence. It could be more concise by merging the first sentence and summary.
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 parameters and no annotations, the description adequately explains what the tool does and its output (metadata, properties, status). It does not mention pagination or rate limits, but for a simple list tool without filters, it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is 100% (trivially). The description adds value by confirming no input is needed and explaining the output scope ('all images'). This clarifies the tool's lack of filtering options, which is helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Get detailed list of all images with comprehensive metadata' and lists specific functions (status, size, format). It clearly distinguishes from sibling tools which target other resources like volumes, instances, or load balancers.
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 context: 'Use when user requests image listing, image information, or image metadata details.' This clearly indicates when to invoke this tool, though it does not mention when not to use it or suggest 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?
No annotations provided; the description indicates it is a read operation returning JSON, but lacks details on error conditions, authentication, or performance impacts, leaving gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise but includes structured sections (Args, Returns) which slightly lengthen it; however, every part is informative and not wasteful.
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 one parameter and no annotations, the description adequately covers purpose and return format. It could mention potential pagination or limits, but overall sufficient for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'lb_name_or_id' is well-described: optional, can be name or ID, and default behavior when empty. This adds significant value beyond the bare schema type 'string'.
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 retrieves amphora instances for a specific load balancer or all amphorae if no ID provided, distinguishing it from sibling tools like get_load_balancer_details or get_load_balancer_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 description explains the optional parameter and its default behavior, but does not provide guidance on when to use this tool over alternatives among the many sibling load balancer tools.
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 describes read-only operations like listing and showing capacity, but does not explicitly state that the tool is non-destructive or has no side effects. It is clear enough but lacks explicit safety disclosure.
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 header, bullet points for functions, example queries, and return type. It is front-loaded with the main purpose. Slightly verbose with 'Functions:' and 'Use when user requests:' but still efficient.
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 zero parameters and an existing output schema, the description provides sufficient context on what the tool does and what information it returns. It covers pool capacity and utilization, which is relevant for floating IP allocation.
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?
Input schema has no parameters, so the baseline is 4. The description adds value by explaining what the output contains (capacity information) and the purpose of the returned data.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets a list of floating IP pools, with specific verb 'Get' and resource 'floating IP pools'. It distinguishes from siblings like get_floating_ips by focusing on pools and capacity.
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 example user queries indicating when to use the tool, such as 'Show floating IP pools' and 'Check floating IP capacity'. However, it does not explicitly mention when not to use or alternatives 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?
With no annotations, the description carries full burden. It indicates a read-only operation and mentions return format (JSON) and functions (query status, timestamps, etc.), but lacks details on permissions, rate limits, or pagination 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?
Description is front-loaded with key purpose and includes a bullet list of functions, but has some redundancy (e.g., 'Get list' in title and description). Could be slightly more concise.
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 zero parameters and an output schema present, the description sufficiently explains what the tool does and returns. However, it does not mention if results are paginated or limited, which would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. Description adds no param info, which is acceptable since there are none. Baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'list of Heat orchestration stacks', with specific functions listed. It distinguishes from sibling tools like get_instance or get_routers by focusing on orchestration stacks.
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?
Explicitly states 'Use when user requests stack information, orchestration queries, or infrastructure-as-code status', providing clear context. However, it does not mention when not to use or suggest alternatives among the many 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 carries full burden. It describes the return content (fingerprints, types, dates, truncated public key) but does not explicitly state that the operation is read-only or any authentication requirements. The name implies a read operation, but transparency is moderate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points and sections (Functions, Use when, Returns). It is concise and front-loaded with the main purpose. Minor redundancy could be trimmed but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and an output schema (implied), the description covers the purpose, usage scenarios, and return content. Missing explicit read-only declaration or auth notes, but it is generally complete for a simple list 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?
No parameters exist, so schema coverage is 100%. The description adds context about the returned fields (fingerprints, types, dates), which adds value beyond the empty 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 states 'Get list of SSH keypairs for the current user' which is a clear verb+resource combination. It further enumerates specific information returned (fingerprints, types, dates, public key). Among sibling tools, this is distinct from other get_* tools (e.g., get_security_groups, get_volume_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 explicitly says 'Use when user requests SSH key management, keypair information, or security key queries.' This provides clear context, though it does not mention when not to use or 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?
No annotations provided, so description carries full burden. Describes what information is returned but does not explicitly state that it is a read-only operation or disclose any side effects, authentication needs, or rate limits. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with a main sentence followed by bullet lists for functions and use cases, plus explicit Args and Returns sections. Front-loaded with purpose, but bullet lists could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 1 parameter with good semantic coverage and a promised output schema, the description adequately explains what the tool does and how to call it. It is complete for the complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but the description adds meaning: 'lb_name_or_id: Load balancer name or ID to query'. This clarifies that the parameter accepts both name and ID, beyond the schema's minimal type definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it retrieves detailed information about a specific OpenStack load balancer, listing specific components like VIP, listeners, pools, members, and health monitors. Distinguishes from sibling tools that focus on individual components.
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 use case examples like 'Show details for load balancer [name/id]' and 'What's the status of load balancer [name]?'. Does not explicitly state when not to use, but the specificity implies alternatives exist for narrower queries.
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 details the output fields (protocols, ports, configurations, timestamps) and states the return type (JSON string). While it does not mention rate limits or error handling, the behavioral traits are adequately disclosed for a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a main sentence, bullet lists for functions and example uses, then Args and Returns sections. It is well-organized and front-loaded. Minor redundancy exists between the initial sentence and the first bullet point, but overall it is concise enough.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one parameter and an output schema exists, the description is sufficiently complete. It covers the tool's purpose, input, and output details. It does not mention behavior for nonexistent load balancers or permission issues, but for a simple get operation this is acceptable.
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 must add meaning. It states that lb_name_or_id accepts 'Load balancer name or ID', which clarifies the parameter's purpose. However, it does not specify how the tool distinguishes between names and IDs or any format requirements, leaving some ambiguity.
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 listeners for a specific OpenStack load balancer' and lists specific functions like listing all listeners and showing protocols. The tool's purpose is distinct from sibling load balancer tools such as get_load_balancer_health_monitors or get_load_balancer_pools.
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 example user requests (e.g., 'Show listeners for load balancer [name/id]') that clarify when to use the tool. However, it does not explicitly state when not to use it or suggest alternative tools for related tasks like retrieving health monitors or pools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It mentions detecting and reporting failures, but lacks details on side effects (e.g., read-only nature), authentication needs, or rate limits. It does state the output format, but could be more transparent about behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points and a clear use-case statement. It is front-loaded with the primary purpose. Slightly verbose with the 'Functions:' list, but every sentence adds value. Appropriate length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and an existing output schema, the description adequately summarizes the return format ('JSON format with service details and health summary'). However, it does not detail the specific fields, which might be needed for call chaining. Still, it is sufficiently complete for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so baseline is 4. The description does not need to add parameter details, but it confirms the tool takes no arguments, matching the schema. No additional semantic value needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool provides status and health check information for each OpenStack service, listing specific functions like checking active status and API responsiveness. It clearly distinguishes from sibling tools (e.g., get_instances_by_status, get_availability_zones) by targeting OpenStack services specifically.
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 use cases: 'Use when user requests service status, API status, health checks, or service troubleshooting.' This helps the agent decide when to invoke, though it does not explicitly mention when not to use or name alternative tools.
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 that the tool performs searching, supports partial matching and case sensitivity, and returns detailed information with pagination. It does not mention any destructive behavior, rate limits, or ordering, but overall provides good transparency for a search 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 clear header, bulleted functions, args, and returns, but it is somewhat verbose. It could be more concise by removing the bullet list of functions and integrating them into a single sentence. The structure is readable but not maximally efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core functionality, explains all 5 parameters, and mentions output (list with pagination metadata). There is an output schema (not shown), so the description need not detail return fields. However, it lacks information on error conditions, authentication requirements, or behavior when no results are found. Overall, it is largely complete for a search tool.
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 has 0% description coverage, meaning the properties have no descriptions. The tool's description provides an 'Args' section that explains each parameter, including defaults and allowed values (e.g., search_in defaults to 'name', case_sensitive defaults to false). This fully compensates for the lack of schema descriptions, adding significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches for OpenStack instances based on various criteria, listing specific fields (name, status, host, flavor, image, availability zone). It clearly distinguishes from sibling tools, which are mostly get_* tools for specific resources, by offering a search with partial matching and pagination.
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 searching instances by criteria, mentions 'efficient pagination' and 'optimized for large-scale environments', but does not explicitly state when to use this tool vs alternatives like get_instances_by_status or get_instance_by_name. It lacks explicit 'when not to use' or comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the returned information (source volume, dates, size) and implies a read-only operation by listing functions. It does not disclose potential limits or performance, but it is transparent enough for a get operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is clear and front-loaded with the main purpose, followed by bullet points and use cases. It could be slightly more concise, but it effectively communicates the tool's capabilities without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no parameters and an output schema exists. The description explains the return value (JSON with detailed info) and covers key aspects. For a simple list tool, this is complete and provides sufficient 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?
There are no parameters, and the schema coverage is 100%. The description does not add parameter semantics because none are needed. Baseline score of 3 is appropriate.
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 list of volume snapshots' and lists specific functions (query, display source volume info, show dates, provide size/usage). This distinguishes it from siblings like get_volume_list (volumes) and get_image_detail_list (images).
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 use cases: 'when user requests snapshot information, backup queries, or volume restoration planning.' It does not mention when not to use or alternatives, but the context is sufficient for a simple list tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description covers behavioral aspects well: it mentions the tool lists monitors, shows types and settings, returns a JSON string, and can be filtered by pool. This is sufficient for a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary, bullet points, usage examples, and argument/return details. It is slightly verbose but each sentence adds value, making it effective without being overly long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's core functionality, parameter, and return format. Given the simple input schema and presence of an output schema, it is adequately complete. It could mention error cases or pagination, but these are not critical for a basic list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the tool description adds meaning: 'Optional pool name or ID to filter monitors (empty for all)'. This clarifies the parameter's purpose beyond the schema's type-only definition.
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 health monitors, optionally filtered by pool' and lists specific functions. It distinguishes from sibling 'get_load_balancer_*' tools by focusing on health monitors, making the tool's 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 usage examples like 'Show all health monitors' and 'List health monitors for pool [name/id]', giving clear context. However, it does not mention when not to use this tool or point to alternatives 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?
The description discloses the return format (JSON string with policy details, actions, rules), but with no annotations provided, it fails to mention permissions, read-only nature, or error handling. The description adds some value but leaves 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 concise, with the main purpose stated first, followed by a structured Args and Returns section. No unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple structure (one optional parameter, no nested objects) and presence of an output schema, the description covers purpose, parameter, and return value adequately. It could mention error cases or permissions but is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully explains the parameter's purpose, optionality, and default behavior (shows all policies if empty). This adds significant meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves L7 policies, optionally filtered by listener, using a specific verb 'Get' and resource 'L7 policies'. It distinguishes from siblings like get_load_balancer_l7_rules and get_load_balancer_listeners.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the optional listener filter and the effect of omitting it, providing clear context. However, it does not explicitly state when not to use this tool or mention alternatives, so it is not a 5.
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 burden. It states returns JSON with cluster summary and hypervisor details, implying a read operation. However, lacks details on performance, caching, or authorization requirements, which would be helpful for a monitoring tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear headline, bulleted functions, usage guidance, and return description. No redundant information; every section serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and a described output schema, the description provides complete context: what it monitors, when to use, and what the response contains. No gaps identified.
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?
Input schema has zero parameters, so schema coverage is 100%. Description adds value by explaining the output format and included functions, beyond what the empty schema provides.
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 monitors real-time resource usage across the OpenStack cluster, listing specific functions like CPU, memory, and storage monitoring. This distinguishes it from sibling tools that focus on other resources.
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?
Explicitly says 'Use when user requests resource monitoring, capacity planning, usage analysis, or performance monitoring.' While it doesn't mention when not to use, the guidance is clear and covers common scenarios.
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 that it returns a JSON list of role assignments with scope information and implies read-only behavior. No annotations exist, so the description carries full burden; it covers the main behavior but doesn't detail authentication or implicit project context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with bullet points for functions and a separate returns section, but slightly verbose. Could be tightened 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 the presence of an output schema, the description adequately covers the return format and use cases. It lacks details on error handling or permissions, but for a straightforward get operation, it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the schema already covers all inputs. The description adds context by specifying the project is 'current' (implied from authentication), which clarifies the implicit parameter.
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 role assignments for the current project, covering specific aspects like project-level and domain-level permissions and scope. It distinguishes itself from sibling tools by focusing on access control, not general resource 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?
Explicitly states when to use: for permission information, access control queries, or security auditing. However, it does not mention when not to use or alternative tools, leaving some ambiguity.
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 transparently describes the output includes servers, RAM, CPU, and disk hours, as well as a summary. It also notes the optional date range parameters. No contradictions or hidden behaviors are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points and clear sections, but slightly lengthy at about 10 sentences. Every sentence adds value, so it earns its place, though it could be slightly 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 the presence of an output schema (context signal: 'Has output schema: true'), the description does not need to detail return values extensively, but it does mention JSON format and summary. It sufficiently covers input parameters and use cases, though a brief note on pagination or limits would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions, so the description adds essential meaning by explaining that start_date defaults to 30 days ago and end_date defaults to today, both in YYYY-MM-DD format. This adds value beyond the schema's type-only 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 clearly states the tool retrieves usage statistics for projects, analogous to the OpenStack command. It lists specific functions and use cases, distinguishing it from sibling tools that focus on other resources like availability zones or floating IPs.
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 specifies when to use the tool, such as for billing, resource consumption analysis, or project usage reports. While it does not explicitly state when not to use it or name alternatives, the context of sibling tools makes the usage context 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 burden. It explains that the tool returns a detailed list in JSON with volume information, attachments, and metadata. This is transparent for a read operation, though it does not disclose potential limitations like pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points and a 'Returns' section, making it easy to parse. However, it is slightly verbose; part of it lists functions that are already implied by the main statement.
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 parameters, no annotations, and an existing output schema, the description adequately covers the tool's purpose and output. It could be more explicit about scope (e.g., project-level listing) but is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the description adds value by explaining what information the listing includes. Baseline for 0 params is 4.
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 list of all volumes with detailed information' and explicitly lists the types of information returned (status, size, type, attachments, metadata). It differentiates from siblings like get_volume_snapshots and get_volume_types by focusing solely on volumes.
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 'Use when user requests volume listing, volume information, or storage overview.' This provides clear use cases, though it does not explicitly mention when not to use or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries behavioral disclosure. It details that the tool lists pools, shows protocols, algorithms, members with status, and health monitor associations, and returns JSON. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with a summary line, bullet list of functions, usage examples, args, and returns. It is concise without unnecessary repetition, though slightly verbose in listing functions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool with 1 optional parameter and an output schema existing, the description covers purpose, behavior, parameter meaning, and return format comprehensively. No 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 has 0% description coverage, but description adds meaning: 'Optional listener name or ID to filter pools'. However, it lacks format details or examples that would further clarify usage, so baseline 3 is appropriate.
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 it gets load balancer pools, optionally filtered by listener. It explicitly lists functions like listing pools, showing protocols, members, and health monitors, distinguishing it from sibling tools such as get_load_balancer_list or get_load_balancer_pool_members.
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 provides explicit usage examples like 'Show all load balancer pools' and 'List pools for listener [name/id]', guiding when to use. However, it does not mention alternatives or when not to use this tool despite ample sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It accurately describes the operation as a read-only list operation returning configuration details. Since there are no side effects or destructive actions, the description sufficiently conveys 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 somewhat redundant. The first sentence already conveys the purpose, but the 'Functions' bullet list essentially repeats it with more words. A more concise version could combine the core idea without the bullet list.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and the presence of an output schema, the description adequately explains that the return is a JSON list of routers with detailed configuration. It is complete enough for an agent to understand the tool's output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the baseline score is 4. The description adds no parameter-level detail, but none is needed. The schema covers 100% of parameters (none), so the description does not need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a list of routers with their configuration. It uses specific verb+resource ('Get routers'), and the 'Functions' bullet list reinforces the scope. This distinguishes it from sibling tools that target other resources like instances or networks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use when user requests router information, network connectivity queries, or routing configuration.' This provides clear context for when to employ the tool, though it does not explicitly state when not to use it or contrast with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details what data is returned: member addresses, ports, weights, health status, admin state, operational status, and monitor configuration, and states it returns a JSON string. Without annotations, this provides adequate behavioral context, though it does not mention read-only nature or potential errors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear headings (Functions, Use when user requests, Args, Returns) and uses bullet points for readability. It is concise, containing only relevant information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema (not shown), so the description's high-level summary of return values is sufficient. It mentions key fields like addresses, ports, and health status, covering expected outputs. A minor gap is the lack of explicit mention of pagination or limits, but not critical given the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only names 'pool_name_or_id' without description. The description compensates by explaining it as 'Pool name or ID to query members for' and listing example queries that illustrate usage. This adds essential meaning, especially given 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get members for a specific OpenStack load balancer pool' and lists specific functions like listing members and showing addresses, ports, weights, and health status. It also provides example user requests, making the purpose unambiguous and distinct from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit use cases with four example queries (e.g., 'Show members for pool [name/id]'), providing clear context for when to invoke the tool. However, it does not explicitly exclude usage or suggest alternatives, such as when to use a different load balancer tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must convey behavioral traits. It specifies that it is a read operation, returns a JSON string with details/roles/quotas, and notes the 'list all' behavior for empty parameter. This sufficiently covers the expected behavior for a simple read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with clear sections for purpose, parameters, and return value. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no nested objects, output schema present), the description adequately covers input, output, and behavior. Minor gap: no mention of error handling for nonexistent project, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It fully explains the only parameter 'project_name', including its purpose, optionality, and effect (lists all if empty). This adds all necessary 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 clearly states it retrieves OpenStack project details, with a CLI equivalent ('openstack project list/show') for reference. It distinguishes from sibling tools (none other target projects) and notes the optional filtering behavior.
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 indicates when to use (to get project details) and explains the optional parameter behavior (empty lists all). However, it lacks explicit guidance on when not to use or alternatives, but the sibling tool list does not contain a direct substitute.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors: it queries user accounts, shows enabled/disabled status, email, domain, and creation/modification timestamps. It states the return format as JSON. Without annotations, it adequately covers behavior, though it omits potential error conditions or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear main sentence, a bullet list summarizing functions, a usage note, and a return statement. Every sentence adds value, and the structure front-loads the essential purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless list tool with an output schema, the description covers the purpose, scope ('current domain'), returned fields, and usage context. It is complete without extraneous information.
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?
There are 0 parameters, so baseline is 4. The description does not need to explain parameters and does not add misleading information.
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 a list of OpenStack users in the current domain, specifying included details like status, email, and timestamps. This distinguishes it from sibling tools which focus on other resources (e.g., floating IPs, instances).
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 context: 'Use when user requests user management information, identity queries, or user administration tasks.' It lacks explicit when-not-to-use or alternatives, but given no direct sibling for user listing, this is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the transparency burden. It clearly indicates a read-only retrieval of volume types with specifications, including extra specs, backend config, and public/private settings. No side effects or contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-structured with a purpose statement, bullet-point functions, usage guidance, and return info. Every sentence is relevant and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter list tool, the description covers all needed context: what it returns (volume types with detailed specs), and hints at fields like extra specifications and backend configurations. The existence of an output schema further fills details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so baseline is 4. The description adds value by detailing the output content (specifications, backend info, settings) beyond the empty 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 explicitly states 'Get list of volume types with their specifications' and lists specific functions, clearly distinguishing it from siblings like get_volume_list and get_volume_snapshots.
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 gives explicit usage contexts: 'Use when user requests volume type information, storage backend queries, or volume creation planning.' It doesn't mention when not to use, but given no direct sibling for volume types, this is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Describes pagination (limit/offset), include_all option, and what information is displayed (VIP, status, listeners, provisioning status). Does not mention authentication or side effects, but as a read-only list, this is sufficient.
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?
Well-organized with clear sections: functions, use cases, args, returns. Every sentence adds value; no fluff. Front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Has output schema, so detailed return structure is covered elsewhere. Description notes returns 'JSON string containing load balancer details with summary statistics', which suffices. Complete for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (only defaults and types). Description's 'Args' section explains each parameter: limit (1-200, default 50), offset (default 0), include_all (default False). Adds context missing from 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?
Description specifies 'Retrieve comprehensive list of OpenStack load balancers with detailed information' and lists functions like listing all LBs, showing VIP/status/listeners. This clearly distinguishes it from sibling tools like get_load_balancer_details (single LB) or get_load_balancer_listeners (listeners only).
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 use cases with example user requests ('Show me all load balancers'). Lacks explicit when-not-to-use or alternatives, but the context is clear enough for an AI to decide.
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, so description fully covers behavior. It explains it's read-only (list), details what is returned (ingress/egress rules, protocols, ports), but does not mention any potential permissions 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?
Well-structured with a clear purpose, bullet points for functions, and usage guidance. Slightly verbose but overall effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and presence of output schema, the description is complete: it explains what the tool does, when to use it, and the content of the response.
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?
No parameters exist (schema coverage 100%). Baseline for 0 params is 4; description adds no further meaning but none is needed.
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 a list of security groups with their rules, distinguishing it from sibling tools like get_instance or get_volume_list which deal with 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'when user requests security group information, firewall rules, or network security queries.' No conflicting alternatives exist among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: supports pagination (limit, offset), case-sensitive search, all_instances flag, detailed mode, and returns JSON with metadata. No contradictions; it's a read-only tool, and all filtering modes are explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections: summary, functions, usage, args, returns, examples. Front-loaded with purpose. Slightly verbose but justified by the number of parameters and complex behavior. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 0 required parameters, 10 params, no annotations, and an existing output schema, the description covers all necessary aspects: param usage, return format, pagination, and examples. No gaps observed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but the description provides detailed 'Args' section with explanations, defaults, and examples for all 10 parameters. Adds significant meaning beyond the schema's property types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it's a unified tool for all instance retrieval patterns, listing specific functions like get by names/IDs, filter by status, search, and list all. Distinguishes itself from sibling tools by consolidating get_instance_details, get_instance_by_name, get_instances_by_status, and search_instances.
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?
Explicitly says to use when user requests instance information, status checks, or searches, but does not provide when-not-to-use or alternative tools beyond the consolidation statement. Sibling list is available externally, but the description itself lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

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/call518/MCP-OpenStack-Ops'

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