Skip to main content
Glama
dave1362

RCA-MCP Connector

by dave1362
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
Python
Remote

rca_model_update_status

Idempotent

Set a model's lifecycle status to draft, trained, validated, deployed, deprecated, or failed. Use deprecated to retire a model without deleting it, or failed to flag poor validation results.

Instructions

Set a model's lifecycle status directly to any of: draft, trained, validated, deployed, deprecated, failed. This is a direct field update, not a guarded state machine — there is no enforced order (e.g. nothing stops setting "deployed" on a model that was never validated); that discipline is on the caller, not the API.

Use "deprecated" to retire a model without deleting it (its past results stay queryable via rca_analysis_get_result); use "failed" to flag one that shouldn't be used, e.g. after rca_model_validate reports poor hold-out performance. Use rca_model_delete instead if you want the model gone entirely, not just marked.

Args: params (ModelStatusInput): - model_id: the model to update - new_status: one of draft | trained | validated | deployed | deprecated | failed

Returns: str: JSON {model_id, status}, or a not_found error if the model doesn't exist or belongs to another user

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
paramsYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv4.1.15
    • addedInput schema / $defs / ModelStatusInput / properties / client_id / description
      Added value: +"Client namespace ID"
    • addedInput schema / $defs / ModelStatusInput / properties / token / description
      Added value: +"API key to authenticate this request"
  2. First observedv4.1.13

TDQS

A4.5/5.0
Behavior4/5

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

The description discloses that no state-machine validation is enforced and that deprecated models remain queryable, which adds valuable behavioral context. It does not mention idempotent behavior or auth-required details, but those are partially covered by annotations and 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 organized into clear purpose, usage guidance, args, and returns sections. Some repetition occurs (e.g., the 'no enforced order' point is made twice), but it remains focused and scannable without significant fluff.

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

Completeness4/5

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

The description covers the key behaviors, return format, and error case (not_found), plus relationships to delete/validate tools. It does not explicitly address client_id, token, or idempotency, but annotations and schema fill those gaps sufficiently for this tool's complexity.

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

Parameters4/5

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

The description explains model_id and new_status, including the allowed enum values inline. It omits token and client_id, but those have explicit descriptions in the schema, so the added value is adequate though not maximal.

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 a specific action ('Set a model's lifecycle status'), enumerates all allowed values, and distinguishes it from related tools like rca_model_delete. An agent can immediately understand what the tool does and when it applies.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly explains when to use 'deprecated' vs 'failed', clarifies that the operation is an unguarded direct field update, and directs users to rca_model_delete when deletion is intended. This gives clear conditional guidance beyond what annotations provide.

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

Install Server

Other Tools