WXO Builder MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
There are overlapping list tools (list_skills, list_standard_tools, list_tools_with_connections) that could cause confusion, and execute_tool vs test_tool_local both invoke functionality but through different paths. However, the detailed descriptions with usage hints help an agent differentiate between them.
Naming Consistency5/5
All tool names follow a consistent verb_noun snake_case pattern (e.g., list_agents, get_agent, create_connection, delete_flow). Even compound names like create_tool_and_assign_to_agent and update_agent_instructions_from_tools maintain the pattern, making the naming predictable and uniform.
Tool Count3/5
With 35 tools, the server is on the heavy side, but the scope is broad, covering agents, skills/tools, connections, and flows. Some tools could be consolidated (e.g., list_standard_tools and list_tools_with_connections overlap with list_skills), but the count is justifiable for a comprehensive builder API.
Completeness5/5
The tool surface is exceptionally complete for the stated domain. It covers full CRUD lifecycle for agents (list, create, get, update, delete, invoke), skills/tools (list, get, deploy, update, delete, copy, execute, assign), connections (list, get, create, configure, delete), and flows (list, create, get, delete) plus API discovery via get_api_spec. No obvious gaps or dead ends are present.
Average 3.4/5 across 35 of 35 tools scored. Lowest: 2.3/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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must convey behavioral traits. It only states the mutation action but fails to disclose idempotency, how updates are identified (e.g., via flow_json contains id), side effects, or return behavior. This exposes significant gaps 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than concise efficiency. A single phrase with no elaboration does not earn high marks for structure, as it omits critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and a complex nested parameter (flow_json) wholly undocumented, the description leaves the agent without enough context to invoke the tool correctly. It is severely incomplete for a creation/update operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter flow_json has zero schema description coverage, and the description offers no explanation of its structure, required fields, or how it determines create vs update. The parameter semantics are entirely absent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action as creating or updating a flow, which is specific enough to distinguish from sibling list/get/delete operations. However, the dual 'or' leaves ambiguity about the exact conditions for create vs update, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, prerequisites, or scenarios where creating vs updating is appropriate. The description is purely functional with no 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, but it only states the action and parameter. It does not mention return format, error behavior, or safety characteristics, leaving the agent without any insight into side effects or assumptions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no wasted words, achieving high conciseness. While it is under-specified, that is a completeness issue rather than a structure issue, so it earns a 4 for efficient phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only one parameter and no output schema, so the description should clarify return value and edge cases. It does neither, leaving the agent unsure what the 'get' returns, what happens if no connection exists, or whether any additional context is needed. The description is minimal but incomplete for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only the type 'string' for app_id with zero description coverage. The description adds that the operation is 'by app_id' but does not explain the semantic meaning of app_id (e.g., what it identifies, format, or whether it is a required unique key), providing minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Get' and the resource 'connection', and specifies the lookup key 'app_id', making the primary action clear. It implicitly distinguishes from list_connections by indicating a specific fetch, though it does not explicitly contrast with 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use get_connection versus list_connections or other connection-related tools. The description merely restates the function name without context or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It does not state whether the operation overwrites existing credentials, is idempotent, requires authentication, or has any side effects. It merely states the action without any behavioral context, which is insufficient for an 8-parameter configuration tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and front-loaded, with no redundant words. However, it is arguably under-specified, sacrificing necessary detail for brevity. As a concise summary of the tool's purpose it works, but it would be better expanded with a sentence or two of behavioral or parameter context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 8 parameters, 2 required, no annotations, and no output schema, so the description is the only source of guidance. It provides almost no context about parameter relationships, environment handling, or side effects. This is severely inadequate for an agent to correctly configure credentials, especially given the credential-type-specific parameter dependencies.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds minimal meaning beyond the schema. While it lists the three kind values, it does not explain how parameters like token, username, password, server_url, or env relate to specific credential types. An agent cannot determine which parameter combinations are valid for each kind without additional information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's function as configuring connection credentials, with the parenthetical listing the supported credential types (api_key, basic, bearer). This distinguishes it from sibling tools like get_connection or delete_connection, though it doesn't explicitly clarify whether it creates or updates a connection. The verb 'configure' and resource 'connection credentials' are 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/5
Does 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 such as create_connection or execute_tool. No prerequisites, environment context, or exclusions are provided. The description only implies that it is used for setting credentials but does not explain use cases or selection criteria.
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 must disclose behavioral traits. It only says 'List all available flows' — it does not mention pagination, rate limits, authentication, or return format. This leaves significant unknowns for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no redundant wording. It is maximally concise, though this brevity trades off against completeness in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 optional pagination parameters, no output schema, and no annotations, the description is severely under-specified. It fails to clarify basic behaviors like pagination or what constitutes a 'flow', making it incomplete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines 'limit' and 'offset' but provides no descriptions (0% coverage). The description does not mention these parameters or explain their role, so the agent has no understanding of how to use them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with the resource 'flows' and further clarifies 'all available flows', which distinguishes it from sibling tools like get_flow, create_flow, and delete_flow. The intent 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like list_agents or list_connections. The description only states what it does, leaving the agent without context on selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only reveals that passing the tools array assigns tool IDs, but omits response behavior, error cases, permissions, or any side effects beyond creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences and contains no waste, front-loading the primary action and adding a single helpful hint about tools. It could be more structured with parameter sections, but it's efficiently concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no output schema, and no annotations, this description is insufficient. It doesn't specify what the response looks like, whether creation is synchronous, or if prerequisites exist, making it difficult for an agent to confidently invoke and verify the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must explain parameters, but it only addresses the optional tools array. The other parameters (name, description, model_id, instructions) are left entirely to their self-explanatory names, and the description adds no extra meaning for them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The verb 'Create' plus resource 'agent' clearly defines the operation, distinguishing it from siblings like update_agent, delete_agent, and invoke_agent. However, it doesn't provide any context about what an agent is or any unique validation rules, so it's clear but not exceptionally informative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as update_agent or assign_tool_to_agent. It simply states the action without preconditions, exclusions, or mention of related workflows.
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 that the tool lists items, implying a read-only operation, but does not mention pagination, authentication, rate limits, or any side effects. The limit/offset parameters are not explained, so the behavior 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the core action and resource. It contains no wasted words and is easy to parse, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has two parameters with no descriptions, no output schema, and no annotations, leaving the description to cover all context. It does not explain pagination behavior, return format, or how this tool differs from similar list tools, so the description is incomplete for effective usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two parameters (limit and offset) with no descriptions, and schema description coverage is 0%. The description does not mention these parameters at all, leaving the agent to infer their meaning from the names alone. Since the description provides no compensation, parameter semantics are severely lacking.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('List') and the resource ('available tools/skills in the Watson Orchestrate catalog'), giving a clear overview of the tool's function. However, it does not differentiate from similar sibling tools like list_standard_tools or list_tools_with_connections, so it misses some 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the many sibling list tools. The description only implies usage by stating it lists all available items, but it does not mention any exclusions, alternatives, or prerequisites.
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 full behavioral transparency. It mentions setting a connection ID but does not disclose side effects (e.g., persistence, state changes), required permissions, or response behavior. This is crucial for a potentially mutating deploy operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and the second sentence gives a targeted usage hint. It is concise and free of extraneous content, earning a high score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and zero schema descriptions, the description is too sparse. It fails to cover prerequisites, the deployment process, expected outcomes, or parameter interactions. The agent lacks critical context for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the parameters. It provides a specific, actionable hint for openapi_spec (setting x-ibm-connection-id), but tool_spec is entirely unexplained. The description adds value for one parameter but leaves the other opaque.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: deploying a tool from an OpenAPI spec. It identifies both the resource (tool) and source (OpenAPI spec), making the purpose understandable. However, it does not differentiate from similar siblings like 'deploy_tool_from_url' or reconcile the 'skill' name with 'tool'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like deploy_tool_from_url or create_tool_and_assign_to_agent. The only hint is the connection-binding instruction, which is specific to setup but not comparative.
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, placing the full burden on the description. 'List all available agents' merely restates the tool name and offers no additional behavioral details such as pagination behavior, sorting, permissions, or whether it returns all agents at once or in pages. This adds no transparency beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence, which is concise and free of unnecessary words. However, it is somewhat under-specified, as it omits details about pagination and parameters, though this is not a violation of conciseness per se.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two pagination parameters, no output schema, and many sibling list tools, the description is incomplete. It fails to explain how 'all' agents relates to limit/offset, and it doesn't clarify the return format or any constraints, leaving substantial gaps for an agent to guess.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, and the description does not mention the 'limit' or 'offset' parameters at all. It offers no meaning for these parameters, leaving the agent to infer their purpose from the schema alone, which is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: listing all available agents. The verb 'list' and resource 'agents' are specific, and it distinguishes from sibling list tools like list_skills and list_connections, which target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing agents but provides no explicit guidance on when to prefer this over related tools like get_agent or list_agent_tools. There is no mention of pagination or typical use cases, so the guidance is only implicit.
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 that the tool lists available connector applications, but does not mention whether the operation is read-only, how the limit parameter affects results, or the structure of the return value. This lack of transparency could lead to incorrect assumptions about side effects or pagination behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It is appropriately concise for a simple listing operation. However, its brevity comes at the cost of missing important information about parameters and usage, so it is not perfect.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a limit parameter and no output schema, the description should explain how the limit affects results and what the return format is. It also lacks any mention of pagination or filtering behavior. The description is too sparse to be considered complete for a tool with even minimal complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (limit) with no description, and the catalog description does not mention it at all. Since schema description coverage is 0%, the description should compensate by explaining the parameter's purpose, but it fails to do so. The agent has no guidance on what 'limit' controls or how it should be used.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list), the resource (connector applications), and the source (the catalog). This effectively distinguishes the tool from sibling tools like list_connections, which likely list connections rather than connector applications. The verb and object are 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as list_connections or list_standard_tools. There is no mention of context, exclusions, or scenarios where this tool is preferred. The user is left without information about appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It lists the updatable fields (name, display_name, description, permission), which is helpful, but it does not explain whether the update is partial or full, how skill_id is used, or what happens on failure or invalid input.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler words. It efficiently conveys the action and scope, making it easy to parse at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the nested skill_json parameter, lack of annotations, and absence of an output schema, the description is too sparse. It does not explain the request/response structure, error behavior, or how the update is applied, leaving significant gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description partially compensates by naming the updatable fields, which likely reside inside skill_json. However, it does not clarify the role of skill_id or the expected structure of skill_json beyond those four fields, leaving the free-form object ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update a tool (name, display_name, description, permission)' clearly identifies the action (update) and the resource (a tool/skill) along with the specific mutable fields. It distinguishes from siblings like delete_skill or deploy_skill through the verb 'update', though using 'tool' instead of 'skill' creates minor 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided about when to use this tool versus alternatives such as create_tool_and_assign_to_agent or deploy_skill. The only implied context is that 'update' indicates modifying an existing resource, but there are no prerequisites, exclusions, or alternative references.
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 behavioral disclosure burden, but it only reveals that credentials are configured later. It does not mention required inputs, side effects, return value, or whether the connection is usable before configuration, leaving significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no fluff. It is front-loaded with the core action and uses the second sentence to add a valuable reference to the next step.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool has only two simple parameters and no output schema, the description is still too incomplete: it omits parameter semantics, does not clarify what a connection consists of, and gives no indication of what happens upon creation. There is no annotation context to fill the gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no descriptions for app_id or display_name, and the description does not explain either parameter. With 0% schema description coverage, the description should compensate but instead ignores parameter meaning entirely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a connection, and the second sentence differentiates it from the sibling configure_connection by noting credentials are handled separately. It is specific enough, though 'Create a connection' closely mirrors the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit usage sequence: first create the connection, then use configure_connection for credentials. This gives clear context for when this tool is appropriate, though it does not mention alternatives like listing or deleting connections.
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 without indicating whether deletion is permanent, if it cascades to related resources (e.g., agent assignments), requires authentication, or has other side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded phrase with no extraneous words. Every word earns its place, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It does not mention return values, error conditions, or side effects, and lacks usage context that would help an agent safely invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only says 'by ID', which adds minimally to the parameter name flow_id. It does not explain the ID format, source, or how to obtain it, leaving the agent without crucial parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a flow by ID' uses a specific verb (delete), specifies the resource (flow), and identifies the key parameter (ID). It clearly distinguishes from sibling tools like get_flow, create_flow, and list_flows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites, exclusions, or conditions under which deletion might be unsafe. The intended usage is only implied by the tool's name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden of behavioral disclosure. It only states that it lists connections and includes scope values, but it does not explain the output format, whether details are returned, or any authentication 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/5
Is 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 and the parameter scope. No unnecessary words or repetition, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only one parameter, but the description lacks information about the return value or any usage nuances. Given no output schema and no annotations, the description is adequate but leaves clear gaps about what the agent will receive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explicitly names the scope parameter and lists its enum values, which adds basic clarity. However, it merely restates the enum and does not add deeper meaning about parameter behavior or formatting, so it only partially compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists configured connections and mentions the scope parameter with its possible values (draft, live, all). However, it does not differentiate from sibling tools like list_active_live_connections, so it lacks explicit sibling 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/5
Does 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 list_active_live_connections or other related tools, and the scope parameter only implies filtering without contextualizing it against other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It states the fields to update but does not mention possible side effects, whether settings are replaced or merged, required permissions, or any preconditions. The update action is vague regarding its impact on existing chat starter settings.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that is front-loaded with the primary action and field list. Every word adds value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a mutation tool with no annotations, an output schema, or schema descriptions, the description leaves significant gaps. It lacks information about return values, error scenarios, whether both identifiers are accepted mutually exclusively, and the effect on existing quick_prompts (e.g., append vs replace). The description is too brief for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful parameter semantics beyond the schema: it specifies the structure of quick_prompts as an array of {title, prompt} and explains that either agent_id or agent_name can be used. Since schema description coverage is 0%, this information is essential and largely compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates chat starter settings and lists the specific fields (welcome_message, quick_prompts). The verb 'update' and resource 'chat starter settings' are specific, and the name aligns. However, it does not explicitly differentiate from the sibling tool get_agent_chat_starter_settings, though the action is inherently distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It only mentions 'Use agent_id or agent_name,' which is a parameter selection hint rather than contextual usage guidance. There are no exclusions or alternative suggestions.
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 merely states 'Delete a skill by ID' without mentioning irreversibility, potential side effects, permission requirements, or success/failure behavior. For a destructive operation, this is a significant omission.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence containing only the essential information. It is extremely concise and front-loaded, with zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's simplicity, the description lacks critical context about the effects of deletion. It does not mention whether the action is reversible, what happens to associated data, or any other behavioral caveats. For a destructive tool, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter skill_id is clearly required in the schema, and the phrase 'by ID' links it to the deletion action. However, the description adds little beyond the schema itself; it does not explain where the ID comes from or any constraints beyond the type string. Given the simplicity, this is adequate but not compensating.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'delete' with resource 'skill' and specifies identification by ID. It clearly distinguishes from sibling tools like get_skill, update_skill, and copy_skill, leaving no ambiguity about the 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/5
Does 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, nor any prerequisites or exclusions. It is a pure action statement with no context about appropriate invocation scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Delete', but does not indicate irreversibility, permission requirements, side effects, or error behavior. 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the primary purpose. It contains no wasted words and 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description covers the core action and the key parameter. However, it lacks context about what happens upon deletion (e.g., idempotency, not-found behavior) and any related effects, which would be valuable for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description's 'by app_id' does add meaning by indicating that app_id is the identifier used to select the connection. However, it does not explain format, validation, or any constraints beyond the schema's string type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Delete' and identifies the resource as 'connection', with the scope 'by app_id'. This clearly distinguishes it from sibling tools like get_connection, create_connection, and configure_connection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, no prerequisites, and no mention of exclusions. The description merely states what it does, leaving the agent to infer 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 full burden but only repeats the name and parameter. It does not disclose whether the operation is read-only, what the return format is, or any potential errors or permissions, providing no behavioral value beyond the 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded and earns its place without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no annotations and no output schema, the description is too sparse. It lacks context about what a flow is, how to find flow_id, or what the response contains, leaving significant information gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only says 'by ID', which mirrors the parameter name. It does not explain the format, source, or any constraints for flow_id, failing to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a flow by ID' clearly states a specific verb (get), resource (flow), and qualifier (by ID), distinguishing it from sibling tools like list_flows and create_flow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies you use this tool when you have a flow ID and want that specific flow, but it does not explicitly mention alternatives like list_flows for finding IDs or other contexts. Usage is implied, not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action is a delete, but does not mention whether deletion is permanent, whether it cascades to associated tools/skills, or whether any confirmation or permissions are required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that front-loads the primary action and target. Every word earns its place; there is no redundancy or superfluous detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter delete operation, the description is minimally adequate but lacks mention of return behavior, destructive consequences, or effect on related resources. It is complete enough for a very simple tool but not richly informative given no annotations or output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documents agent_id as a required string with 0% description coverage. The description only repeats 'by ID', adding minimal meaning beyond the schema and no additional format, source, or lifecycle context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete an agent by ID' uses a specific verb and resource, clearly distinguishing it from sibling tools like delete_skill or delete_flow. It unambiguously states the operation and target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by ID' implies an agent ID is needed and that the tool is appropriate when deleting a specific agent. However, it provides no explicit guidance about prerequisites, irreversibility, or when to prefer alternatives like update_agent.
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 present, so the description must convey behavioral traits. It discloses the returned content (an OpenAPI spec) but doesn't explicitly declare this as a safe, read-only operation or mention the impact of the format parameter. Given the 'Get' verb and introspection purpose, the lack of side-effect warnings is reasonable, but the description remains minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary action, and no redundant words. Every sentence contributes meaning: what it gets, what it contains, and why to use it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one optional parameter and no output schema, so the description must be comprehensive. It is not complete because it omits any explanation of the format parameter, leaving the agent uncertain about how 'full' vs 'summary' affects the returned spec.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines a 'format' parameter with enum values 'full' and 'summary', but the description does not mention or explain it. With 0% schema description coverage, the description must compensate, and none of the parameter semantics are conveyed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the Watson Orchestrate OpenAPI spec and enumerates its scope (tools, agents, connections, flows, runs). This concise verb-object construction distinguishes it from sibling tools that target specific entity types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Use to understand what operations the Watson Orchestrate instance supports' provides clear context for when to call this tool. It implies using this instead of scanning individual list/get tools, though it doesn't explicitly name alternatives or state 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 the internal process: 'Fetches tools, builds helpful instructions, and patches the agent.' This is useful, but it does not explain side effects on existing instructions, permissions required, or error behavior. The disclosure is partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, direct, and front-loaded with the main action. Every word contributes value, and the example use case adds context without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (two optional parameters, no output schema, no annotations), the description is incomplete. It fails to explain parameter semantics, prerequisites, or what the patch entails. The process description is high-level but does not equip an agent to invoke the tool correctly with confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain 'agent_id' or 'agent_name' at all. It does not clarify which parameter is required, whether both are needed, or how they relate. The description provides no compensation for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Update an agent's instructions based on its assigned tools.' It specifies the verb ('update'), the resource ('agent's instructions'), and the method ('based on its assigned tools'). The example use case ('update TimeWeatherAgent instructions based on its tools') further distinguishes it from generic 'update_agent' and other sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear context with the example use case, indicating when to use the tool. However, it does not mention alternatives or explicitly state when not to use it. It gives a concrete scenario but lacks exclusionary guidance.
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 responsibility for behavioral disclosure. It explains that copying preserves spec and connection and imposes naming constraints. However, it does not disclose what happens to skill_id or skill_name, whether existing tools with the same name are overwritten, or any potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized: three sentences, front-loaded with the main action. Every sentence provides useful information without redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, with no output schema and only three parameters, one required. The description covers the core purpose and naming convention but misses parameter semantics for two of three parameters and lacks usage guidance. It is functional but incomplete for full agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains new_name but leaves skill_id (the required parameter) and skill_name unexplained. This creates ambiguity about which parameter identifies the source tool and what skill_name represents, failing to fully compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Copy a tool' and specifies the result: 'Creates a new tool with same spec and connection.' It also provides a concrete example of custom naming (MVKWeatherV2), making the tool's purpose specific and distinct from sibling tools like create_tool_and_assign_to_agent or deploy_skill.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you want to duplicate a tool) and provides an example of using new_name, but it does not explicitly mention alternatives or when not to use the tool. It gives some context for naming but lacks explicit exclusions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It does reveal key behaviors (auto-creates connection for key-based APIs, no auth for public APIs), but omits side effects (e.g., overwriting existing tools, permanence, or return value). This is useful but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences, front-loaded with the core purpose. The second sentence lists use cases efficiently, though the 'NOT ADK' clause is slightly cryptic but not wasteful. It earns a high score for minimalism without missing critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main use cases and gives enough context for a straightforward deployment action. However, given no output schema and no annotations, it leaves gaps such as failure handling, idempotency, or what happens after creation. It is adequate but not fully complete for an agent to anticipate all outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain any of the three parameters (url, tool_name, description) beyond their names. While the names are self-explanatory, the description adds no meaning, so it fails to compensate for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a tool from a URL' with a specific verb and resource. It distinguishes itself from sibling tools like 'deploy_skill' (skill vs. tool) and 'create_tool_and_assign_to_agent' (no mention of assignment), making its scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool: for APIs with API key (auto-creates connection) and public APIs (no auth needed). It explicitly says 'NOT ADK', giving an exclusion, though it does not name sibling tools as alternatives. This is clear enough for an agent to decide 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It indicates a read operation via 'Get' and specifies the returned fields, but it does not explicitly state that no changes are made, require authentication, or define behavior for missing/ambiguous agents. This 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the core purpose, and each sentence earns its place. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with two optional params and no output schema, the description covers the essential information: what is retrieved and how to identify the target. It lacks explicit behavior on not-found scenarios and does not provide return structure details beyond the field names, but it is reasonably complete for this low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain parameters. It explains that agent_id or agent_name can be used as alternative identifiers, adding meaning beyond raw string fields. However, it doesn't clarify whether at least one is required, how conflicts are handled if both are provided, or the expected format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb 'Get' and resource 'chat starter settings for an agent', and elaborates that this includes 'welcome message and quick prompts'. This distinguishes it from sibling tools like get_agent and update_agent_chat_starter_settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It instructs to 'Use agent_id or agent_name', providing parameter usage guidance, but it does not explicitly state when to use this tool versus alternatives such as get_agent or update_agent_chat_starter_settings. The context implies using it when you need starter settings, so usage is only implied, not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since annotations are absent, the description carries the burden for disclosing behavioral traits. It does add some useful detail by stating that it works with public APIs (no auth) and APIs with keys, which informs the agent of authentication requirements. However, it omits other important behaviors such as idempotency, side effects (e.g., overwriting an existing tool), or the return value, leaving gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using three short sentences to convey purpose, example usage, auth compatibility, and an exclusion. It is front-loaded with the core function and contains no redundant or filler content, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters, no output schema, and no annotations, increasing the need for descriptive completeness. While the description covers the core purpose, an example, and auth handling, it fails to explain the 'description' parameter, potential side effects, or how this tool differs from the sibling deploy/assign tools beyond being 'ONE step.' This leaves the description moderately complete but with notable gaps for a tool with this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter semantics. It implicitly explains 'url' (from URL) and 'agent_name' (assign to agent), but it does not clarify 'tool_name' or the optional 'description' field. The example hints at tool_name but does not define its role or constraints. Given the low coverage and partial compensation, this score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Create a tool from URL and assign to agent – ONE step.' This specific verb+resource+outcome combination directly conveys the tool's purpose and distinguishes it from the separate sibling operations (deploy_tool_from_url and assign_tool_to_agent) by emphasizing the combined single-step nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a concrete example of when to use the tool ('Use for 'create REST Countries tool and assign to TimeWeatherAgent'') and notes compatibility with both public and key-authenticated APIs. It also explicitly directs users to avoid the ADK, giving an exclusion. However, it does not explicitly mention using the separate sibling tools when only one step is needed, so differentiation from alternatives is incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It explains the internal flow: 'Resolves tool names... ensures an agent has the tool, then invokes it.' However, it doesn't disclose potential side effects, permission requirements, or error behavior, which leaves significant gaps for an execution tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences: purpose, usage examples, and mechanics. Every sentence adds value, and the most important information (what it does) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, no annotations, and four parameters with zero schema descriptions. The description gives a basic overview but omits critical details such as the return value format, how to handle errors, whether execution is synchronous, and clear semantics for agent_id. This is inadequate for a generic execution tool with such sparse structured metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It explains that parameters should be passed as a JSON object and distinguishes between name and ID for tool identification. However, agent_id is only implicitly mentioned via 'ensures an agent has the tool,' and the schema itself provides no property descriptions, so the compensation is incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Execute a Watson Orchestrate tool by name or ID.' It provides specific examples like 'execute News Search Tool' and distinguishes itself from siblings such as invoke_agent by focusing on tool execution rather than agent invocation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage context with examples ('Use for prompts like...'), which helps the agent know when to call this tool. However, it doesn't mention when not to use it or directly name alternatives, so it lacks the full exclusionary guidance of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool performs a direct HTTP GET, runs locally, and bypasses Watson Orchestrate. However, it does not mention what the response looks like, error handling, or any side effects, which is a notable gap for a testing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences, each conveying essential information: purpose, usage triggers, and scope/exclusion. It is front-loaded, with no filler or redundant content, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple GET testing tool, the description covers the core purpose and usage. However, with no output schema and no annotation, it leaves gaps: the return value is not described, and the 'params' parameter is unexplained. This is adequate but not fully complete for an agent to invoke it with confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It implicitly suggests the 'url' parameter by stating 'Test an API endpoint,' but it gives no explanation for the 'params' object. The description adds minimal meaning beyond the bare schema, and the 'params' parameter remains ambiguous in purpose and format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Test an API endpoint locally (direct HTTP GET).' It identifies a specific verb (test) and resource (API endpoint), and adds the scope 'locally' to distinguish it from orchestrated tools. This is a complete purpose statement that differentiates from siblings like execute_tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage triggers are provided: 'Use for "run locally" or "test locally".' The phrase 'Does not go through Watson Orchestrate' serves as an implicit when-not, indicating it is not for orchestrated calls. However, it does not name alternative tools explicitly, so it falls short of a 5.
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 indicates the operation is a mutation ('add to toolkit'), but it does nothing to disclose side effects, idempotency, overwrite behavior, or required permissions. With no annotations provided, the description carries the full burden, and 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose. The first sentence states what the tool does; the second gives parameter guidance and a context-specific hint. Every phrase contributes value, and there is no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With four parameters, no required fields, no output schema, and no annotations, the description covers the basic usage and an example but leaves gaps. It fails to clarify what happens on duplicate assignments, whether both name and ID are needed, or what the response looks like, making it minimally viable but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema offers zero descriptions and no required fields for the four parameters. The description meaningfully clarifies that either tool_name or tool_id and either agent_name or agent_id can be used, which partially compensates for the schema's silence. It does not address whether both are required or the priority if both are provided, but adds useful structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'assign' and clearly identifies the resource ('a tool to an agent') with the parenthetical 'add to toolkit' reinforcing the action. It distinguishes from the sibling 'create_tool_and_assign_to_agent' by focusing on assigning an existing tool, and the MCP/ADK comment adds environmental clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a concrete example ('assign REST Countries to TimeWeatherAgent') and clarifies the environment ('use MCP, not ADK'), which is useful guidance. However, it does not explicitly contrast with alternative tools like create_tool_and_assign_to_agent or state when not to use this tool, so it lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the return shape and implies read-only behavior via 'Get'. However, it omits error behavior, authorization requirements, and whether all fields are returned, which limits transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action, and no wasted words. The structure is efficient and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter getter with no output schema, the description provides a clear scope and return summary. It misses edge cases like not-found errors and the skill/tool naming ambiguity, but is otherwise complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It only says 'by ID', which merely restates the parameter name skill_id. No format, source, or examples are provided, adding little beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and identifies the resource as a 'specific skill/tool by ID', clearly distinguishing it from list_skills. It also states the return content (display name, description, binding), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'specific skill/tool by ID' implies this is for retrieving a single item when the ID is known, contrasting with listing tools. It does not explicitly name alternatives or exclusions, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 disclosing behaviors. It only says 'Runs behind the scenes, no script needed,' but fails to mention side effects, whether it's asynchronous, return format, or error behavior. This is insufficient for a tool that could trigger agent actions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core purpose, and includes a practical example. Every sentence contributes value and there is no verbose or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema and no annotations, the description should provide more behavioral context. It explains how to invoke the tool with parameters and gives an example, but lacks information about response format, execution model, or potential side effects, leaving gaps for an agent to operate safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains that agent_name or agent_id can be used, and gives an example using agent_name and message. This adds meaning beyond the raw schema, though it doesn't clarify precedence when both are provided or the message format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Chat with an agent' using a specific verb and resource, and provides an example ('ask TimeWeatherAgent what the exchange rate is CAD/USD') that illustrates the tool's purpose. This distinguishes it from sibling tools like 'execute_tool' or agent management functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a concrete usage example and clarifies how to use agent_name vs. agent_id, giving clear context for when to invoke this tool. However, it does not explicitly state when not to use it or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool 'Returns accurate count and list from Watson Orchestrate', indicating a read-only operation and data source, and asserts accuracy. It does not mention rate limits or error conditions, which would be useful, but it does cover the most important behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences and front-loads the main purpose immediately. There is some redundancy between 'tools with no connections' and 'tools with empty/missing security and connection_id', and the 'Do not guess' clause is somewhat extraneous, but overall it is efficient and not bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one optional parameter), and the description covers purpose, usage, and data source. However, it never explains the 'limit' parameter or details the return structure beyond a 'count and list'. With no output schema and no annotations, these gaps leave the agent with some uncertainty about how to invoke the tool and interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes a single 'limit' parameter with no description and 0% schema description coverage. The tool description completely ignores this parameter, leaving its meaning ambiguous (e.g., result cap, timeout, or something else). Given the low coverage, the description should have compensated, but it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'standard tools', and immediately defines them as 'tools with no connections', distinguishing it from the sibling tool list_tools_with_connections. The phrase 'only standard tools' reinforces the exclusive scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly tells the agent to use it for 'list standard tools' or 'tools with no connections' and gives the criteria 'empty/missing security and connection_id'. It does not name an alternative for connected tools, but the sibling list_tools_with_connections implies the opposite use case, and 'Do not guess' adds practical guidance.
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 present, so the description carries the transparency burden. It explains the grouping logic and the connection to the extension view, but does not mention read-only status, permissions, or the behavior of the 'limit' parameter. The description is adequate but lacks some behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and includes a useful example. Every word contributes value with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers the essential aspects: purpose, grouping, and usage context. It lacks details about the return format and the limit parameter, but the lack of an output schema and the straightforward nature of a list operation keep it reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines a single optional 'limit' parameter with no description, and the tool description does not mention this parameter at all. With 0% schema coverage, the description fails to explain the parameter's meaning or effect, leaving a meaningful gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: listing Watson Orchestrate tools grouped by connection status, distinguishing between API key/OAuth-requiring tools and standard tools. It also ties to the extension Tools view and provides an example prompt, making it distinct from siblings like list_standard_tools and list_connections.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a concrete usage example ('list my tools with active connections') and mentions matching the extension Tools view, giving clear guidance on when to use it. It doesn't explicitly rule out alternatives, but the context is sufficient.
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 burden of disclosing behavior. It states return contents but does not explicitly mention read-only nature, side effects, or access requirements. Since it's a get operation, the name implies safety, but the description lacks explicit behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that packs the essential purpose and return type. 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter getter with no output schema, the description adequately covers what the tool does and what it returns. It lacks notes on error behavior or prerequisites, but for this low complexity, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies that the sole parameter is the agent's ID ('by ID'), but provides no details on format, source, or validation. This adds some meaning but not enough to fully compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get agent details by ID' with a specific verb and resource. It also lists the returned data (config, assigned tools, instructions, model), distinguishing it from list_agents and other sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying 'by ID', contrasting with list_agents. However, it does not explicitly mention when not to use it or name alternatives, so it falls short of a 5.
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 disclose behavioral traits. While it clarifies identifier and payload usage, it does not mention side effects such as whether the payload merges with or replaces existing agent settings, what happens if both agent_name and agent_id are provided, or whether specific permissions are required. The description only states 'Update an agent' without explaining the update semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, front-loaded with the core action 'Update an agent.' It efficiently packs usage instructions and an example without fluff. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives sufficient context for typical updates, including a realistic example and payload guidance. It does not, however, discuss the response format (no output schema) or edge cases like agent not found, or precedence when both agent_name and agent_id are given. Given the flexible payload (additionalProperties), the description provides a solid baseline, but these gaps prevent a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, so the description carries the full burden. It directly explains all three parameters: agent_name (with a concrete example), agent_id (as an alternative), and payload (with example fields 'instructions, tools, description, etc.' and a full JSON example). This is excellent compensation for the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update an agent' with a specific verb and resource, and gives an example using 'TimeWeatherAgent' to illustrate the target. This distinguishes it from sibling tools like create_agent or delete_agent, and the example clarifies the intended operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: to modify an agent's instructions, tools, description, etc. It explains how to identify the agent (by name or ID) and includes a concrete example for updating instructions. However, it does not explicitly mention when not to use it or name alternatives like update_agent_chat_starter_settings, though the focused example implies general-purpose updates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses a key behavioral trait: returned connection names are deduplicated. It also clarifies the tool excludes tools, going beyond the basic annotation-less requirement. However, it doesn't mention if it's read-only or any other potential side effects, but that's less critical 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but contains redundancy: the second sentence essentially repeats the first ('active and live connections' and 'not the tools'). A more concise version would merge these into a single sentence, making it tighter without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, zero-parameter list tool with no output schema and no annotations, the description adequately covers purpose, scope, and a behavioral trait (deduplication). It doesn't explain return format details, but since it returns names, that's sufficient. It feels complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is 100% with no properties. Per the guidelines, a 0-parameter baseline is 4, and the description doesn't need to explain parameters. It adds no parameter-specific info, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists only active and live connections (not tools), uses a specific verb 'List' with a specific resource, and distinguishes from sibling tools like list_connections and list_tools_with_connections by explicitly excluding tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides an explicit usage example in quotes, indicating when to use it ('list all connections which are active and live'). It does not mention alternatives or when not to use, but the distinction from tools and the qualifier 'only' imply clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It does add useful behavioral context by saying 'Returns accurate tool list from Watson Orchestrate' and notes that display names/descriptions are included 'when available'. However, it does not disclose edge-case behavior (e.g., what happens if the agent is not found, or if both agent_id and agent_name are 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: the first sentence states the primary function, the second provides usage guidance and an example. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with two optional parameters and no output schema, the description covers the core purpose, parameter usage, example query, and expected content of the response. It is not fully exhaustive (e.g., no mention of error conditions or return format), but it is adequate for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage and only lists parameter names, so the description must compensate. It does so by explaining that either agent_name (with a concrete example 'TimeWeatherAgent') or agent_id can be used. It does not specify precedence or behavior when both are supplied, but the core usage semantics are clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb and resource: 'List tools assigned to an agent'. It also distinguishes this from sibling tools like list_standard_tools and list_tools_with_connections by focusing on agent-assigned tools, and it mentions what the response includes (display names and descriptions when available).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage context with the example query 'which tools are assigned to TimeWeatherAgent' and instructs to use either agent_name or agent_id. However, it does not explicitly mention when not to use this tool or name direct alternatives, so it stops short of a 5.
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:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/markusvankempen/wxo-builder-mcp-server'

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