Skip to main content
Glama
dave1362

RCA-MCP Connector

by dave1362
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
Python
Remote

rca_model_create

Register a new root cause analysis model specification in the registry, starting in draft status. Define the model family and configuration now, then run and validate it later.

Instructions

Register a new RCA model spec in the registry, starting in "draft" status. This just stores the spec — it doesn't run anything.

Plan limits on how many models you can hold: Free 5, Starter 20, Pro+ unlimited (call rca_admin_show_plan_info to check your own count/limit).

Typical lifecycle: create (here) → rca_analysis_run to use it → rca_model_validate on hold-out data → rca_model_update_status to mark it "deployed" (or "deprecated"/"failed") → rca_model_delete when you're done with it entirely.

Model families: bayesian_network | dowhy_causal_inference | granger_causality | fault_tree_analysis | fishbone_ishikawa | fmea | bayesian_structural_time_series | change_point_detection | random_forest_importance | counterfactual_analysis

Args: params (ModelCreateInput): - name: for your own reference only - family: which RCA algorithm this model will use - description, tags, version: optional, for your own organization - config: family-specific parameters (e.g. significance threshold), passed through to the model at run time

Returns: str: JSON {model_id}, or a plan_required error if you're at your model-count limit

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 / ModelCreateInput / properties / client_id / description
      Added value: +"Client namespace ID"
    • addedInput schema / $defs / ModelCreateInput / properties / token / description
      Added value: +"API key to authenticate this request"
  2. Changed4 schema fields changedv4.1.14
    • addedInput schema / $defs / ModelCreateInput / properties / description / description
      Added value: +"Optional free-text notes on what this model is for"
    • addedInput schema / $defs / ModelCreateInput / properties / name / description
      Added value: +"Model name (for your own reference — doesn't affect behavior)"
    • addedInput schema / $defs / ModelCreateInput / properties / tags / description
      Added value: +"Up to 10 free-text labels for filtering with rca_model_list"
    • addedInput schema / $defs / ModelCreateInput / properties / version / description
      Added value: +"Your own version label for this model (not validated or auto-incremented)"
  3. First observedv4.1.13

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already indicate this is a write operation that is not idempotent and not destructive, and the description adds valuable behavioral details: the model starts in 'draft', creating doesn't run anything, and hitting the plan limit returns a plan_required error. This goes beyond the annotations and helps the agent predict side effects, though it could also mention what happens on duplicate names or whether deletion is required before recreating.

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 purpose front-loaded, followed by limits, lifecycle, families, args, and return. It is a bit long and partially duplicates the family enum already present in the schema, but every major section earns its place by adding operational or semantic context.

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 and the lack of top-level schema descriptions, the description is complete: it explains status, side effects, plan limits, lifecycle routing, parameter semantics, and the return value including an error case. An agent has enough information to decide whether and when to call this tool and what to pass.

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?

Although schema description coverage is reported as 0%, the description compensates thoroughly by explaining each key field's meaning and purpose: name is for reference only, family selects the algorithm, config is passed through at run time, and description/tags/version are optional organizational metadata. This adds real semantic value beyond the bare schema field 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 clearly states the specific verb ('Register'), the resource ('a new RCA model spec'), and the immediate outcome ('starting in draft status'). It also explicitly contrasts with other lifecycle tools ('it doesn't run anything') and names the siblings in the lifecycle, so the agent can distinguish it from rca_model_update_status, rca_analysis_run, and rca_model_delete.

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?

The description gives explicit when-to-use guidance: create is the first step in a typical lifecycle, and the full sequence is laid out. It also provides operational context by mentioning plan limits and pointing to rca_admin_show_plan_info to check capacity, and it clearly says create only stores the spec, preventing misuse as an execution tool.

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