ibmcloud-mcp-server
Server Quality Checklist
Latest release: v1.0.1
- Disambiguation5/5
Each tool follows a clear resource-action pattern with domain prefixes (cf, ks, cr, iam, resource, billing, catalog), making every tool's purpose distinct. Even similar operations like listing service instances in CF vs resource service instances are clearly separated by their prefixes and descriptions.
Naming Consistency5/5All tool names use the consistent ibmcloud_<domain>_<verb>_<noun> pattern, with plural nouns for list operations and singular for get/create/update/delete. Standalone commands like ibmcloud_login and ibmcloud_target fit the overall CLI convention without breaking the pattern.
Tool Count2/5At 88 tools, the server is far beyond a typical MCP size, even for a comprehensive cloud platform. While each tool is independently useful, the sheer number makes selection and discovery unwieldy, and the score guideline suggests 25+ is already too many.
Completeness4/5The tool set covers most major IBM Cloud domains with reasonable CRUD coverage, but some lifecycle gaps exist. For example, access groups and their policies have create/list/get operations but no delete or update, and CF apps lack an explicit update op (though push serves that role). Overall, the core workflows are covered.
Average 3.2/5 across 88 of 88 tools scored. Lowest: 2.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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.jsonto 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 also fails to disclose side effects, permission requirements, or post-creation behavior. The only implied behavior is creation, which is already evident from the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but under-specified rather than concise. It is a tautological phrase with no structure or substance beyond restating the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with 6 parameters and no annotations, the description is inadequate. It lacks essential context like required setup, resource group selection, location defaults, and what happens when a service instance is created.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 6 parameters. The description adds no parameter information, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a service instance' is a direct restatement of the tool name and adds no new information. It does not distinguish from sibling tools like ibmcloud_resource_service_instance_update or ibmcloud_cf_create_service, beyond the verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, no prerequisites (e.g., login/target state, resource group requirement), and no context about when resource service instances are appropriate vs Cloud Foundry services.
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?
There are no annotations, so the description carries the full burden of behavioral disclosure. 'List' implies a read-only operation, but it does not mention authentication requirements, return format, pagination, or whether it lists all tags or only those with a specific resource filter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely sparse at two words, which is under-specification rather than effective conciseness. While there is no fluff, the description does not earn its place as a standalone explanation for the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and no output schema or annotations, the description still lacks essential context: what tags are listed (resource tags vs. other types), whether the output is a simple array or includes metadata, and any prerequisites. This is below the minimum needed for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description for the single parameter resource_id is explicit ('Filter by resource CRN'), and schema coverage is 100%. The description 'List tags' adds no parameter semantics beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List tags' provides a clear verb and resource but is minimal. It does not specify the scope (e.g., all tags in account vs. for a resource) or distinguish from potential related operations, though sibling tool names like ibmcloud_resource_tag_attach help clarify the domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. There is no mention of the optional resource_id parameter context or exclusions, leaving the agent to infer usage from the tool name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Search for resources,' implying a read operation but not explaining what is returned, whether authentication is needed, or how results are formatted. This is a minimal attempt at transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one short sentence) and front-loaded, but it is essentially a restatement of the tool name. It contains no extra information that earns its place, bordering on tautology. It is not a waste of words, but it is under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no annotations, no output schema), the description still fails to convey what the search covers (e.g., all resource types, current account, cross-region) or what the response looks like. The agent is left without enough context to confidently invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single 'query' parameter (with 'Search query (Lucene syntax)'). The description adds no additional parameter context, so the schema does the heavy lifting. Baseline 3 is appropriate since the description does not compensate with examples or synthax details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Search') and resource ('resources'), but it is extremely generic and does not specify what types of resources are searched or how this differs from sibling tools like catalog_search or resource_groups. It conveys only the basic action without meaningful scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention whether it is the preferred choice for cross-resource searches, nor does it exclude specific scenarios. The agent receives no help in deciding between this and sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It simply says 'Delete a service ID' without explaining consequences, irreversibility, required permissions, or the effect of the 'force' parameter. This is essentially a restatement of the tool's name and offers no additional transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no wasted words, which is structurally concise. However, it is under-specified to the point of offering minimal useful information beyond the tool name. It is adequately sized for a simple delete operation but lacks substantive content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a destructive operation with no annotations and no output schema, the description should provide more context about irreversible effects, force option behavior, or resource associations. The schema covers parameters but not the operational context, leaving the description incomplete for safe and correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% as the input schema describes both parameters ('name' and 'force') with clear descriptions. The tool description adds no extra semantic value, but the baseline for high schema coverage is 3. The description does not conflict with or replace schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a service ID' clearly states the action (delete) and the target resource (service ID). It is distinct from other delete tools in the sibling list by specifying the resource type. While minimal, it is not a tautology and adequately communicates the tool's core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as ibmcloud_iam_api_key_delete or ibmcloud_resource_service_instance_delete. It does not mention prerequisites, typical scenarios, or exclusions, leaving the agent without contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It fails to mention that deletion is destructive, irreversible, or that the 'force' parameter affects confirmation. This is a significant transparency gap for a delete 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that is immediately clear and not verbose. It is front-loaded with the verb and resource, though it sacrifices necessary detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but as a destructive operation with no annotations and no output schema, the description should explain consequences, permissions, or the effect of 'force'. The current description is too sparse to be considered complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters, documenting 'name' as the service key name and 'force' as forcing deletion without confirmation. The description adds no additional semantic value beyond the schema, so the baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the resource ('service key'), making the tool's purpose evident. However, it does not explicitly distinguish itself from sibling tools like create or get, relying on the verb for differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, what prerequisites exist, or how it compares to alternatives. The description is a bare command without contextual usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavioral traits. It only states the action 'Create', which implies a mutation, but provides no information on side effects, required permissions, irreversibility, or response behavior. This is insufficient for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, making it concise. However, it offers no substantive information beyond the tool's name, bordering on a tautology. It is appropriately short but lacks the enriching details that would earn a higher score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (2 parameters, no output schema, no annotations), the description is too sparse. It does not clarify the role of 'resource_group', whether it must exist, or any default behavior. For a create operation, it should at least hint at what happens when resource_group is omitted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'name' and 'resource_group' having descriptions in the schema. The tool description adds no additional parameter context, so the baseline of 3 applies per the scoring guidelines.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Create' and the resource 'Container Registry namespace', making the tool's purpose unambiguous. It also distinguishes from the sibling tool 'ibmcloud_cr_namespaces' which presumably lists namespaces, as this tool performs a creation operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 vs alternatives. It does not mention prerequisites (e.g., login), default behavior for omitted resource_group, or cases where creation might fail (e.g., duplicate namespace). No exclusions or alternative tools are referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. It fails to mention that deletion is destructive, irreversible, or potentially cascading, and it does not warn about the need for confirmation or force flag implications. This is a significant gap for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and front-loaded, avoiding verbosity. However, it is under-specified, lacking any additional context or structure that could aid an agent. It is not overly long but also not helpfully concise; it simply states the obvious.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive delete operation with no annotations and no output schema, the description should provide more context about consequences, reversibility, or caveats. The schema covers parameter syntax, but the description fails to make the tool safe and complete for an agent to invoke properly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents both parameters (cluster name/ID and force). The description adds no extra semantic value beyond what the schema provides, but it does not need to since the schema is sufficient. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Delete') and a clear resource ('Kubernetes cluster'), distinguishing it from sibling tools like create, config, or list. It unambiguously states the tool's core function with minimal ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 or when to prefer an alternative. There is no mention of prerequisites, exclusions, or comparisons to other cluster-related commands. The description simply states the action without any usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'update', which implies mutation, but does not disclose whether the update is additive, destructive, idempotent, or what happens to unspecified fields. No context about permissions or side effects is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence and is very concise, but it is under-specified for a 4-parameter mutation tool. It lacks structure or front-loaded context that would make it genuinely helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description should explain more about return values, effects, and constraints. It does not mention whether the operation is synchronous, what happens on failure, or how the 'parameters' field behaves. It is minimally sufficient but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter has a basic description. The tool description itself adds no parameter meaning beyond the schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update a service instance' uses a specific verb ('update') and resource ('service instance'), clearly distinguishing it from create/delete siblings. However, it lacks detail about what aspects can be updated, though the schema partially compensates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like create or delete. There is no mention of prerequisites, typical use cases, or when to avoid it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description is the sole source of behavioral transparency. The verb 'List' implies a read-only operation, but the description does not disclose pagination, output format, authentication requirements, or how the optional 'instance' parameter affects results. This is minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that is easy to parse, but it is somewhat under-specified. It avoids unnecessary verbosity, but it could include a brief note about optional filtering without becoming too long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description must carry the burden of context. It fails to explain the relationship to service instances, whether listing is global or scoped, or what output the agent can expect. The sibling tools indicate a singular resource getter, but the description does not clarify the distinction.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the single parameter 'instance' with the description 'Service instance name', so the schema already provides 100% coverage. The tool description adds no additional meaning beyond the schema, such as clarifying that the instance filter is optional or that omitting it lists all keys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with a clear resource 'service keys/credentials', which states the core action. However, it does not explicitly distinguish this from the sibling tool 'ibmcloud_resource_service_key' (singular), which likely retrieves a specific key, so the scope (all vs one) is only implied.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as the singular 'ibmcloud_resource_service_key' for retrieving a single key, or the create/delete variants. There is no context about prerequisites or filtering by instance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Get', implying a read operation, but gives no details about required permissions, data aggregation, output format, or any side effects. This is a minimal disclosure 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, terse sentence with zero wasted words. It is efficient and front-loaded with the action, though it sacrifices context for brevity. It is not as polished as a two-sentence description that also provides usage alternatives.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with two well-documented parameters, the description is minimally viable. However, the lack of any mention of output shape, optional month behavior, or relation to other billing usage tools leaves some gaps. It is complete enough for a basic call, but not richly contextual.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters (org and month) with clear descriptions, achieving 100% schema description coverage. The description adds no extra parameter semantics, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get Cloud Foundry org usage' clearly states the action (get) and the resource (Cloud Foundry org usage). It distinguishes itself from sibling billing tools like account, resource group, and resource instance usage by specifying 'Cloud Foundry org', though it doesn't enumerate the specific usage fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 the similar billing siblings (ibmcloud_billing_account_usage, ibmcloud_billing_resource_group_usage, etc.). The description does not mention alternatives, exclusions, or prerequisites, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but 'Get resource group usage' offers no information about required permissions, default behavior for the optional month parameter, or the nature of the returned data. This is insufficient for a tool that likely has nuances around billing data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded and not verbose. However, it essentially restates the tool name and adds no extra information, making it minimally acceptable but not exceptional.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description fails to clarify what 'usage' means (cost, resources, etc.), how it relates to sibling billing tools, or what the response format would be. The existence of multiple billing scopes (account, org, resource instances) makes this lack of context problematic.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%—both 'month' and 'resource_group' have clear descriptions. The description adds no extra meaning beyond the schema, so the baseline of 3 applies as the schema already documents the parameters effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get resource group usage' clearly states the action (get) and the resource (resource group usage), making the primary purpose clear. However, it does not differentiate from sibling billing tools like account, org, or resource instances usage, which all follow the same pattern.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not specify when to use this tool instead of the other billing usage tools, nor does it mention any prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, and the description does not disclose return format, query semantics, read-only status, pagination, or any behavioral details beyond the fact that it searches.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is concise, though it sacrifices depth.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with no output schema, the description should at least indicate the result type or scope. It does not explain what matches look like or how this differs from resource_search, leaving an incomplete context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes the query parameter ('Search query'), and the description adds only the catalog context. With 100% schema coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific action ('search') and a clear resource ('service catalog'), which conveys the core purpose. It is distinct enough from sibling tools like catalog_service and catalog_service_plans, 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this search tool versus alternatives like resource_search or catalog_service, nor is the query syntax described.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits, but it only restates the action without any additional context. It does not mention whether the operation is read-only, requires authentication, or how results are returned, leaving significant gaps for a tool with no annotation safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no wasted words. It is appropriately brief for a simple one-parameter tool, earning a high score on conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal for a tool with no output schema and no annotations. It fails to explain what a 'plan' is, the structure of the return value, or any operational context like authentication or error behavior. This makes it incomplete for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for the single parameter, describing 'service' as 'Service name'. The description adds no further semantic information about the parameter, so it stays at the baseline of 3 for high schema coverage without adding value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('plans for a catalog service'), making it easy to understand the tool's basic function. It is distinct from sibling tools like ibmcloud_catalog_service or ibmcloud_catalog_search, though it does not explicitly differentiate itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as ibmcloud_catalog_service or ibmcloud_catalog_search. It also offers no context about prerequisites, such as requiring a login or target, so an agent receives no decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral disclosure. It implies a read-only operation ('Get') but does not specify what details are returned, whether the app must exist, or potential error conditions. This leaves significant ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no redundant words. It is concise and front-loaded, but could include more useful context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description is insufficient. It does not explain what 'details' includes, how to interpret the response, or any usage context, leaving the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'name' already described as 'Application name'. The tool description adds no additional semantic meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description succinctly states 'Get Cloud Foundry application details', which clearly identifies the action (get) and resource (Cloud Foundry application). The singular 'app' helps distinguish it from the sibling 'ibmcloud_cf_apps', though it doesn't explicitly mention retrieving by name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like ibmcloud_cf_apps or ibmcloud_cf_env. The description only states the action without any context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the full burden of behavioral disclosure. It only states the action without detailing side effects, prerequisites, permissions, reversibility, or impact on the application. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence (8 words) that is front-loaded with the key action. Every word earns its place, and there is no wasted or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but with no annotations, no output schema, and a very sparse description, it lacks completeness. It does not explain prerequisites, when to use it, what a successful binding entails, or how it relates to sibling operations like unbind. The parameter schemas help, but behavioral and contextual information is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all three parameters documented ('Application name', 'JSON binding parameters', 'Service instance name'). The description adds no additional parameter semantics, but the schema already provides adequate meaning, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Bind a service to an application' clearly states the action (bind) and the resources involved (service, application). It is specific and uses a distinct verb/resource combination, but it does not differentiate itself from sibling tools like ibmcloud_cf_unbind_service or ibmcloud_cf_create_service.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention that the app and service must already exist, nor does it reference sibling tools like unbind_service for reverse operations. Usage context is entirely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only repeats the action 'create' without mentioning side effects, billing implications, or provisioning behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that conveys the core purpose without any wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create operation with no annotations and no output schema, the description is too sparse. It omits prerequisites, how to discover valid service/plan names, and how it differs from the resource service instance create tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 100% of the 4 parameters, so the baseline is 3. The description itself adds no parameter details beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create) and resource (Cloud Foundry service instance). It distinguishes from the similar resource_service_instance_create by specifying 'Cloud Foundry', but does not explicitly call out alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 the sibling ibmcloud_resource_service_instance_create, nor any prerequisites such as being logged in or targeting a Cloud Foundry org/space.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It only says 'List marketplace services' without detailing any behavior such as output format, pagination, authentication requirements, or the effect of the optional 'service' parameter (which is only in the schema). This is insufficient for a tool with no annotation safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It fully earns its place and is as concise as possible for a tool of this simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has low complexity but the description is extremely terse. Given that there is no output schema and no annotations, the description should provide more context about what the tool returns or when it is appropriate to use, especially to avoid confusion with sibling tools like cf_services or catalog tools. The current description is insufficient for an agent to fully understand the tool's role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the only parameter 'service' with a clear description ('Show plans for a specific service'), giving 100% coverage. Since the schema already explains the parameter, the description does not need to add much, and the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('marketplace services'), making the primary purpose unambiguous. However, it does not distinguish this tool from the similar sibling tools like ibmcloud_cf_services or ibmcloud_catalog_search, so it misses the chance to differentiate itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention any context, prerequisites, or conditions that would help an agent decide between this and the many related listing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose side effects. It merely says 'Deploy' without noting that this may create or update an app, upload code, require a targeted CF space, or affect running instances.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no redundancy. It's front-loaded and to the point, though it might be too sparse for completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a deployment command with 7 parameters and no annotations, the description is inadequate. It lacks information about deployment behavior, prerequisites, return values, or post-conditions. The rich sibling list hints at a complex environment but the description doesn't orient the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 7 parameters have schema descriptions (100% coverage), so the description doesn't need to repeat them. It adds no additional parameter semantics beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
States the action clearly: 'Deploy a Cloud Foundry application' – a specific verb+resource. Though it doesn't elaborate on deployment specifics, it's distinguishable from sibling tools like listing apps (ibmcloud_cf_apps) or starting an app (ibmcloud_cf_start).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage context, prerequisites, or alternatives are mentioned. The description gives no indication of when to prefer this over other CF commands like ibmcloud_cf_start or ibmcloud_cf_app.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does not mention side effects (e.g., downtime), prerequisites (e.g., app must exist), or that it stops and starts the application. This is a significant gap for a state-changing 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is appropriately concise for a simple tool, though it omits useful context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description provides only the bare minimum. There is no information about return values, prerequisites (e.g., must be logged in and targeted), or operational impact. The tool is simple but still needs more context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter 'name' described as 'Application name'. The description adds no additional meaning beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (restart) and the resource (Cloud Foundry application). It distinguishes from siblings like start/stop by using the verb 'restart', though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like start, stop, or push. The description simply restates the tool's purpose without context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full responsibility. It only states the high-level action without disclosing what scaling does (e.g., updates the app's instances/memory/disk), whether it triggers a restart or rolling update, or any side effects on running applications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that is easy to parse and front-loads the primary action. It is concise, though slightly under-specified, it earns the score for avoiding unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and minimal description, the tool lacks important context such as prerequisites (e.g., CF CLI login and target organization/space), expected outcomes, or any limitations. Even with a well-structured parameter schema, the description alone is too sparse to fully guide an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter (disk, name, memory, instances) is already well-documented. The description adds no extra meaning beyond the schema, which is acceptable but does not elevate the score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Scale') and resource ('Cloud Foundry application'), clearly distinguishing it from sibling tools like cf_push, cf_start, and cf_stop. It doesn't explicitly mention that scaling affects instances/memory/disk, but the schema covers those details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. There are no mentions of preconditions (e.g., being logged in, targeting a CF org/space) or exclusions. The intended use is only implied by the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states 'Unbind a service from an application' without disclosing any side effects, reversibility, permission requirements, or consequences. For a mutation tool, this is insufficient; the agent is left unaware of what changes occur in the service binding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundant words. It is front-loaded with the verb and object. However, it is so brief that it sacrifices useful context, though this is a conciseness preference rather than a structural issue.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with two well-documented parameters and no output schema. The description fully explains the primary action. But it omits any nuance like the fact that unbinding does not delete the service instance, or that the app and service must be in the same space. Such context would help, but overall the information is minimally sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: both app_name and service_instance are described with meaningful labels ('Application name' and 'Service instance name'). The description adds no additional meaning beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Unbind a service from an application.' This is specific and unambiguous, using a strong verb and resource. It is implicitly distinguished from the sibling tool ibmcloud_cf_bind_service by the action, but it does not explicitly name or contrast with alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool, that it is the inverse of bind_service, or any context about required prior steps (e.g., targeting an org/space, the service must already be bound). The description offers only the action itself, leaving usage decisions entirely to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'Get access group details' without disclosing what details are returned, whether special permissions are required, or any side effects. This is insufficient for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single short sentence 'Get access group details' is concise and front-loaded. No wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should explain what 'details' includes to help the agent determine if this tool meets the user's request. It does not, leaving the agent to guess the return structure. Simple tool, but too underspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single 'name' parameter described as 'Access group name'. The description adds no extra meaning beyond the schema, but baseline 3 applies because the schema handles the parameter documentation adequately, even though it is minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Get access group details' which clearly identifies a read operation for a single access group. It distinguishes from siblings like 'ibmcloud_iam_access_groups' (list) and 'ibmcloud_iam_access_group_create' (create), though 'details' is slightly vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention that this is for retrieving a specific access group by name, nor does it reference the list or create siblings. The agent must infer usage from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It does not disclose any behavioral traits such as the key being shown only once, authentication requirements, or side effects of creation. Fails to provide context beyond the action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence. It is front-loaded and wastes no words, though it may be slightly under-specified for the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool lacks an output schema and annotations, and the description provides no information about return values or important prerequisites. For a create operation, more context about the resulting API key or file saving behavior is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all parameters. The tool description adds no additional parameter semantics, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create an API key' clearly states the action and resource. It is specific enough, though it does not explicitly distinguish between user API keys and service API keys among 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 Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like ibmcloud_iam_api_key_delete or ibmcloud_iam_service_api_key_create. The description is purely declarative.
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 convey behavioral traits. It only says 'Delete an API key' without disclosing that deletion is permanent, what the 'force' parameter implies, or any side effects. This is a destructive action with minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with zero wasted words. It is immediately clear and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations and no output schema, this description is inadequate. It fails to mention irreversibility, force semantics, or expected outcomes, leaving significant gaps for a delete operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with the 'name' and 'force' parameters already described in the schema. The description adds no additional parameter meaning. Baseline 3 applies because the schema fully documents parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete an API key' clearly states the action and resource. While it doesn't explicitly distinguish between IAM API keys and service API keys, the tool name including 'iam_api_key' removes ambiguity. It is a specific verb+resource statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage context is provided. The description does not mention when to use this tool versus alternatives like ibmcloud_resource_service_key_delete or ibmcloud_iam_api_key_create, nor does it note prerequisites such as login or required permissions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the basic function without mentioning read-only nature, permissions required, pagination behavior, or how the service filter affects results. This is a significant gap for a list 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise ('List IAM roles') and front-loaded with the key action and object. There is no wasted language, and the structure is appropriate for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool, the description is minimally adequate, but it lacks essential context: return format, filtering semantics, relationship to other IAM entities, and any operational caveats. Without an output schema or annotations, this description leaves the agent underinformed about how to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides a description for the single optional parameter ('Filter by service name'), giving 100% schema description coverage. The tool description adds no additional parameter semantics beyond what the schema already states, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('IAM roles'), making it a specific verb+resource description. It distinguishes from sibling IAM tools by naming a unique resource type, though it lacks additional scope or context that would make it a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 other IAM listing tools such as ibmcloud_iam_users or ibmcloud_iam_access_groups. The description gives no context for selecting this tool over 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?
With no annotations, the description carries full responsibility for disclosing behavior. It only says 'Get service ID details' with no mention of permissions, read-only safety, potential errors, or the structure of the returned details. This is insufficient for a tool that might require authentication or return complex data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that directly states the tool's purpose. There is no fluff or redundant information, and it is front-loaded with the action verb 'Get'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema), but the description omits any explanation of what 'details' means, what the response looks like, or any error/edge cases. Because there is no output schema, the description should clarify the return value, but it does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the single parameter 'name' as 'Service ID name or UUID', so the description adds no extra meaning. Since schema coverage is 100%, the baseline of 3 applies; 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.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get service ID details' clearly states a specific verb ('Get') and resource ('service ID details'). It is obviously distinct from the sibling list tool 'ibmcloud_iam_service_ids' and create/delete tools, though it doesn't explicitly differentiate itself beyond the implied singular/plural contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like `ibmcloud_iam_service_ids` for listing or `ibmcloud_iam_service_id_create` for creation. The description provides no context about typical use cases or prerequisites (e.g., requires an available service ID name/UUID).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention whether an invitation email is sent, whether any account roles or permissions are required, or whether the invite can be revoked. The behavioral impact remains opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, making it highly concise and easy to parse. It is not overly verbose, though it could have been more informative without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and a minimal one-line description, the context is incomplete. It does not explain expected side effects, prerequisites, or how access_groups are applied, leaving the agent with insufficient information for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters, and their descriptions in the schema are adequate. The tool description adds no additional parameter semantics, matching the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Invite a user to the account' uses a specific verb ('invite') and clearly identifies the resource (user/account). It is distinguishable from sibling tools like ibmcloud_iam_users (listing) and ibmcloud_iam_access_group_user_add (adding to a group), though it does not explicitly call out these distinctions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives, prerequisites, or exclusions. The description only states the action without any context on expected use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, but it only states 'Get cluster details' with no mention of output format, required authentication, side effects, or limitations. It implies a read-only operation but adds no behavioral context beyond what the name conveys.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at three words, with no filler. However, it sacrifices detail for brevity, so it earns a 4 rather than 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read operation, the description is minimally viable but lacks details about what 'details' are returned and how this differs from other cluster-related tools. Given the absence of an output schema, more explanation would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully covers the single 'cluster' parameter with 'Cluster name or ID', achieving 100% schema description coverage. The description adds no additional meaning, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get cluster details' has a specific verb ('Get') and resource ('cluster details'), making the purpose clear. It distinguishes from siblings like ibmcloud_ks_clusters (list) and ibmcloud_ks_cluster_config (configuration) by implying a single cluster's details, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like ibmcloud_ks_clusters or ibmcloud_ks_cluster_config. While the sibling names imply different purposes, the description itself offers no contextual usage instructions 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?
With no annotations provided, the description carries full responsibility for behavioral transparency. It only states 'Configure kubectl for a cluster' without disclosing side effects such as downloading a kubeconfig file, modifying local kubectl context, or requiring authentication/access to the cluster. This is a significant gap for a command that alters local configuration.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant wording. It is compact and front-loaded, effectively communicating the core purpose in the fewest possible words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that modifies local kubectl configuration, the description is incomplete. It does not explain what 'configure' means (e.g., downloading certificates, setting context), nor does it mention any prerequisites or outcomes. Given the simplicity of the schema, a bit more context would make it self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents both parameters with 100% coverage ('Download admin certificates' and 'Cluster name or ID'). The description adds no further parameter semantics, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Configure kubectl for a cluster' clearly names the action (configure) and the target resource (kubectl for a cluster), which distinguishes it from cluster creation/deletion and other cluster operations. However, 'configure' is somewhat generic; 'download the kubeconfig for a cluster' would be more specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives (e.g., ibmcloud_ks_cluster to view cluster details, or other kubectl setup commands). The description gives no context for when it should be invoked.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of explaining behavior but only says 'Create a Kubernetes cluster.' It does not disclose that cluster provisioning is typically long-running, requires account access, or that VPC vs classic cluster behavior depends on parameters like vpc_id and subnet_id.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded with the essential action. It avoids unnecessary words, but it borders on under-specification; however, this is more of a completeness concern than a conciseness flaw, so it earns a solid score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters and no output schema, the description is insufficiently rich. It doesn't explain expected outcomes, prerequisites (e.g., existing VPC/subnet), cluster types, or provisioning time. The description alone would leave an agent under-informed for successful invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 7 parameters with descriptions (100% coverage), so the baseline of 3 applies. The description adds no extra meaning beyond what the schema already provides, though it does not hinder parameter understanding either.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Create) and resource (Kubernetes cluster), which distinguishes it from sibling tools like delete, config, and workers. However, it essentially duplicates the tool name and provides no additional differentiating details such as cluster type or scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, prerequisites, or alternatives. It does not mention requirements like IBM Cloud login, billing, or contrast with ibmcloud_ks_cluster_delete or ibmcloud_ks_cluster_config.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states 'List Kubernetes clusters' and does not mention output format, scope (e.g., account or resource group), pagination, or read-only semantics. This is minimal and lacks detail beyond what the tool name implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at three words with no filler, making it easy to parse. However, it is slightly under-specified because it does not mention the optional provider filter, but the schema covers that, so the brevity is mostly appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and no output schema, the description is minimally viable. It is missing information about returned data, account/region scope, and prerequisites such as login or target context, but the schema fills in the filter option.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the only parameter 'provider' with a description 'Filter by provider (vpc-gen2, classic)', providing 100% schema coverage. The tool description adds no parameter information, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List Kubernetes clusters' uses a specific verb and resource, clearly indicating the action. It is distinguishable from the singular sibling 'ibmcloud_ks_cluster' by pluralization, but it does not explicitly state that distinction, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'ibmcloud_ks_cluster' for details or 'ibmcloud_ks_cluster_create' for creation. The description only states the basic action, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is responsible for disclosing behavioral traits. It only says 'Create a worker pool' without mentioning side effects like adding worker nodes to a cluster, potential cost implications, or required permissions. This is a significant gap for a mutation 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using only six words, and is front-loaded with the action. However, it is arguably under-specified for a tool with multiple parameters, though it does not contain unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation operation with four parameters, no output schema, and no annotations, this description is inadequate. It does not explain what a worker pool is, when to create one, or what the expected outcome is, leaving the agent without sufficient contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage for all four parameters, each with a description, so the baseline is 3. The description adds no additional meaning or context about the parameters beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create) and resource (worker pool), which is specific enough to understand the tool's basic purpose. It distinguishes from sibling tools like ibmcloud_ks_worker_pool_resize and ibmcloud_ks_worker_pools by the 'create' verb, but does not explicitly contrast with 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/5Does 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 ibmcloud_ks_cluster_create or ibmcloud_ks_worker_pool_resize. The description lacks any context about prerequisites, typical scenarios, or when to choose another tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It only says 'Resize' which implies mutation, but does not explain whether it causes downtime, how it affects existing workers, or whether changes are reversible. Critical operational context is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with no filler; it is front-loaded and to the point. While it could include more information, it earns its place as a clear, minimal statement of the tool's core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description should provide more context about the resize operation's impact, prerequisites, or expected results. It is too minimal to fully inform an agent on a mutation tool that affects cluster infrastructure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all three parameters (cluster, pool, size_per_zone) clearly documented. The description adds no parameter semantics, but the schema already provides sufficient meaning, so a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Resize') and the resource ('worker pool'), making the tool's purpose unambiguous. However, it does not differentiate from sibling tools like create or list pools, which is a minor gap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 creating a new pool or scaling other resources. There are no prerequisites, context, or alternative references, leaving the agent without direction for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only states 'List available zones.' It does not explain what zones are, whether any filtering or defaults apply, or describe the output format. This lacks transparency beyond the core action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at three words, with no unnecessary fluff. It avoids verbosity, though it may be slightly under-specified. Still, it is efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two parameters, no output schema, and no annotations, the description is too brief. It fails to mention return values, whether the zones are for a specific region, or any other behavioral details that would help an agent understand the tool's full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters ('Filter by location', 'Filter by provider') are already described in the input schema. The description adds no parameter information, but the schema handles it, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List available zones' clearly states the action (list) and resource (available zones). The tool name suggests Kubernetes, but the description itself is unambiguous enough about the operation. It does not explicitly differentiate from sibling tools, but the resource is unique among 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like ibmcloud_ks_flavors or ibmcloud_ks_versions. There is no mention of use cases, 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?
With no annotations, the description must carry the full burden of disclosing behavior. 'Install' implies a system modification, but the description does not mention side effects, permissions required, whether the installation is silent, or what happens if the plugin already exists. The 'force' parameter hints at reinstallation behavior, but the description itself provides no transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no extraneous words. It efficiently states the tool's core action, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple, but the description is too minimal to be fully complete. There is no output schema, and the description does not explain return values, installation source, or potential failure modes. For an installation tool, more context about expected behavior would be needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for its two parameters, so the schema already explains 'plugin' and 'force'. The description adds no additional parameter semantics beyond the schema, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Install a CLI plugin' clearly states the verb and resource, making it distinct from sibling tools like plugin_list and plugin_repo_plugins. It is concise and unambiguous, though it could be more specific about which plugin repository or source is used.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not indicate when to use this tool versus installing via other means, nor does it mention any prerequisites or context for installing a plugin (e.g., needing to be logged in).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but only states 'Create a resource group.' It does not disclose prerequisites, failure modes, idempotency, or any behavioral traits beyond the basic create action. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no wasted words. It is appropriately front-loaded, though it might be considered too sparse, it earns its place by stating the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create tool with one parameter and no output schema, the description is minimal but lacks important context such as login requirements, account targeting, or what happens on duplicate names. It does not fully equip an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter described as 'Resource group name.' The description adds no additional parameter meaning, but the schema already fully documents the parameter, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a resource group' uses a specific verb and resource, clearly stating the tool's action. It is clear but does not explicitly differentiate from sibling tools like create_service or create_cluster, though the resource type is specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 other create tools in the sibling list. The description simply states the action with no context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits itself. It only says 'Delete a service instance' without noting permanence, cascading effects, or any cautionary details. For a destructive operation, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and resource. There is no filler or redundancy, making it highly efficient and appropriately sized for a simple delete operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though the parameter schema is comprehensive, the description lacks essential behavioral context for a destructive tool. It does not explain return values, prerequisites, or any warnings, leaving the agent without enough information to safely invoke the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes both parameters (name and force) with clear descriptions, so the description does not need to add parameter semantics. The schema coverage is 100%, which meets the baseline for a score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the resource ('a service instance'), which is a specific verb+resource pairing. It does not explicitly distinguish from siblings like create or update, but the name and verb make it unambiguous enough. However, it lacks extra context that would earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives, no mention of prerequisites, force flag behavior, or potential warnings. It is a bare imperative without any usage context, earning a low score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavior on its own. It only says 'List', implying a read-only operation, but gives no detail about pagination, scope (e.g., all instances vs. per resource group), or response shape. This is a minimal disclosure for a list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct phrase with no wasted words. It is front-loaded and appropriately sized for a simple list action, though it could add a bit more context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (optional filters, no required params, no output schema), the description is minimally adequate. It states the core purpose but lacks extra context like filtering behavior or how results are returned, which would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both service_name and resource_group have descriptions), so the schema already explains the parameters. The description adds no additional parameter semantics, but the baseline of 3 is appropriate since the schema carries the load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (List) and resource (service instances), making its purpose evident. It differentiates from singular sibling tools like 'ibmcloud_resource_service_instance' via the plural form, but doesn't explicitly call out this distinction or contrast with other list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No information about when to use this tool versus alternatives. Sibling tools include many other list commands (e.g., ibmcloud_cf_apps, ibmcloud_ks_clusters), and the description provides no contextual guidance or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral disclosure burden. It only says 'Get details' without stating whether the operation is read-only, whether authentication is required, what happens if the key is not found, or the format of the returned details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: six words, one sentence, no redundant information. It is front-loaded with the verb 'Get' and the resource, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and lack of annotations/output schema, the description is too sparse. It omits any context about preconditions, return values, or relation to sibling tools, leaving the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the parameter 'name' with description 'Service key name'. The description adds no additional semantic meaning beyond what the schema already provides, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get details of a service key' clearly states the action (get details) and the resource (service key). It implicitly differentiates from the sibling 'ibmcloud_resource_service_keys' by using singular 'key', but does not explicitly contrast the two, so it is clear but not fully distinguishing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention that the user must supply a key name, nor that listing available keys can be done via 'ibmcloud_resource_service_keys'. There is no when-to-use or when-not-to-use information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'List' which implies a read operation, but there is no explicit statement about read-only behavior, required target context (e.g., org/space), or output format. The sparse description leaves critical behavioral aspects undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single, clear sentence. It is appropriately sized for a simple tool, though it could be slightly more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no parameters, and no output schema, the description should provide more context about the scope (e.g., which Cloud Foundry space is used), any prerequisites like logging in or targeting, and what the returned data contains. The current description is too minimal to be fully useful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% (empty schema). Per the scoring rubric, a baseline of 4 is appropriate since there are no parameters to describe. The description adds no parameter-related information, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the primary action ('List') and the resource ('Cloud Foundry routes'), which is specific enough to understand the tool's function. However, it does not differentiate from other list tools like ibmcloud_cf_apps or ibmcloud_cf_orgs beyond the distinct resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention any prerequisites, target selection, or exclusions, leaving the agent without context for selecting this tool among many similar listing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only restates the tool's name without elaboration. It fails to mention side effects like stopping all app instances, the app becoming unavailable, or reversibility via cf_start.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that is appropriately concise and front-loaded. It avoids unnecessary verbosity and covers the core purpose without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description lacks essential context such as when to stop an app versus starting or restarting it, and what the expected outcome is. Given the presence of closely related sibling tools, this minimal description is insufficient for an agent to make a fully informed decision.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the 'name' parameter described as 'Application name'. The description adds no further parameter semantics, so the schema carries the burden and the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Stop' and identifies the resource as 'a Cloud Foundry application'. It clearly differentiates from sibling tools like start and restart, which involve different lifecycle actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 cf_start, cf_restart, or cf_delete. There is no mention of prerequisites, typical scenarios, or exclusion cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'List' implies a read-only operation, but no details are given about output format, pagination, or authorization requirements. This is minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise phrase with no wasted words. It is front-loaded and easy to parse, though it could benefit from additional context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameter-less list tool with no output schema or annotations, the description is under-specified. It does not clarify which API keys are listed (user vs service) or what information is returned, making it incomplete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty. Per calibration guidance, a baseline of 4 applies since there are no parameters to describe, and the schema fully covers this aspect.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and resource 'API keys', clearly stating the tool's function. It distinguishes from create/delete siblings but does not disambiguate from ibmcloud_iam_service_api_keys, leaving scope ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like ibmcloud_iam_service_api_keys. The description lacks any context about intended use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It only restates the action ('Create a service ID') and omits details like permissions needed, side effects, idempotency, or return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. However, it is essentially a rephrasing of the tool name, which adds minimal informational value, so it does not fully earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations, no output schema, and a very brief description. It does not explain what happens after creation, how to interpret results, or any relationship to related IAM tools, leaving important gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters (name and description). The description adds no additional parameter semantics, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Create' and a clear resource 'service ID'. It effectively distinguishes from sibling tools like ibmcloud_iam_service_ids (list), ibmcloud_iam_service_id (get), and ibmcloud_iam_service_id_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 other IAM creation tools such as ibmcloud_iam_api_key_create or ibmcloud_iam_access_group_create. No prerequisites or alternative contexts are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'View or set' implies read/write behavior, but it does not disclose side effects (e.g., persisting a change, affecting subsequent commands), output format, or whether authentication is needed. This is a minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler, repetition, or unnecessary detail. Every word contributes to conveying the tool's core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description provides the basic purpose but omits surrounding context such as when to use it, what 'view' returns, and what effect 'set' has. It is minimally viable but leaves gaps in expected behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the 'endpoint' parameter is described as 'API endpoint URL'). The description adds no new meaning beyond the schema, but the baseline of 3 applies since the schema already documents the only parameter adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource: 'View or set IBM Cloud API endpoint', clearly stating the tool's function. It distinguishes from siblings like ibmcloud_target, which focuses on org/space/region, though it does not explicitly call out that distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, nor any mention of prerequisites or scenarios where setting an API endpoint is appropriate. The description simply states the operation without contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits on its own. While 'get' implies a read-only operation, it doesn't mention authentication requirements, rate limits, possible pagination, or whether usage data is aggregated or itemized. The description is too thin to fully inform the agent about 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the key action and resource. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple lookup tool with two clearly described optional parameters, the description is minimally sufficient. However, there is no output schema and no mention of what the returned usage data contains or how it might be filtered beyond the parameters. The lack of guidance on differentiating from sibling billing tools leaves a slight gap, but the tool is simple enough that this is not a major deficiency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for both parameters (month and resource_group), so schema coverage is 100%. The description adds no extra meaning about how these parameters interact or what the output looks like. This matches the baseline of 3 for complete schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get usage for resource instances' clearly states a specific verb and resource: it fetches usage data for resource instances. It is distinct from sibling tools like billing_account_usage or billing_resource_group_usage, as it targets resource instances specifically, though it doesn't explicitly call out those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as ibmcloud_billing_account_usage or ibmcloud_billing_resource_group_usage. There is no mention of context, prerequisites, or exclusions. The only implicit signal is the resource scope in the name, but the description itself is silent on usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only says 'get details' with no information about return format, required permissions, or side effects. It implies a read-only operation but does not convey any meaningful behavioral details beyond the name itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no unnecessary words or repetition. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, so the description is minimally viable. However, it lacks context about what 'catalog service' means or what details are returned, and could benefit from referencing sibling tools (e.g., 'Use this after catalog_search').
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents the single parameter 'service' as 'Service name' with 100% coverage. The description adds no further semantic meaning, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Get details') and resource ('catalog service'), making its primary function understandable. It implicitly differentiates from sibling tools like catalog_search (searching) and catalog_service_plans (plans), though it doesn't explicitly state what 'details' include.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 catalog_search or catalog_service_plans. The description lacks any context about prerequisites (e.g., requiring login) or when this is the appropriate choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. 'List' indicates a read-only operation, but no additional behaviors are disclosed—such as whether it lists service instances in the current Cloud Foundry space, output format, or pagination. Minimal behavioral information is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that immediately conveys the action and resource. No filler words or redundant information are present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description is mostly complete for a straightforward list operation. However, it does not specify whether it lists service instances vs. service offerings, and lacks any context about the current org/space, which could be ambiguous for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, which per the rubric sets a baseline of 4. The description does not need to add parameter details since there are none to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List Cloud Foundry services' uses a clear verb ('List') and a specific resource ('Cloud Foundry services'). It is distinct from resource-level service listing tools like ibmcloud_resource_service_instances, but does not explicitly differentiate from related Cloud Foundry siblings such as ibmcloud_cf_create_service or ibmcloud_cf_marketplace.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like ibmcloud_resource_service_instances or ibmcloud_cf_marketplace. The description provides no context about required prior steps (e.g., login, target) or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It merely says 'Set' without explaining whether the variable is created or overwritten, if the app needs to be restarted, or if there are any side effects. This is a significant gap for a mutating 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence of eight words. Every word contributes to the meaning, and there is no repetition or filler. It is maximally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with three string parameters and no output schema, so the description is mostly adequate for basic usage. However, it lacks any note about return values, error conditions, or whether the operation requires certain prerequisites, leaving minor but real gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers all three parameters with descriptive names and descriptions (Application name, Environment variable name, Environment variable value). The tool description adds no new parameter-level meaning, but since schema coverage is 100%, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set an environment variable for an application' clearly states the action (set) and resource (environment variable for an application). It is specific enough to distinguish from sibling tools like ibmcloud_cf_env, though it does not explicitly mention that sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives, nor any prerequisites such as being logged in or targeting a Cloud Foundry space. The description only states what the tool does, not when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the core read operation but does not mention authentication requirements, account context, pagination, or any other behavioral traits that would help the agent anticipate the tool's 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, front-loaded with the verb 'List'. It is appropriately concise for a simple list operation, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description is too sparse to be fully complete. It does not specify the scope of the listing (e.g., all groups in the current account), any prerequisites like authentication, or what the output looks like. With no annotations or output schema, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the schema fully covers parameter handling. The description correctly stays silent on parameters, which aligns with the rule that 0 params yields a baseline of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list) and resource (access groups), making the purpose easy to understand. However, it does not explicitly distinguish from the singular sibling tool ibmcloud_iam_access_group or other access group management tools, relying on the plural name for differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 whether it lists all access groups in the current account or whether login is required. There are no exclusions or references to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'List', which implies a read-only operation, but does not mention what data is returned, whether it requires a targeted Cloud Foundry org/space, or any pagination or sorting behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no wasted words. It is immediately accessible and does not repeat any structured information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter list tool, the description provides a minimal level of completeness. However, it lacks context about operating within a Cloud Foundry org/space or how the result set is scoped, which is relevant given the broader IBM Cloud toolset.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the schema coverage is 100% (vacuously). The baseline for 0 parameters is 4, and the description correctly implies there are no configuration options.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('Cloud Foundry applications'), making the tool's purpose obvious. It does not explicitly differentiate from the sibling 'ibmcloud_cf_app' (singular), but the plural form and clear verb provide adequate clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'ibmcloud_cf_app' for individual app details or 'ibmcloud_cf_orgs' or 'ibmcloud_cf_spaces' for broader context. There is no mention of prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose behavioral traits beyond the act of deletion. It omits irreversibility, potential impact on associated routes (though a delete_routes parameter exists), confirmation behavior, or required permissions. With no annotations provided, the description carries the full burden and falls short.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that front-loads the verb and object. It contains no filler or redundant information, making it maximally concise while still being clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no annotations or output schema, the one-line description is inadequate. It does not explain return values, side effects, required login/target state, or how it relates to other Cloud Foundry commands, leaving critical gaps for an agent to misuse the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes all three parameters (name, force, delete_routes) with concise descriptions. The tool description itself adds no additional semantic meaning beyond what the schema already provides, so it stays at the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Delete') and a clear resource ('a Cloud Foundry application'), making the tool's purpose immediately obvious. It distinguishes itself from sibling tools like ibmcloud_cf_apps, ibmcloud_cf_push, and ibmcloud_cf_start, which perform different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, no prerequisites (e.g., being logged in, targeting a space), and no mention of when not to use it. It simply states the action without any contextual usage directions.
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 responsibility for behavioral disclosure. The verb 'List' implies a read-only operation, but the description does not specify what is returned, whether authentication is required, or any side effects. It adds minimal context beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, 'List CLI configuration', with zero fluff. It is front-loaded, immediately conveying the action and resource. It is appropriately sized for such a simple tool, though it could be seen as under-specification, it is perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (zero parameters, no output schema, no annotations), the description is minimally viable. It tells the agent the operation but is vague about the exact content of the output or any prerequisites. For a simple list tool, this might be acceptable, but it leaves a gap in setting expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is an empty object with 100% coverage. Per the baseline guidance for 0 params, this is a score of 4. The description does not need to add parameter details since there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List CLI configuration' clearly states the action (list) and resource (CLI configuration), which is specific enough to differentiate from sibling tools like ibmcloud_cf_apps or ibmcloud_resource_groups. However, it lacks detail on what exactly constitutes 'CLI configuration' (e.g., target, account, API endpoint), which could be ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description merely states what it does without mentioning prerequisites (e.g., requiring login) or situations where it's appropriate. No exclusions or alternative tools are referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only states the deletion action but does not mention irreversibility, whether the 'force' flag is required or affects behavior, or any side effects on related tags. This is a significant gap for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that immediately conveys the purpose. It is appropriately sized for a simple operation and uses no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite being a simple 2-parameter tool, the lack of annotations and minimal description leaves out critical context for a destructive action. The absence of usage guidelines and behavioral transparency makes it incomplete for an agent deciding whether and how to invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides complete descriptions for both parameters ('image' and 'force'), so schema coverage is high (100%). The description adds no additional parameter semantics beyond what the schema offers, thus the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove') and the resource ('a container image'), which is specific and distinct from sibling tools like ibmcloud_cr_images (list images) and ibmcloud_cr_namespace_add. It follows the pattern of a destructive operation on a single resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, prerequisites, or exclusions. It does not mention alternatives (e.g., ibmcloud_cr_images for listing before deletion) or any conditions for safe deletion. The usage context is only implied by the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral disclosure burden. It only states the creation action, without mentioning whether the operation is idempotent, what side effects occur, or any required permissions. It does not add context beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the tool's purpose. It is front-loaded and contains no unnecessary wording, making it highly efficient for its simple scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create operation with no output schema and no annotations, the description is bare minimum. It does not mention return values, potential errors, or any dependencies. Although the parameter set is small, the lack of behavioral or result context leaves gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for both parameters ('name' and 'description'), so the schema already provides the necessary semantics. The tool description adds no additional parameter context, which is acceptable given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the resource ('an access group'), distinguishing it from sibling tools that list, view, or modify access groups. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, nor any prerequisites or exclusions. The verb 'Create' implies its use but does not offer clear context or comparisons to sibling tools like ibmcloud_iam_access_group or ibmcloud_iam_access_group_policy_create.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. 'Create' implies a mutation, but the description does not mention required permissions, whether the policy is appended or replaces existing policies, whether the access group must already exist, or any side effects. This is a significant gap for a write 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundant information. Every word earns its place, and the structure is appropriately minimal for a simple action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters, no output schema, and no annotations, a one-sentence description is insufficient. It does not explain how the parameters work together, what the expected result is, or any constraints (e.g., whether the access group must exist). The description fails to provide enough context for an agent to use the tool correctly beyond the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each of the 6 parameters having a one-line description. The tool description adds no additional parameter semantics, so the baseline of 3 applies. The schema descriptions are basic but adequate for understanding the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a policy for an access group' uses a specific verb ('create') and resource ('policy for an access group'), clearly distinguishing this from sibling tools like ibmcloud_iam_access_group_policies (which likely lists policies). It states exactly what the tool does without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as ibmcloud_iam_access_group_policies (list policies) or ibmcloud_iam_access_group_create (create the group itself). There are no prerequisites, exclusions, or contextual hints beyond the bare statement of the action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description alone must disclose behavioral traits. It states the action (create) but fails to mention side effects, required permissions, return values, or whether the key is immediately active. For a mutation operation with zero annotation support, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence that directly states the tool's purpose. There is no wasted text or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and an output schema, the description is minimally complete. It explains the core action but lacks usage guidance and behavioral context. For a create tool with four parameters and no output schema, the agent receives only the bare minimum to understand the operation, making it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all four parameters (100% coverage), so the schema already explains parameter meaning. The description adds no additional semantic nuance beyond what the schema reveals. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create an API key for a service ID' uses a specific verb (create) and resource (API key), and clearly scopes to service IDs. This distinguishes it from sibling tools like ibmcloud_iam_api_key_create (which creates user API keys) and ibmcloud_resource_service_key_create.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. While the description implies service ID use, it does not explicitly mention broader context or exclusions, such as when to use ibmcloud_iam_api_key_create instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action 'List' but doesn't mention authentication requirements, scope, or return format. Minimal 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three words and extremely concise, with no filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no params and no output schema, so a short description is acceptable. However, it lacks context about the scope (e.g., account-wide vs current resource group) and any prerequisites, which would help an agent decide when to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline of 4 applies. There is nothing for the description to add, and the schema coverage is trivially 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does 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 'resource groups', which is unambiguous and distinct from sibling tools like resource_group_create. It doesn't add scope details but is specific enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 vs alternatives. There is no mention of typical scenarios, 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?
Annotations are absent, so the description carries the full burden. It only states the basic action 'Create a service key/credential' without disclosing side effects, required permissions, whether the instance must exist, or what happens on success/failure. It adds no behavioral context beyond the verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the core purpose without verbosity, earning a perfect score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description is too minimal. It does not explain return values, requirements like an existing service instance, or the role/parameters interplay. The schema helps, but the tool-level context is incomplete for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema documents all 4 parameters with descriptions (100% coverage). The tool description does not add any additional meaning beyond the schema, so it meets the baseline but does not enrich parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Create) and the resource (service key/credential). It distinguishes from sibling tools like ibmcloud_resource_service_key (view), ibmcloud_resource_service_keys (list), and ibmcloud_resource_service_key_delete (delete) by specifying the create operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., an existing service instance) or mention that creation is for new keys only. No exclusions or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only says 'Attach tags to a resource', which reveals the mutation but does not explain whether tags are appended or replace existing tags, if the operation is idempotent, or what permissions are required. This is a significant transparency gap for a mutating 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that is perfectly concise. It front-loads the action (attach) and the object (tags to a resource), containing no unnecessary words or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a mutation with no annotations and no output schema. The description does not cover important behavioral context like whether the operation is additive or overwrites, whether the resource must exist, or what happens on failure. Given the simplicity of the tool, a bit more context is needed to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: resource_id is described as 'Resource CRN' and tags as 'Comma-separated list of tags'. The description adds no parameter-specific meaning beyond what the schema already provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb (attach) and defines the resource (tags to a resource), clearly distinguishing this from sibling tools like ibmcloud_resource_tags (which likely lists tags) and other resource operations. It is immediately obvious what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, whether the resource must already exist, or contrast with related tools such as ibmcloud_resource_tags or resource group tag operations. Usage is only implied by the tool name, which is insufficient per the rubric.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It only says 'Show', which implies a read operation, but it does not state whether this is non-mutating, what output format to expect, or any permissions required. Minimal behavioral context is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded and free of unnecessary words. It earns its place by clearly identifying the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, so the description is largely sufficient. However, it lacks usage context, does not mention any exclusions or prerequisites, and provides no information about the return format. This leaves some gaps for an agent deciding when and how to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the single parameter 'name' with description 'Application name' at 100% coverage. The tool description adds no extra parameter semantics. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Show') on a specific resource ('environment variables') for an application. It is distinct from the sibling tool ibmcloud_cf_set_env, which sets variables, so the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like ibmcloud_cf_app or ibmcloud_cf_set_env. There is no mention of prerequisites such as targeting an org/space or needing login.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses only the action 'list', with no mention of scoping, authentication requirements, or whether it relies on a targeted org. This is insufficient for a tool with an optional org parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded and contains no redundant information. It effectively communicates the core action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has low complexity and the schema covers the only parameter. However, the description lacks context about the behavior when org is omitted and whether spaces are listed for the current target or require explicit org. This leaves some ambiguity, but it is acceptable for a simple list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage with the org parameter described as 'Organization name'. The description adds no additional parameter semantics, but the baseline of 3 applies since the schema fully documents the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and identifies the resource 'Cloud Foundry spaces', which clearly distinguishes it from sibling tools like ibmcloud_cf_orgs and ibmcloud_cf_apps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 or how the optional org parameter affects results. The description does not explain contexts such as listing spaces for a specific org or the current target.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. The verb 'List' suggests a read-only operation, but the description gives no additional behavioral details such as pagination, default filters, authentication requirements, or whether IBM images are included by default. It discloses very little about the tool's actual behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: 'List container images'. It is front-loaded, contains zero waste, and every word contributes meaning. It is appropriately sized for such a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (two optional parameters, no output schema, no annotations), the description is minimally viable. It clearly identifies the action, and the schema covers parameter meanings. However, it does not mention the IBM Cloud context, expected return format, or any prerequisites like login, leaving some gaps for an agent relying solely on this description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters with 100% coverage ('Filter by repository' and 'Include IBM images'). The description adds no extra parameter semantics, so the baseline of 3 is appropriate. There is no need for the description to compensate for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to list container images. It uses a specific verb ('List') and a specific resource ('container images'), and it is distinct from sibling tools like ibmcloud_cr_image_rm (removes images) and ibmcloud_cr_namespaces (lists namespaces).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or alternative tools. The usage context is only implied by the basic action of listing images.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral transparency. It only says 'List policies for an access group' and discloses no side effects, output format, error behavior, required permissions, or whether the operation is read-only. This is minimal and leaves the agent without expectations about the result or failures.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action and object without any filler. It is appropriately sized for a simple read operation with one parameter, and every word contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description is minimally adequate but sparse. It does not mention what the output looks like, whether the group must exist, or any result characteristics. While the schema covers the parameter, the description leaves some operational context missing, making it 'minimum viable' rather than complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: the sole parameter 'group' is described as 'Access group name' in the schema. The tool description reinforces that the group is the access group but adds no additional semantic details (e.g., whether it's an ID or display name, case sensitivity, or format). With full schema coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List policies for an access group' clearly states a specific verb ('List'), a specific resource ('policies'), and the scope ('for an access group'). It distinguishes from sibling tools like ibmcloud_iam_access_group_policy_create (create) and ibmcloud_iam_access_group (view group details).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. There is no mention of prerequisites, context, or exclusion cases. The description is purely functional and does not help an agent decide between listing policies and creating/viewing policies or groups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits on its own. 'List' implies a read-only operation but does not explicitly state that it makes no changes, nor does it mention authentication requirements, error behavior, or output format. This is insufficient for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero wasted words. It delivers the essential information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list tool, the description is passable but minimal. It lacks context about what the output will look like (users list, IDs, etc.) and does not mention prerequisites like being logged in or the access group needing to exist. Given no output schema or annotations, this is a clear gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the only parameter ('group') with a description, and the tool description reinforces its meaning ('in an access group'). However, no additional details are provided beyond the schema, such as naming conventions or whether the group name is case-sensitive. Baseline of 3 is appropriate due to 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('users in an access group'), clearly distinguishing it from sibling tools like ibmcloud_iam_access_groups (which lists access groups) and ibmcloud_iam_access_group_user_add (which adds a user).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or reference sibling tools such as the access group user add tool. Usage must be inferred solely from the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'List' clearly indicates a read-only operation, but no additional behavioral details such as permissions, return format, or side effects are disclosed. This is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that front-loads the action and resource. Every word contributes value, with no redundancy or ambiguity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential purpose and parameter, but for an agent selecting among many similar IAM and API key tools, the lack of behavioral detail and usage guidance makes it only partially complete. No output schema exists, so the description could have mentioned what the returned list contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully documents the single parameter service_id with its meaning. The description adds no extra insight into parameter usage or formatting, and the baseline is 3 given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List'), the resource ('API keys'), and the scope ('for a service ID'). This differentiates it from the broader ibmcloud_iam_api_keys tool, though it does not explicitly name alternatives. It is specific enough to understand its function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the analogous ibmcloud_iam_api_keys or creation/deletion siblings. The description simply states what it does without any contextual cues or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool is a read-only listing operation via 'List', but does not mention any additional behavioral details such as required authentication, potential empty results, or zone-specific behavior. This is minimally adequate for a simple list.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. It is appropriately front-loaded and easy to parse in one line.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two well-documented parameters and no output schema, the description is adequate but lacks any explanation of how results are scoped by zone/provider or what the return data looks like. It is sufficient for basic invocation but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters ('zone' and 'provider'), so the description adds no extra meaning beyond what the input schema already provides. The baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and identifies the resource as 'machine types/flavors', making the tool's purpose clear. It differentiates from sibling tools like ibmcloud_ks_clusters or ibmcloud_ks_zones, though it does not explicitly name them as alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus other listing tools such as ibmcloud_ks_zones or ibmcloud_ks_versions. The description lacks any mention of prerequisites, use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Get' implies a read-only operation, the description does not mention output format, return value, authentication requirements, or how it handles non-existent instances. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler words. It directly states the purpose in the simplest possible form, earning every word.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one well-described parameter and no output schema, the description is minimally adequate but lacking. It doesn't explain what 'details' includes or what the response contains, and it doesn't mention any preconditions like being logged in. A more complete description would add context about the output or when to prefer this over the list variant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the sole parameter ('name' with 'Service instance name or ID'), so schema coverage is 100%. The description does not add any additional parameter context beyond what the schema provides, such as format constraints or how the name is used. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get details') and the resource ('service instance'). The singular resource distinguishes it from sibling 'ibmcloud_resource_service_instances' (which lists instances) and from create/delete/update siblings. This is a specific verb+resource+scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that this is for retrieving a single instance by name or ID, nor does it exclude cases where listing instances might be more appropriate. No prerequisites or alternative tools are referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It only states 'Show current account information', which implies a read operation but does not disclose what data is returned, whether authentication is required, or any side effects. The behavior is under-specified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundancy or fluff. It is appropriately concise for a zero-parameter read-only tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too vague to be complete. It does not specify what 'account information' includes (e.g., ID, name, billing details), and with no output schema to fill the gap, an agent cannot predict the return value. It also doesn't clarify how 'current' is determined relative to login/target state.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing for the description to explain. The baseline for 0 params is 4, and the description does not need to add parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Show' with a clear resource 'current account information', and it is distinct from sibling tools like ibmcloud_account_list (which lists accounts) and ibmcloud_target (which sets/views target). This clearly identifies the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., being logged in), nor does it contrast with account_list or target. There is no 'when' or 'when not' context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the basic action without disclosing whether it appends to existing membership, requires specific IAM permissions, fails on nonexistent users, or other behavioral traits. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded, and free of unnecessary words. It is appropriately concise for a simple operation, though it could include a bit more behavioral context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two flat parameters fully documented in the schema. However, without annotations or an output schema, the description is minimal and lacks information about side effects, prerequisites, or error conditions. It meets the minimum viable bar but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%—both parameters are documented with descriptions ('Access group name' and 'Comma-separated user IDs'). The tool description adds no additional parameter semantics beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add users to an access group' with a specific verb ('Add'), resource ('users'), and target ('access group'). This distinguishes it from sibling tools like ibmcloud_iam_access_group_create (create group) and ibmcloud_iam_access_group_users (list users).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the tool name and description, but there is no explicit when-to-use guidance or mention of alternatives. The description does not discuss when not to use this tool or how it compares to related operations like removing users or managing policies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only repeats the operation ('list') without any additional context such as whether this is read-only, if it requires specific permissions, how the output is structured, or whether it depends on the current target. The added value over the tool name is negligible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-formed sentence that states exactly what the tool does with no unnecessary words or repetition. It is appropriately sized for the simplicity of the operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description is minimally sufficient: it tells the user the tool lists accounts. However, it lacks any nuance about what 'accessible' means, whether the list includes all IBM Cloud accounts or just those in the current context, or any related information that would help an agent set expectations. The simplicity of the tool keeps this at a 3 rather than lower.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing to document. The description doesn't need to explain parameter semantics, and a baseline of 4 is appropriate since the schema already reflects the absence of parameters completely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('all accessible accounts'), distinguishing it from sibling tools like 'account_show', which focuses on a single account. The scope is explicit and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. It does not mention prerequisites (e.g., logged in), context, or situations where another tool like 'account_show' would be more appropriate. The description is purely a statement of function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It says 'Get' which implies read-only, but it does not disclose what the returned usage data includes (costs, resource breakdown), whether month is required or defaults to current month, or any access requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that is front-loaded with the action and resource. Every word contributes to understanding, with no redundant or vague text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a simple read operation with one optional parameter and no output schema, the description is minimally sufficient but lacks detail on what 'usage' includes or what happens when month is omitted. It is not as complete as it could be for a tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for the only parameter 'month' (format YYYY-MM). The description adds no extra semantic detail, so the 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the specific resource ('account usage') scoped to a 'billing period'. This distinguishes it from sibling tools like billing_resource_group_usage or billing_org_usage by focusing on account-level usage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when account-level usage is needed) but does not explicitly mention alternatives for other scopes (e.g., resource group, org). Sibling names provide context but the description itself lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It states 'view recent logs' but does not explain the effect of the 'recent' boolean (e.g., whether false means streaming or something else), output format, or any limitations. This is a significant gap for such a simple 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly states the tool's purpose. There is no wasted text or unnecessary detail, making it highly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, with a complete schema and no output schema, so the description need not explain return values. However, the ambiguity around the 'recent' parameter and lack of any behavioral context make it only minimally viable for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for both parameters (name and recent), covering 100% of parameters. The description adds no additional semantic meaning beyond what the schema provides, so the 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool views recent logs for an application, using a specific verb and resource. It distinguishes itself from sibling tools like ibmcloud_cf_app (app details) and ibmcloud_cf_env (environment variables).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does 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, but its purpose is implied by the description. It does not mention when not to use it or provide alternative commands for streaming logs or other logging needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only states the action 'List' with no details on output format, pagination, authentication requirements, or side effects. The agent knows it's a read operation but lacks essential 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundancy, repetition, or filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation, the description is minimally viable, but it lacks any detail about return payload, scoping, or required context. Since there is no output schema, the agent gets only the action, not the result structure, making it complete enough for basic use but not richly informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description need not explain parameter semantics. The baseline of 4 applies because the schema already indicates no inputs are required, and there is nothing to clarify.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and resource 'service IDs', clearly distinguishing it from sibling tools like ibmcloud_iam_service_id (singular) which likely shows details. It unambiguously states the action and object.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 vs alternatives such as the singular service_id or create/delete tools. The agent must infer usage from sibling naming conventions and the context, which is not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It states 'View or set' but does not reveal that setting likely persists a session state, whether parameters can be combined or are mutually exclusive, or what the command returns after a 'view' or 'set'. This is especially important for a state-mutating tool where side effects affect subsequent commands.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. Every word contributes to the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with four optional parameters and no output schema. The description covers the core purpose but lacks behavioral details like return values or side effects, which would make it more complete for an agent. It is adequate but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% as each parameter has a clear description ('Target Cloud Foundry org', etc.). The tool description repeats these terms without adding additional semantics, such as whether parameters are independent or how they interact. The baseline for full schema coverage is 3, and this description does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('View or set') and enumerates the exact resource attributes (region, resource group, org, space), making it clear what the tool does. It distinguishes itself from sibling tools that operate on specific resources or list available regions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for configuring the CLI's current working context (target), but it does not explicitly state when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. The context among many siblings provides some implicit differentiation, but no direct guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. The verb 'List' implies a read-only operation, but the description does not explicitly state that it is non-destructive, require any permissions, or describe any side effects. It lacks details about pagination, error behavior, or response format. This minimal disclosure is insufficient for a fully transparent picture.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence: 'List users in the account'. Every word earns its place, and there is no redundancy or filler. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the negligible complexity (no parameters, no output schema, no annotations), the description is largely sufficient to convey the tool's function. However, it could mention the context that it lists IAM users (the name implies this) or clarify whether 'account' means the current IBM Cloud account. Minor missing context prevents a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema confirms this (input schema is an empty object). Per the rubric, 0 parameters gives a baseline of 4. The description adds no parameter information because there are none to explain, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List users in the account' uses a specific verb (List), a resource (users), and a scope (in the account). This clearly distinguishes the tool from siblings like ibmcloud_iam_access_group_users (which lists users in a specific access group) and ibmcloud_iam_user_invite (which invites users). The scope 'in the account' adds clarity and differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or context for choosing this over related IAM tools, such as checking access group members or listing service IDs. There is no explicit 'use this when' or 'instead of' language.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention that login modifies the CLI session state, that it is a prerequisite for other commands, or what happens on failure. This is a significant gap for a state-changing 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that is directly actionable. Every word earns its place, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite being a simple tool, the absence of an output schema and annotations means the description must explain return values, session effects, and prerequisites. It does not mention that login is required before other commands or what a successful login returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents all three parameters with descriptions (100% coverage), so the baseline is 3. The description adds the distinction between 'apikey' and 'sso', but does not clarify the role of 'region' or provide additional format/syntax details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Login') and resource ('IBM Cloud') with the two authentication methods (API key or SSO). It distinguishes itself from sibling tools like ibmcloud_logout and ibmcloud_target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: this is the authentication step for accessing IBM Cloud resources. It implicitly establishes when to use this tool (before other commands), though it does not explicitly name alternatives 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?
There are no annotations, so the description carries the burden. It indicates a read-only list operation, but does not mention prerequisites like being logged in or targeted. The action is straightforward with no side effects, so it is adequately transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no wasted words, perfectly front-loaded with the verb and object.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is very simple with no parameters, so the description is mostly sufficient. However, it lacks any mention of prerequisites or return format, which is a minor gap for a list command.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description need not explain parameter details. The 100% schema coverage is vacuously satisfied, and the baseline for no parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('Cloud Foundry organizations'), making the tool's purpose unambiguous. It clearly distinguishes from sibling tools like ibmcloud_cf_apps and ibmcloud_cf_spaces.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It simply states what it does without mentioning prerequisites, exclusions, or comparative context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. However, it only states the verb 'start' and adds no context about permissions, preconditions, side effects, or return behavior, which is insufficient for a mutating 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence that directly states the action. It is front-loaded and contains no filler or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the parameter schema is complete, but with no annotations or output schema, the description omits important context like prerequisite login/target requirements and expected behavior after completion. It is minimally viable but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage for the single parameter 'name' with description 'Application name'. The tool description adds no parameter-specific information, so the 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Start') and resource ('Cloud Foundry application'), clearly identifying the tool's function. It distinguishes from sibling tools like ibmcloud_cf_stop and ibmcloud_cf_restart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this tool to start a Cloud Foundry application. It does not explicitly mention alternatives or exclusions, but the intended usage is direct and unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'List', which implies a read-only operation with no side effects, but beyond that it does not disclose whether a login is required, what the output format might be, or any other behavioral nuances. For a simple list tool, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that gets straight to the point: 'List installed CLI plugins'. Every word earns its place, and there is no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity — zero parameters, no output schema, and a straightforward list operation — the description is complete enough for an agent to understand what it does. The addition of the word 'installed' provides essential context that distinguishes it from listing repo plugins, making it sufficient for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is fully covered (empty properties). The baseline for 0 parameters is 4, and the description adds no parameter information, which is appropriate since there are none to describe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('installed CLI plugins'), which is specific and unambiguous. It effectively differentiates from sibling tools like ibmcloud_plugin_repo_plugins (which lists available plugins in a repository) by including the qualifier 'installed', though it does not explicitly name an alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use this tool when you need to see installed plugins. However, there is no explicit guidance on when not to use it or how it compares to alternatives like ibmcloud_plugin_repo_plugins or ibmcloud_plugin_install. The context is clear enough for a simple list operation, but it lacks explicit directions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action 'List' without mentioning whether authentication/scoping is required, whether output is paginated, or that it is a read-only operation. This is minimal disclosure beyond the bare intent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence containing exactly the essential information—verb and object—with no filler or redundant phrasing. It is appropriately concise for a parameterless list tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, this description adequately conveys the core function for selection and invocation. It could mention the return format (e.g., a list of namespace names), but the verb 'List' already implies a listing result, so the omission is not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema already fully covers parameter semantics (vacuously). The baseline of 4 applies, and the description adds no unnecessary parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and identifies the resource as 'Container Registry namespaces', clearly distinguishing it from sibling tools like ibmcloud_cr_namespace_add (which adds namespaces) and ibmcloud_cr_images (which lists images). This makes the tool's function unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the verb 'List'—the agent would call this when needing to enumerate namespaces—but there is no explicit guidance about when to prefer this over related tools like ibmcloud_cr_images or ibmcloud_cr_quota. No alternatives 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. The verb 'list' implies a read-only operation, but the description does not mention output format, error behavior, or permissions. It is adequate for a simple list operation but lacks extra transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with zero waste, front-loading the action and resource. It avoids repetition of the tool name and is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list tool with no output schema, the description is almost complete. It clearly states what it does and the parameter required, but could explicitly mention that it returns a list of worker pools for the given cluster. Still, this is a minor omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the single 'cluster' parameter with description 'Cluster name or ID' (100% coverage). The description 'in a cluster' adds no additional meaning beyond restating the parameter's role, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'List' and the resource 'worker pools' with scope 'in a cluster'. It distinguishes from sibling tools like ibmcloud_ks_clusters (list clusters) and ibmcloud_ks_workers (list workers).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing worker pools in a given cluster, but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. The context is clear but minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The verb 'List' clearly indicates a read-only operation, which is a key behavioral trait. However, it does not disclose details such as return value structure, whether it requires specific permissions, or any rate limits. For a simple list tool, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states exactly what the tool does without any wasted words. It is brief and to the point, 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.
Completeness4/5Given 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), the high schema coverage, and the absence of an output schema, the description is sufficiently complete for an agent to select and invoke the tool. It covers the essential purpose and the single parameter's role. It might benefit from noting output details, but that is not necessary for a basic list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with a description for 'cluster' ('Cluster name or ID'), so the baseline is 3. The tool description adds no additional meaning beyond restating that worker nodes are listed for a cluster, which is already obvious from the schema. It neither enhances nor contradicts the parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('worker nodes in a cluster'), clearly distinguishing it from sibling tools like ibmcloud_ks_worker_pools (list worker pools) and ibmcloud_ks_clusters (list clusters). It is direct and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when one needs to see worker nodes for a given cluster, but it does not explicitly state when to prefer this tool over alternatives like ibmcloud_ks_worker_pools or ibmcloud_ks_clusters. There is no mention of exclusions or alternative tools, so the guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Logout' only states the action; it does not disclose what happens during logout (e.g., whether local credentials are removed, session tokens revoked, or if re-login is required). This lack of detail is a significant gap for a tool that affects authentication state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence 'Logout from IBM Cloud' that is front-loaded and contains zero unnecessary words. It perfectly meets the requirement for appropriate sizing and structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no parameters, no output schema, a single clear action), the description is almost complete. However, it could benefit from a note about the effect on the session or credentials, as might be expected in a logout operation. This minor gap keeps it from a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 adds no parameter information, but none is needed since the schema is empty. The description is adequate for a no-argument tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Logout from IBM Cloud' clearly states the action and resource, with a specific verb 'Logout'. It is easily distinguishable from the sibling 'ibmcloud_login' and other tools, leaving no ambiguity about its function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool or provide exclusions. However, given the sibling tool 'ibmcloud_login', the usage is implied as the counterpart to log out after a session. No explicit alternatives or conditions are provided, but the context makes it understandable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. 'List' implies a read-only operation, but it does not disclose any additional behavioral context such as whether it queries a remote repository, requires prior login, or returns any specific output structure. It is minimally transparent but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action and resource. Every word contributes, with no filler or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema, no annotations), the description is adequate to understand the tool's purpose and invoke it correctly. It could benefit from a note about return format or repository source, but for a zero-parameter list operation, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so parameter semantics are not applicable. The baseline for 0 parameters is 4, and the description adds no irrelevant parameter information, so this score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List available plugins from repository' uses a specific verb ('List') and resource ('available plugins from repository'), clearly distinguishing this tool from sibling 'ibmcloud_plugin_list' which likely lists installed plugins. The scope is explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 vs alternatives. There is no mention of when to use this instead of 'ibmcloud_plugin_list' or how it relates to plugin installation workflows. The description only states what it does, not when it 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?
There are no annotations, so the description fully bears the burden of behavioral disclosure. 'List' clearly implies a read-only, non-destructive operation, but the description does not mention authentication requirements, return format, or any other behavioral characteristics. It is adequate 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that is completely front-loaded with the essential purpose. Every word earns its place, and there is no wasted content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool, the description conveys the core action and result ('List... regions') sufficiently. It lacks mention of authentication prerequisites or the exact structure of the returned data, but the simplicity of the operation means this is acceptable. A slightly richer description might include 'no login required' or 'returns region IDs and names'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the schema fully covers all parameter information. The baseline for 0 parameters is 4, and the description does not need to add parameter details since there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a clear resource ('available IBM Cloud regions'), making the tool's purpose immediately obvious. It is distinct from sibling tools like ibmcloud_ks_zones, which focus on zones rather than regions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, nor are there any prerequisites or context mentioned. While the tool is simple, the description lacks any explicit usage direction, such as whether login is required or when to prefer this over similar list commands.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. 'Get' implies a read-only operation, but the description does not disclose any additional context such as authentication requirements, output format, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler words. It is appropriately front-loaded and easy to parse, with every word earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters, but there is no output schema and the description does not describe the return value structure or any prerequisites. While it adequately states the purpose, it lacks contextual detail such as what the quota includes or how it is scoped.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema reflects this with 100% coverage. Since there are no parameters to explain, the baseline of 4 applies; the description adds no parameter information because none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and identifies the resource 'Container Registry quota information'. This clearly distinguishes it from sibling CR tools like ibmcloud_cr_images and ibmcloud_cr_namespaces.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives. The usage is only implied by the name and description, suggesting it should be called when quota information is needed, but no exclusions or alternatives are mentioned.
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 responsibility for behavioral disclosure. It states that it lists versions but does not mention return format, whether authentication is required, or any other behavioral aspects. For a simple read-only list, this is acceptable but minimal, and adds little beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. Every word contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema, no annotations), the description is complete enough to inform an agent. It fully states what the tool does. It could optionally mention the IBM Cloud Kubernetes Service context, but that is implied by the naming convention.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is fully covered (vacuously). Per rubric, 0 params baseline is 4. The description does not need to add parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List available Kubernetes versions' uses a specific verb (List) and resource (available Kubernetes versions), clearly distinguishing it from sibling tools like ibmcloud_ks_clusters (list clusters) and ibmcloud_ks_flavors (list flavors). The purpose is immediately obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: this tool lists Kubernetes versions. It does not explicitly mention alternatives or exclusions, but for a simple, parameterless list command, the context is sufficient. No misleading information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. 'Show' clearly implies a read-only, non-destructive action that outputs version information. This is sufficient for a zero-parameter informational 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that precisely communicates the tool's function. Every word earns its place with no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool whose sole purpose is to display version information, the description is fully complete. There are no hidden side effects, complex inputs, or return values to document.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema already reflects this with 100% coverage. The description adds no parameter details because none are needed, which is appropriate. Baseline of 4 is warranted for tools with no params.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool displays the IBM Cloud CLI version with a specific verb ('Show') and resource ('IBM Cloud CLI version'). It is distinct from all sibling tools, which focus on specific services, accounts, or configuration, making it unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The tool is a simple version check and its use is self-evident, but the description provides no explicit guidance on when to use it or what alternatives exist. For a trivial utility, this is acceptable but not outstanding.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/ExpertVagabond/ibmcloud-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server