IBM watsonx.data MCP Server

Official

by IBM

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

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

Latest release: v0.1.4
Disambiguation5/5
Each tool targets a distinct action and resource. Even though there are many engine-specific tools (e.g., create_presto_engine vs create_prestissimo_engine), the tool names and descriptions clearly differentiate them. Overlapping concepts like pause/resume are separated by engine type, making selection unambiguous.
Naming Consistency4/5
Most tools follow a verb_noun pattern (create_schema, list_engines, execute_select). There is slight inconsistency: 'get' vs 'list' for retrieval tools (e.g., get_instance_details vs list_engines), and 'describe_table' uses 'describe' instead of a more uniform prefix. Overall, the convention is predictable.
Tool Count3/5
With 39 tools, the set is on the higher side. Many tools are redundant because they duplicate the same operations for different engine types (Presto, Prestissimo, Spark). While each tool serves a purpose, the count feels heavy for a typical MCP server, bordering on excessive.
Completeness2/5
Several lifecycle operations are missing: no tool to delete engines, schemas, or tables, and no create_table tool exists. Additionally, there is no way to list catalogs, which are referenced in many operations. These gaps would cause agent failures when trying to perform basic data management tasks.
Average 3.8/5 across 39 of 39 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 9 commits in the last 12 weeks
- Last stable release on May 18, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'Restart' without explaining side effects (e.g., impact on running queries, permissions required, or whether restart is graceful). This is insufficient for a mutation operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (2 lines) but includes a docstring structure (Args, Returns) that is acceptable though not necessary. It is not verbose, but the lack of essential information makes it merely adequate in length.
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 (1 required param, no annotations, sibling tools with similar actions), the description is incomplete. It does not mention potential outcomes, error conditions, or any context beyond the basic restart intent. An output schema exists but is not utilized in description.
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?
With 0% schema description coverage, the description should compensate. It merely restates 'engine_id: Engine identifier', adding no meaning beyond the schema's string type and required flag. No format, constraints, or examples are given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Restart a Presto engine in watsonx.data', which is a specific verb (restart) and resource (Presto engine). It clearly distinguishes from sibling tools like restart_prestissimo_engine, pause_presto_engine, etc.
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 restart vs alternatives (e.g., pause/resume) or any prerequisites. It lacks any context about conditions or preferred use cases, failing to help the agent decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behavioral traits. It only states 'Cancel' and returns a dict, but fails to mention idempotency, what happens if job is already finished, or permission requirements. This is insufficient for safe invocation.
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 and follows a standard Args/Returns structure, but it omits necessary context, making it too sparse. It is concise but at the cost of completeness.
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 lack of annotations and the presence of an output schema, the description could be more complete. It does not address error states, preconditions (e.g., job must be active), or side effects. The tool requires more context for safe use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description for 'job_id' ('Job identifier') adds minimal meaning beyond the schema, which has 0% description coverage. It does not clarify format, source, or constraints, so the parameter is poorly documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool cancels a data ingestion job, using a specific verb and resource. It distinguishes from sibling tools like create_ingestion_job and list_ingestion_jobs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives, nor any preconditions or exclusions. The description only states the action, leaving the agent to infer usage context from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It simply says 'Restart' without explaining side effects (e.g., downtime, state transitions), required permissions, or response details. This is minimal for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, with three concise sections: purpose, args, returns. It is front-loaded with the key action. However, the brevity limits content; it earns a 4 for efficiency but not a 5 due to lack of depth.
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 (a restart operation requiring state awareness) and absence of output schema details beyond field names, the description is incomplete. It lacks prerequisites, error information, and behavioral context, leaving gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description only adds 'Engine identifier' for engine_id. This clarifies the parameter's role but provides no format, constraints, or context. The addition is minimal, not compensating fully 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 'Restart' and the resource 'Prestissimo engine' in watsonx.data, distinguishing it from sibling 'restart_presto_engine' by engine type. It uses a specific verb and resource, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like restart_presto_engine, pause/resume, or scale. It does not specify prerequisites (e.g., engine state) or exclude any scenarios, leaving the agent to infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It states the tool resumes a paused engine and returns a status dict, but omits safety (e.g., is it destructive?), authorization needs, or consequences of resuming an already running engine.
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 and well-structured with separate Args and Returns sections. However, it could be slightly more compact without losing clarity.
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 (1 parameter) and presence of an output schema, the description covers the core function and return value. However, it lacks mention of preconditions (e.g., engine must exist and be paused), error states, or side effects.
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 single parameter engine_id is described only with 'Engine identifier', which adds virtually no meaning beyond its name in the schema. Schema coverage is 0% because the description fails to elaborate on format, constraints, or examples.
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 (Resume), the resource (a paused Presto engine), and the domain (watsonx.data). It effectively distinguishes from sibling tools like pause_presto_engine and resume_prestissimo_engine.
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 explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites (e.g., engine must be paused). The only implied usage is from the verb 'resume' and the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavioral traits. It mentions pausing and returning status/state transition, but does not disclose side effects (e.g., on running queries), reversibility, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose, followed by docstring-style args and returns. It is reasonably concise but could be shorter by removing 'Args:' and 'Returns:' boilerplate since these are contextually implied.
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 one parameter, no annotations, and presence of an output schema, the description covers the basic operation and return value. However, it lacks guidance on when to pause and what happens to the engine state afterward, which is needed for complete context.
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?
Only one parameter (engine_id) with minimal description ('Engine identifier'). Schema description coverage is 0%, and the description adds no details on format, source, or validation rules.
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 ('Pause') and the resource ('running Prestissimo engine in watsonx.data'), and distinguishes from sibling tools like pause_presto_engine and pause_spark_engine by specifying the engine type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, such as pause_presto_engine or pause_spark_engine, nor any prerequisites or consequences of pausing. The description only implies usage through the name.
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 cover behavioral traits. It describes creation and return type but lacks details on side effects, authorization requirements, or consequences. Basic 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 structured with Args and Returns, front-loaded with the purpose sentence. It is clear but not overly concise; each sentence adds information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters and no annotations, the description covers basics but lacks prerequisites, error conditions, or dependencies. An output schema exists but does not fully compensate for missing context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must add meaning. It provides brief descriptions for each parameter (e.g., origin values), adding value beyond the schema. However, some descriptions are obvious (e.g., display_name).
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 new Spark engine in watsonx.data.' It uses a specific verb ('create') and resource ('Spark engine'), and distinguishes it from sibling tools like create_presto_engine.
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 lists parameters including origin types but gives no guidance on when to use this tool versus alternatives like create_presto_engine or when not to use it. No explicit when-to-use or when-not-to-use information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates it is a read-only status retrieval, but with no annotations, it does not cover behavioral aspects like idempotency, side effects, or required permissions. The description is minimal but sufficient to infer non-destructive nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the main purpose. The Args/Returns format is efficient, though it could be condensed into a single prose sentence without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to detail return values. However, it lacks information about error handling, timeouts, or permissions. The description is adequate for a simple retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'job_id' is described merely as 'Job identifier' with no additional context on format, constraints, or examples. Since schema description coverage is 0%, the description adds little value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 'detailed status of a data ingestion job', specifying a concrete verb and resource. It distinguishes the tool from siblings like list_ingestion_jobs and cancel_ingestion_job.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as list_ingestion_jobs. No prerequisites, context, or when-not-to-use information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states the return type (dict with applications list) but omits details like pagination behavior, required permissions, error conditions, or whether the list is complete. The limit parameter hint is helpful but insufficient for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear structure separating purpose, arguments, and returns. No redundant sentences, though the 'Args:' format is slightly verbose. It could be shorter, but remains 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?
Given the lack of annotations and no output schema provided, the description partially compensates by mentioning the return value. However, it does not cover pagination, error handling, or prerequisites. For a list endpoint, this is a moderate gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description effectively documents all three parameters. It provides examples for state, and for limit it gives a range and a recommendation. engine_id is described as 'Spark engine identifier', which adds minimal but sufficient context beyond the schema type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists Spark applications on a Spark engine. This distinguishes it from siblings like get_spark_application_status (for a single app) and submit_spark_application. However, it could be more specific about the scope (e.g., whether it returns all applications or those belonging to the caller).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case (listing applications) and includes a recommendation for limit to avoid token exhaustion. However, it does not explicitly state when not to use this tool or differentiate it from alternatives like get_spark_application_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only mentions 'pause' and 'state transition', but does not disclose any side effects, permissions needed, or whether the operation is reversible. For a mutation tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences: a clear title, then structured Args and Returns. It is front-loaded and efficient, though the Args/Returns section is somewhat redundant with the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter, no annotations, and an existing output schema, the description covers basic input and output. However, it lacks behavioral context like preconditions (engine must be running) and consequences, leaving gaps for safe usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description lists the parameter name (engine_id) in Args but adds no additional meaning beyond the schema's type string. Schema description coverage is 0%, so the description should compensate, but it does not provide format, examples, or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Pause' and the resource 'running Presto engine', verb+resource is specific. It distinguishes from sibling tools like pause_prestissimo_engine and pause_spark_engine.
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 there is a running Presto engine, but does not explicitly state when to use this tool versus alternatives like pause_prestissimo_engine. No when-not-to-use or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states basic action and return type. Missing details on side effects (e.g., idempotency, state changes, prerequisites, error conditions). Minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, but includes 'Args:' and 'Returns:' which add minimal value. Could be streamlined into one sentence without losing clarity.
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 one parameter and no annotations, description is adequate for a simple resume operation but lacks mention of permissions, error handling, or prerequisites for the engine to exist and be paused.
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%; description merely repeats 'engine_id: Engine identifier' without adding meaning beyond the schema. Does not explain how to obtain or validate the identifier.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Resume a paused Spark engine in watsonx.data (SAAS only)', specifying exact verb and resource with scope limitation. Distinguishes from sibling tools like pause_spark_engine and resume_presto_engine.
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?
Description implies usage context (when engine is paused) but lacks explicit when-not-to-use guidance or comparisons to alternative resume tools. No exclusions or prerequisites stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fails to disclose side effects, required permissions, or behavior when the engine is not paused. The return value mentions status and state transition but lacks detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, direct, and well-structured with clear Args and Returns sections, making it 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?
Given the simple operation and presence of an output schema, the description sufficiently covers the core functionality and return value, though it omits error conditions and prerequisite state checks.
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 includes an Args section that labels 'engine_id' as 'Engine identifier', which adds basic meaning beyond the schema's type-only definition, but no further constraints or formatting details are provided.
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 'Resume' and the resource 'paused Prestissimo engine', and it distinguishes from sibling tools like pause_prestissimo_engine and resume_presto_engine.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives such as resume_presto_engine or resume_spark_engine, nor are any prerequisites or conditions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It mentions that engine_restart set to 'force' triggers a restart, which is helpful, but it does not disclose whether the update is reversible, whether it disrupts running queries, or if specific permissions are required. The description is partially transparent but lacks important 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured as a concise Args/Returns docstring with minimal redundancy. Each parameter is listed on a separate line, and the return value is briefly described. It is front-loaded with the main purpose, but the line breaks could be tighter for better readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema (as per context), and the description mentions that the return is a dict with updated engine configuration, which is sufficient. However, for 7 parameters, the description does not cover error conditions, prerequisites (e.g., engine must exist), or implications of property changes. It is moderately complete but has gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists all 7 parameters with brief explanations (e.g., 'engine_restart: Set to "force" to trigger restart after update'), but the explanations are mostly repetitions of parameter names (e.g., 'engine_properties: Engine configuration properties'). The description adds some value but is not sufficiently detailed for parameters like engine_properties or remove_engine_properties.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Update Presto engine configuration in watsonx.data', which clearly identifies the verb (update), resource (Presto engine), and domain. It distinguishes from sibling tools like update_prestissimo_engine and update_spark_engine by specifying 'Presto'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a list of parameters but does not explicitly state when to use this tool versus alternatives like update_prestissimo_engine or update_spark_engine. It implies usage via the engine type in the name, but no direct guidance on prerequisites or scenarios where this tool is preferred.
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 cover behavioral aspects. However, it only lists parameters and a brief return type. It does not disclose important behaviors like whether the job starts immediately, is idempotent, requires permissions, or has side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a purpose statement and then an organized Args block. While it is lengthy due to 20 parameters, it is well-structured and all information is relevant. Minor deduction for verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 20 parameters and no annotations, the description covers parameter details and return type. However, it lacks explanation of the overall process, error conditions, or output schema details. It is moderately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully documents parameters. Each parameter includes explanation, default value, and format examples (e.g., 'e.g., s3://bucket-name/file.csv'). This significantly adds meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create a data ingestion job to load data into watsonx.data.' It uses a specific verb (create) and resource (data ingestion job) with context (watsonx.data). This clearly distinguishes from sibling tools like cancel_ingestion_job or get_ingestion_job.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives, such as other data loading or spark submission tools. It lacks context about prerequisites, ideal scenarios, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It explains the return value as 'Dict with engine_id, engine_type, statement, analysis, and full response', which is transparent. However, it does not explicitly state that the tool is read-only, its safety profile, or any potential side effects. The mention of query failure hints at error handling but is incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a concise opening sentence followed by a clear arg/return format. It is front-loaded with the purpose. While the arg details are necessary, they add some length; still, every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's inputs, outputs, and a troubleshooting tip. Given the absence of annotations and the need to explain 4 parameters with 0% schema coverage, it is mostly complete. It could further clarify if the tool has any side effects or is purely analytical, but this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds meaningful context to all parameters: engine_id ('Presto or Prestissimo engine identifier'), statement (with troubleshooting tip), engine_type (values and default), and verbose ('Include detailed statistics'). This goes well beyond the minimal schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get detailed query analysis with execution statistics'. It identifies the resource (query analysis) and the action. However, it does not explicitly distinguish from the sibling 'explain_query' tool, which likely has a similar but possibly less detailed purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a helpful usage tip: 'If query fails, consider using fully qualified table names (catalog.schema.table)'. But it lacks guidance on when to use this tool versus alternatives like 'explain_query', and does not specify any prerequisites or contexts where the tool is most appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It fails to mention potential side effects (e.g., impact on references), required permissions, or whether the operation is reversible. It only states the action and return type.
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 and front-loaded with the one-line purpose. The Args and Returns sections are structured and efficient, though some parameter details could be more compact.
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 5 required parameters and no provided output schema, the description covers basics but omits context like error handling or prerequisites (e.g., engine availability). It does reference 'list_engines' for the engine_id, which adds useful context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds essential meaning by listing each parameter and providing examples (e.g., 'catalog_name: Catalog containing the table (e.g., "iceberg_data")'). This compensates well 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 'Rename a table in a watsonx.data schema.' It uses a specific verb (rename) and resource (table), distinguishing it from sibling tools like 'rename_column' and other table operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by describing the operation, but it lacks explicit guidance on when to use this tool over alternatives (e.g., for renaming vs. other table modifications). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes the return structure in detail but does not disclose behavioral traits such as read-only nature, side effects, error conditions, or authentication needs. The tool is likely read-only, but this is not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args and Returns sections, front-loading the purpose. It is appropriately detailed without being overly verbose; each sentence adds value. Minor redundancy in the Returns section echoing inputs, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not fully shown), the description covers return values comprehensively, including column details. However, it lacks information on error scenarios, required permissions, or edge cases. For a describe tool, this is adequate but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description adds meaning beyond parameter names by providing examples and sources (e.g., 'catalog_name: Catalog containing the table (e.g., "iceberg_data", "tpch")'). This significantly aids parameter understanding, though format or constraints could be more precise.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get detailed schema and metadata for a watsonx.data table', which is a specific verb+resource combination. It distinguishes itself from sibling tools like list_tables (which lists table names) and other schema-related tools.
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 by referencing other tools as parameter sources (e.g., 'from list_schemas', 'from list_tables', 'from list_engines'), but it does not explicitly state when to use this tool vs alternatives like list_tables or get_instance_details. No when-not or exclusion guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It describes the return value structure, indicating a read-like operation, but does not explicitly state idempotency, error handling, or side effects. The description adds moderate transparency but leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using a two-line summary followed by structured Args and Returns sections. Every sentence provides necessary information without redundancy. No extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (list schemas), the description covers the key aspects: purpose, parameters with examples, and return structure. The output schema is described, so return values are clear. Missing details like error conditions or permission requirements are minor for a read-only listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for parameters. The description compensates by explaining catalog_name with examples ('iceberg_data', 'hive_data', 'tpch') and noting engine_id's source (list_engines). This adds significant meaning beyond the raw schema, though no validation constraints are mentioned.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List database schemas in a watsonx.data catalog,' specifying the verb (list) and resource (schemas). It provides parameter examples that reinforce the purpose. However, it does not explicitly differentiate this tool from siblings like list_tables or create_schema, though the action is distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes Args with examples and notes that engine_id comes from list_engines, implying a dependency. It does not provide explicit guidance on when to use this tool vs alternatives (e.g., describe_table, list_tables) or when not to use it. The usage context is implied but not fully defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains the force parameter's effect but does not disclose what happens to existing applications if not forced, whether the operation is reversible, or any authentication requirements. Lacks depth on 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 three sentences with a structured Args list. It is front-loaded with the main action and is entirely concise with no redundant 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?
Given the simple two-parameter tool, the description covers the action and parameters adequately but lacks detail on return value structure (only 'Dict with pause operation status') and prerequisites (e.g., engine must be running). Not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It defines engine_id as 'Engine identifier' and force as 'Force pause even if applications are running (default: False)', which adds context beyond type/default, though it could specify the format of engine_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Pause), the resource (running Spark engine), and the context (watsonx.data SAAS only). It differentiates from sibling tools like pause_presto_engine and pause_prestissimo_engine by specifying 'Spark engine'.
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 mentions 'SAAS only' as a usage constraint, but does not provide guidance on when to use pause versus stop or resume, nor when to set force=True. No explicit alternatives or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It details configuration options and constraints (e.g., engine_id pattern, description length), but does not disclose side effects (e.g., permissions needed, cost, idempotency, or conflict handling). Lacks information about the creation process length or error scenarios.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (example payload, args, autoscaling, predefined configs, returns). It is somewhat lengthy but organized, and the key information is front-loaded. Some redundancy exists between the example and the parameter descriptions, but overall it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested objects, many optional fields), the description covers configuration details, autoscaling, predefined sizes, and return value. It includes constraints and examples. However, it lacks information on error handling, validation behavior, and does not mention that engine names must be unique or that certain configurations may fail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It thoroughly explains each parameter, including required/optional status, types, nested structures (e.g., configuration with coordinator/worker/autoscaling), constraints (e.g., min/max quantities), and provides an example payload. The autoscaling section details all fields. This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new Presto engine in watsonx.data.' It provides specific verb and resource, and the details (predefined configs, autoscaling) align with Presto engine creation. While it doesn't explicitly compare with sibling tools (e.g., create_prestissimo_engine), the tool name and context make 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like create_spark_engine or create_prestissimo_engine. It does not include prerequisites, limitations, or when not to use. The description focuses on the 'how' but not the 'when'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must address behavioral traits. It describes the operation and return value but does not disclose side effects, permissions needed, reversibility, or error conditions. It implies a rename but lacks detail on what happens to dependent objects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args and Returns sections, using clear parameter names and brief explanations. Every sentence adds value, and the format is easy to parse for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple operation and presence of an output schema (not shown), the description adequately covers the task. It specifies required parameters and the return type. However, it could add more detail on validation or failure cases.
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 compensates by listing parameters with examples (e.g., catalog_name: 'iceberg_data') and linking engine_id to list_engines. However, it does not explain constraints on new_column_name or behavior if column doesn't exist.
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 operation: 'Rename a column in a table in a watsonx.data schema.' The verb 'rename' and resource 'column' are specific. It distinguishes from sibling 'rename_table' which renames a table, and other table/column operations like 'add_columns'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use or not use this tool. There is no mention of prerequisites, alternatives, or contexts where renaming might be inappropriate. The description only lists parameters without 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?
No annotations provided. Description does not disclose side effects, blocking behavior, authentication requirements beyond examples, or rate limits. Lacks disclosure of potential errors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with Args, Returns, Examples, and Optional params sections. Slightly verbose but justified by complexity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all 11 parameters, provides return type, and includes examples. Lacks error handling or state change details, but adequate for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description excellently explains each parameter's purpose and format, including examples for conf, volumes structure, and name auto-injection into conf.
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?
Clear verb+resource: 'Submit a Spark application for execution on a Spark engine.' Distinguishes from sibling tools like get_spark_application_status or stop_spark_application.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides examples for common configurations (COS, S3A) but does not explicitly state when to use this tool versus alternatives or prerequisites. No when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions the return type (dict) and the need for manual restart, but lacks details on permissions, failure modes, or side effects beyond the note.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args, Returns, and Note sections. It is not overly verbose, and each sentence contributes useful 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?
Given the presence of an output schema and moderate parameter count, the description covers purpose, basic parameter roles, and a behavioral note. However, it lacks information on error conditions, validation rules, or relationship to other engine operations.
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 compensates with brief parameter descriptions (e.g., 'Updated display name', 'Engine configuration (default_config, default_version, engine_home)'). These add value but are minimal and lack details on constraints or defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update Spark engine configuration in watsonx.data,' specifying the verb and resource. It distinguishes from sibling tools like create_spark_engine and scale_spark_engine by focusing on configuration updates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a note about Spark engines not supporting engine_restart and that configuration changes may require manual restart. This provides useful guidance but does not explicitly compare to other update tools like update_presto_engine.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes the return value and data type guidance, but does not disclose potential side effects or authorization needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with Args and Returns sections and a note. It is concise but could be slightly tighter.
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 5 required params and no annotations, the description covers all parameters and return value. It lacks prerequisites or error conditions, but is adequate for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It explains each parameter: catalog_name, schema_name, table_name, columns (including sub-fields), engine_id, adding meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add one or more columns to a table in a watsonx.data schema' with a specific verb and resource. It distinguishes from sibling tools like rename_column and rename_table.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a hint about data type casing but does not explicitly state when to use this tool vs alternatives. Sibling tools include other table modifications, but no cross-references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It states the tool does not run the query, which is key, and outlines return values. However, it does not specify permissions, error conditions, or confirm it is read-only, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. The first line gives the core purpose, followed by clearly formatted Args and Returns sections. No unnecessary words, and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no annotations, and an output schema, the description is fairly complete. It covers all parameters and the return dict structure. Minor omission: possible error cases or preconditions are not addressed, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates fully. Each parameter is described in the Args section: engine_id is an identifier, statement is the SQL with a tip for failure, and engine_type, format, type have enums explained. This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get query execution plan without running the query', which is a specific verb and resource. It distinguishes from running actual queries and is actionable. While siblings like 'explain_analyze_query' exist, the purpose of obtaining a plan without execution is clear and unique.
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 a troubleshooting tip for failed queries but lacks explicit guidance on when to use this tool versus alternatives like 'explain_analyze_query'. No exclusions or prerequisites are mentioned, limiting its utility for tool selection.
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 return structure (engines list and summary) but does not mention side effects, authorization, rate limits, or performance characteristics. It does not contradict structured data but lacks behavioral depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured as a short paragraph with args and returns sections. It is front-loaded and each sentence adds value. Slightly verbose but clear and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single optional parameter and presence of output schema (though described in text), the description covers the tool's purpose and return format. It lacks mention of paging or instance scope, but is complete for a straightforward list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description compensates well by explaining the parameter engine_type with specific values ('presto', 'prestissimo', 'spark', or None) and its effect. Also documents the return structure, adding value beyond the minimal schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists available Presto, Prestissimo, and Spark compute engines in watsonx.data. It uses specific verbs and resources ('List available ... engines') and distinguishes from sibling tools that create, pause, or scale engines.
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 by showing an optional filter but does not explicitly state when to use this tool versus alternatives like list_schemas or list_tables. No when-not-to-use or alternative suggestions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses asynchronous nature (202 Accepted) and SAAS-only constraint, but does not detail side effects like downtime or whether scaling is incremental or requires a restart.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise with a clear structure: summary line, parameter list, return description. No extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers input, effect, and return. Lacks preconditions or error scenarios, but sufficient for a simple scaling tool given the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaning beyond schema by specifying node count range (1-1000) and clarifying that engine_id is an identifier, compensating for 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?
Description clearly states the action (scale) and resource (Spark engine) with the specific constraint of SAAS only, which differentiates it from sibling tools that scale other engine types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use scale versus other operations like pause or resume, and no mention of prerequisites or if the engine must be running.
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 accurately conveys that this is a read-only retrieval tool by using 'Get detailed status' and listing return fields. However, it does not mention side effects, authorization requirements, or error conditions, but the read nature is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args and Returns sections, front-loading the purpose and providing details in a clean format. It is appropriately concise without unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with an output schema, the description fully covers the return value fields and parameter meanings. It is complete for an agent to understand the tool's input and output without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining each parameter: 'engine_id: Spark engine identifier' and 'application_id: Application identifier', adding context beyond the raw property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Get detailed status of a Spark application', using a strong verb and specifying the resource. This clearly distinguishes it from sibling tools like list_spark_applications (which lists all) and submit_spark_application (which creates).
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_spark_applications for listing or explain_query for analysis. There are no prerequisites, exclusions, or context hints beyond the basic purpose.
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 pagination behavior (start and limit parameters) but does not mention read-only nature, rate limits, idempotency, or potential cost implications. The description is adequate but lacks deeper behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear front-loaded purpose, followed by structured Args and Returns sections. Every sentence provides essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists (not provided but referenced), the description is largely complete for a list tool. It explains pagination and return structure, but could mention sorting or filtering possibilities, though these are not required for basic completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description clearly explains both parameters: start (offset, 0-based, default 0) and limit (number per page, default 10, max 100, -1 for all). This adds substantial meaning beyond the basic type information in 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 explicitly states 'List data ingestion jobs on watsonx.data' using a specific verb (list) and resource (ingestion jobs). It clearly distinguishes from sibling tools like get_ingestion_job (single job), cancel_ingestion_job, and create_ingestion_job.
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 ingestion jobs with pagination, but does not provide explicit guidance on when to use this tool versus alternatives like get_ingestion_job for single job retrieval. No exclusion criteria or context for pagination parameters are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden. It clearly lists the return fields (instance_id, region, status, version, etc.), indicating a safe read operation. No side effects are mentioned, but that's expected. It could mention error conditions or prerequisites, but the provided detail is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is front-loaded with the main purpose in the first sentence, followed by a structured list of return fields. It is concise and easy to scan, though it could be slightly more compact by using a table or bullet list.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no complex behavior), the description fully covers the returned information and purpose. It lists all relevant fields, and with the output schema presumably available, it is complete enough for an agent to understand and invoke correctly.
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?
Tool has zero parameters, and the description implicitly confirms this by stating it returns instance details without any input. Baseline for 0 parameters is 4, and no additional parameter info is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it retrieves watsonx.data instance information including status, version, region, and enabled features. It uses specific verb 'Get' and resource 'instance information', and distinguishes itself from sibling tools which focus on engines, ingestion, schemas, etc.
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?
Description does not provide explicit guidance on when to use this tool versus alternatives. While the context implies it's for instance-level info, no exclusions or alternatives are mentioned. Sibling tools are other getters/lists, but the description lacks usage 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?
No annotations are provided, so the description bears the full burden. It states termination and removal from engine history, which is helpful. However, it lacks details on irreversibility, permission requirements, or impact on running queries. For a tool with no annotations, it provides basic but not comprehensive behavior info.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a single-line summary, followed by structured Args and Returns sections. Every sentence adds value with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (stop a spark app), and the description covers purpose, parameters, and return format. It mentions removal from history, which is a key behavioral detail. Given the presence of an output schema, it is fairly complete, though it could mention prerequisites like the engine existing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It does so by clearly explaining each parameter: engine_id as 'Spark engine identifier' and application_id as 'Application identifier to stop', adding semantic meaning beyond the property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Stop and remove a Spark application,' which clearly identifies the verb and resource. It distinguishes itself from sibling tools like submit_spark_application, get_spark_application_status, and list_spark_applications.
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 clearly states the action (stop and remove) but does not explicitly mention when to use this tool versus alternatives or when not to use it. However, the purpose is clear, and the sibling list indicates this is the only tool for stopping a Spark application.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It describes the creation operation, required parameters, configuration constraints (e.g., node types, quantities), and returns engine details. It does not cover auth requirements or rate limits, but provides extensive behavioral context about allowed values and recommendations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening line, example payload, parameter descriptions, and detailed sections for custom/predefined configs. It is front-loaded but somewhat verbose; however, the length is justified by the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, nested objects, many options), no annotations, and schema coverage 0%, the description is very complete. It covers all parameters, required vs optional, recommended practices, config options, and return format. No major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It does so thoroughly by explaining each parameter, providing an example payload, detailing configuration subfields (size_config, coordinator, worker), defining constraints (e.g., description max 50 chars, engine_id pattern), and differentiating custom vs predefined setups.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Create a new Prestissimo engine in watsonx.data.' which is a clear verb+resource statement. The name and context differentiate from siblings like create_presto_engine.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives (e.g., create_presto_engine). The name implies the engine type, but the description does not provide usage context or when-not-to-use. The detailed configuration instructions imply usage for custom setups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses read-only behavior and notes that high limits consume more tokens. It also details return format. However, it does not mention error handling or performance constraints beyond token usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args and Returns sections, concise yet informative. Every sentence adds value, and it avoids redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the parameter count and presence of output schema, the description covers all inputs and return values comprehensively. Minor omission: no mention of potential errors or query execution async nature, but overall sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description thoroughly explains each parameter: sql must start with SELECT, catalog_name provides examples, schema_name as default, engine_id from list_engines and must be running, and limit with default behavior. This compensates fully 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 it executes read-only SELECT queries against watsonx.data, specifying the verb (execute) and resource (SELECT queries on watsonx.data). This distinguishes it from sibling tools like execute_insert or execute_update, which perform different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for read-only queries but does not explicitly state when to use this tool versus alternatives like execute_insert, execute_update, or explain_query. No guidance on when-not or comparisons with siblings is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It details the return dict and notes Iceberg table update limitations (format version 2, merge-on-read mode). However, it does not mention side effects, permission requirements, or handling of failed updates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections (Args, Returns, Note) and uses clear bullet points. It is somewhat verbose but every sentence adds value, especially the Iceberg note. Could be slightly more concise but effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (though not detailed here) and the complexity of UPDATE operations, the description is comprehensive. It covers the return values, input parameters, and a specific configuration note for Iceberg tables. Lacks error handling or concurrency context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% with no parameter descriptions in the input schema. The description adds substantial meaning: sql must start with UPDATE, catalog_name examples, schema_name as default schema, engine_id from list_engines. This compensates well 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 it executes UPDATE queries against watsonx.data, with a specific verb and resource. It distinguishes from sibling tools like execute_insert and execute_select by focusing on UPDATE operations and requiring SQL to start with UPDATE.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies when to use the tool (for UPDATE queries) and provides prerequisites like the engine must be running and obtained from list_engines. While it doesn't explicitly mention alternatives, the sibling list makes it clear. No explicit when-not-to-use guidance is given.
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 takes full responsibility for behavioral disclosure. It details constraints, required parameters, and raises error conditions (e.g., engine type, catalog type, empty custom_path). Returns section clarifies output. However, it does not mention side effects (e.g., whether schema creation is immediately visible).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections (IMPORTANT RESTRICTIONS, Args, Returns, Raises). While detailed, it avoids unnecessary verbosity; each sentence serves a purpose. Could be slightly more concise, but structure aids readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description adequately covers return values. It includes parameter dependencies, error conditions, and usage guidelines. No apparent gaps in information for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains each parameter in an Args section beyond the input schema, which has 0% coverage. It clarifies requirements for custom_path ('must be at least 1 character') and storage_name ('REQUIRED for object storage catalogs'), adding essential context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new schema in a watsonx.data catalog,' specifying the action and resource. This distinguishes it from sibling tools like list_schemas or create_ingestion_job.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit restrictions on engine type and catalog type, guiding when this tool is appropriate. It does not explicitly mention when not to use it, but the restrictions effectively serve as usage 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 provided, so the description carries the full burden. It details the return structure (query_id, rows_inserted, etc.) and constraints (SQL must start with INSERT, engine must be running), but does not mention that INSERT modifies data 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 well-structured with sections and bullet points, each sentence adding value without redundancy. It is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description fully covers return values. All four required parameters are explained, and the tool's role among 39 siblings is clear. The description provides sufficient information for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description fully compensates by explaining each parameter: sql expects an INSERT query, catalog_name with examples, schema_name as default for unqualified names, and engine_id sourced from list_engines and must be running.
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 executes INSERT queries against watsonx.data and specifies that the SQL must start with INSERT, distinguishing it from siblings like execute_select or execute_update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains parameters including the requirement that engine_id must come from list_engines and be in a running state. While it doesn't explicitly contrast with alternatives, the 'must start with INSERT' implies the appropriate use case.
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?
Since no annotations are provided, the description carries the full burden. It details the return format (tables list, total_count, echo) and notes parameter sources. It does not explicitly state read-only, but it is implied by 'List tables'. Good for a listing operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose sentence and separate Args/Returns sections. It is informative without being verbose, though minor trimming could make it more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema covering return values, the description is complete for a list tool. It covers purpose, parameter sources, and return format. Could mention pagination or limits, but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% with no parameter descriptions. The description compensates by providing examples for catalog_name and noting that schema_name and engine_id come from other tool outputs, adding significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The purpose is clearly stated: 'List tables in a watsonx.data schema.' The verb 'list' and resource 'tables' are specific, and the scope 'in a schema' distinguishes it from siblings like describe_table and list_schemas.
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 usage context by noting that schema_name comes from list_schemas and engine_id from list_engines, implying a workflow. However, it does not explicitly state when not to use or suggest 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?
No annotations are provided, so the description carries the full burden. It discloses a known API limitation (description cannot be updated alone) and notes that setting restart_type to 'force' triggers a restart. It does not detail other behaviors like auth needs, idempotency, or error states.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: an opening sentence, an important warning, and a bullet-like Args list. It is slightly repetitive as the warning about description needing an additional field appears both in the main text and in the parameter description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool complexity (7 params, 1 required, a known limitation) and the presence of an output schema, the description covers the limitation, all parameters, and the return type. It lacks details on update semantics (merge vs replace) and potential errors, but is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It lists each parameter with a clear explanation, including constraints (e.g., description length 1-50) and behavioral notes (e.g., restart_type triggers restart). This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates Prestissimo engine configuration in watsonx.data. The sibling list includes update_presto_engine and update_spark_engine, so the agent can differentiate by the engine type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool (updating engine config) and includes a critical warning about the description field limitation. However, it does not explicitly state when not to use or suggest 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?
No annotations are provided, so the description carries the full burden. It discloses key behaviors: coordinator quantity fixed at 1, worker range, node types can be changed, and both configurations must be provided. This adds value beyond the input schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for recommendations, capabilities, API requirements, and parameter details. It is slightly verbose but every sentence provides useful information, with the main action front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 required parameters and an output schema, the description covers all parameters, explains return values, and addresses potential edge cases (e.g., node type changes, different types for coordinator and worker). It is complete for the complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description explains each parameter thoroughly, including constraints (e.g., coordinator_quantity must be 1, worker_quantity recommended 1-18), typical values, and how parameters interact. This fully compensates 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 action: 'Scale a Prestissimo engine by adjusting coordinator and worker node counts'. It specifies the resource (Prestissimo engine) and the specific adjustments, distinguishing it from siblings like scale_presto_engine and scale_spark_engine.
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 guidelines: recommended node types, scaling capabilities (coordinator always 1, worker 1-18), note that node types can be changed, and requirement to provide both configurations. It does not explicitly state when not to use this tool versus alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully discloses critical behaviors: coordinator quantity fixed at 1, worker range 1-50, node types can be changed, coordinator and worker can have different types. No ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with bullet points and sections. Slightly verbose but every sentence adds value. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, no annotations, output schema present), the description covers all necessary information: purpose, constraints, ranges, requirements. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but description's Args block explains each parameter with constraints (e.g., coordinator_quantity must be 1, worker_quantity 1-18 recommended). Adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it scales a Presto engine by adjusting node counts in watsonx.data. The specific verb 'scale' and resource 'Presto engine' distinguish it from sibling tools like scale_prestissimo_engine and scale_spark_engine.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidelines: recommended node types, scaling capabilities, requirement to provide both coordinator and worker configurations. Does not explicitly mention when not to use or compare with alternatives, but the context is sufficiently clear.
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:

[![ibm-watsonxdata-mcp-server MCP server](https://glama.ai/mcp/servers/IBM/ibm-watsonxdata-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/IBM/ibm-watsonxdata-mcp-server)

Score Badge

Copy to your README.md:

[![ibm-watsonxdata-mcp-server MCP server](https://glama.ai/mcp/servers/IBM/ibm-watsonxdata-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/IBM/ibm-watsonxdata-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/IBM/ibm-watsonxdata-mcp-server'

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