Updates a specific ZenML resource by its UUID using an allowlisted payload for models, projects, artifacts, or components.
Update one exact UUID through an allowlisted operation-specific payload.
| Name | Required | Description | Default |
|---|---|---|---|
| payload | No | ||
| model_id | No | ||
| project_id | No | ||
| artifact_id | No | ||
| resource_id | Yes | ||
| resource_type | Yes | ||
| component_type | No |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v2.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so the mutation profile is known. The description adds context by emphasizing 'one exact UUID' and an 'allowlisted operation-specific payload,' which suggests constrained, targeted updates. It does not explain permissions, side effects, or failure behavior, but the annotation coverage lowers the burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. Every word adds some meaning, and it is appropriately sized for a tool definition that relies on structured schema/annotations for the rest.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a 7-parameter mutation tool with no parameter descriptions, no enums, and no sibling routing. The description only captures the core update intent but omits the resource_type semantics, payload constraints, and selection guidance needed for reliable invocation. The existence of an output schema reduces the need for return-value explanation, but the input-side gaps remain significant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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, but it only vaguely maps to resource_id ('one exact UUID') and payload ('operation-specific payload'). Required resource_type and optional model_id, project_id, artifact_id, and component_type are left unexplained, making correct parameter selection difficult.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a clear verb and object: 'Update one exact UUID through an allowlisted operation-specific payload.' This distinguishes the tool from create, delete, get, and list siblings. It does not explicitly name sibling alternatives, but the update resource scope is reasonably clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus zenml_create_resource, zenml_delete_resource, zenml_action_resource, or other siblings. The verb 'Update' implies it is for modifying an existing resource, but no exclusions, prerequisites, or alternative-selection cues are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.