Skip to main content
Glama
dave1362

RCA-MCP Connector

by dave1362
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
Python
Remote

rca_model_validate

Validate a causal model against your hold-out data using a correlation-based sanity check, returning coverage and confidence metrics to catch broken models before deployment.

Instructions

Run a quick correlation-based sanity check of a model against hold-out data you supply (not automatically split from training data -- you provide a separate dataset). This is a lightweight coverage/confidence check, not full cross-validation or backtesting; use it to catch an obviously broken model, not to certify accuracy.

Sets the model's status to "validated" on success -- you don't need to also call rca_model_update_status afterward, though you can still use that tool later to move it to "deployed", "deprecated", or "failed".

Args: params (ModelValidateInput): - model_id: the model to validate (from rca_model_create) - validation_data: {variable: [values]}, same shape as an rca_analysis_run payload's "data" field - target: which variable in validation_data to validate against

Returns: str: JSON validation metrics (coverage, mean_correlation, confidence), or a not_found/bad_input error

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 / ModelValidateInput / properties / client_id / description
      Added value: +"Client namespace ID"
    • addedInput schema / $defs / ModelValidateInput / properties / token / description
      Added value: +"API key to authenticate this request"
  2. Changed1 schema field changedv4.1.14
    • addedInput schema / $defs / ModelValidateInput / properties / model_id / description
      Added value: +"Model to validate (from rca_model_create)"
  3. First observedv4.1.13

TDQS

A5/5.0
Behavior5/5

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

The description discloses a key side effect not visible from the annotations: it sets the model status to 'validated' on success. It also sets accurate expectations about the lightweight nature of the check and mentions possible error returns, adding behavioral context beyond the schema and annotation fields.

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

Conciseness5/5

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

The description is front-loaded with the core purpose, then adds usage caveats, side effects, and parameter details in a clear, scannable structure. The Args/Returns sections are compact and every sentence contributes useful information without redundancy.

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?

The description covers what the tool does, how to provide inputs, what side effect occurs, how it relates to sibling tools, and what return value to expect. For a validation tool with this complexity, nothing essential is missing for an agent to select and invoke it correctly.

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 the raw parameter names appear in the schema, the description adds critical semantics: model_id comes from rca_model_create, validation_data must match the shape of an rca_analysis_run payload's 'data' field, and target refers to a variable inside validation_data. This meaningfully reduces ambiguity beyond the schema descriptions.

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 opens with a specific verb and resource: 'Run a quick correlation-based sanity check of a model against hold-out data you supply.' It clearly distinguishes this from full cross-validation or backtesting, and from rca_model_update_status, which is a sibling tool with a different purpose.

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 explicitly says when to use it ('catch an obviously broken model') and when not to ('not to certify accuracy'), clarifies that hold-out data must be supplied separately rather than auto-split, and explains that calling rca_model_update_status afterward is unnecessary for 'validated' but can be used for other statuses.

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