update-registered-model
Update the description of a registered MLflow model to reflect changes or provide additional context.
Instructions
Update a registered model's description
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| description | No |
Update the description of a registered MLflow model to reflect changes or provide additional context.
Update a registered model's description
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| description | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and openWorldHint=true, which are consistent with the 'update' action described. The description does not add behavioral details beyond the annotations, such as whether only the description is affected or if other properties are reset. No contradictions.
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 very short (one sentence, four words), which makes it concise but arguably too terse. It front-loads the key action but lacks detail that could be added without significant bloat.
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?
Given no output schema, the description should explain what happens on success or failure, but it does not. It also omits details like whether the model must exist, what happens to other fields, and any side effects. For a simple update tool, this is minimally adequate but lacks completeness.
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 coverage is 0%, so the description partially compensates by implying that 'name' identifies the model and 'description' provides the new value. However, it does not explain parameter formats, constraints, or the effect of omitting the optional description parameter.
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?
Description clearly states the action ('Update'), the resource ('a registered model'), and the specific attribute being updated ('description'). This distinguishes it from sibling tools like 'create-registered-model', 'delete-registered-model', and 'rename-registered-model'.
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 provided on when to use this tool versus alternatives, such as when to update other attributes or when to use model version update tools. There is no mention of prerequisites or context for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/us-all/mlflow-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server