Skip to main content
Glama
watsonx Platform MCP Server

watsonx Platform MCP Server

by manjotsidhu

delete_job

DestructiveIdempotent

Deletes a specified watsonx job by project ID and job ID, using the dedicated endpoint to remove unwanted or completed jobs.

Instructions

Confirmed live: 204, via the dedicated /v2/jobs/{id} path (the generic asset-delete path also works, since jobs are assets, but this uses the dedicated form for clarity).

Input Schema

NameRequiredDescriptionDefault
job_idYes
confirmNo
project_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.1/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description does add one piece of value beyond them: that success yields 204 with no response body, which matters because there is no output schema. However, it says nothing about what gets destroyed (runs, history, dependent assets) or what `confirm=false` actually does.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is a single sentence, but it is front-loaded with an internal verification note ('Confirmed live: 204') rather than the action, and the parenthetical about the generic asset-delete path is irrelevant to an agent choosing or invoking the tool. Little of the text earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a destructive, irreversible operation with two required parameters, an undocumented `confirm` flag defaulting to false, no output schema, and 0% schema coverage. The description addresses none of that — no scope of deletion, no confirm semantics, no error behavior — leaving an agent without what it needs to call it safely.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry all three parameters, and it effectively carries none. The path template '/v2/jobs/{id}' only weakly implies that job_id identifies the job; project_id and the boolean `confirm` (default false) are left entirely unexplained, including whether confirm must be true for deletion to proceed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The text never states a clean verb+resource like 'Delete a job'. It only asserts that a DELETE to /v2/jobs/{id} returned 204, from which an agent must infer the purpose. It also makes no attempt to distinguish this from siblings such as cancel_job_run, update_job, or the generic asset-delete path it mentions.

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 one usage-adjacent remark is that the generic asset-delete path 'also works' but this dedicated form is used 'for clarity' — an implementation aside, not guidance for an agent about when to call delete_job versus cancel_job_run or delete_project. No preconditions, no irreversibility warning, no confirmation guidance despite a `confirm` parameter.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.