Skip to main content
Glama
getsimba-ai

Simba MCP Server

Official
by getsimba-ai

Create Quality Policy

create_quality_policy

Create a project-specific quality policy that defines required checks, metric thresholds, and validation protocols to enforce model quality gates before runs.

Instructions

Save project-specific checks. Built-in checks have metric (r_hat_max, mae, rmse, wape, prediction_mae, prediction_rmse, prediction_wape), maximum and required. Custom numeric checks use metric custom:, name, units, operator (lte/gte/between), applicable minimum/maximum and required. Boolean checks use kind=boolean, operator=equals and expected=true/false. Manual checks use kind=manual, equals, expected=true; agents can define these but cannot submit manual sign-off. Custom bounds may be negative. WAPE is a fraction. Prediction-window checks require saved finite actuals/predictions at unique dates after the saved training window; this does not certify untouched holdout provenance. No default thresholds are assumed. Declare at least one required check, use each metric once, and set maximum R-hat at least 1. Optional validation_protocol declares a temporal holdout split, configured sampling minima, R-hat and prediction WAPE limits before both runs launch under this policy. The backend validates policy rules.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYes
checksYes
study_idYes
rationaleYes
validation_protocolNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.5.0

TDQS

A4.5/5.0
Behavior5/5

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

The description goes well beyond the annotations by disclosing important behavioral constraints: no default thresholds, required-check rules, uniqueness of metrics, the R-hat minimum, prediction-window requirements, the holdout provenance caveat, and the fact that agents cannot submit manual sign-off. This gives an agent realistic expectations about what the backend will enforce.

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 front-loaded with the core action and packs many distinct, useful constraints into a dense paragraph. It is efficient but could be improved with light structural separation between check types, validation protocol behavior, and validation rules.

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 high complexity, the description is remarkably complete: it covers all check kinds, parameter relationships, validation-protocol semantics, and important caveats. Since an output schema exists, not explaining return values is acceptable, and the behavioral detail is sufficient for an agent to invoke the tool 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?

With schema description coverage at 0%, the description carries the full burden, and it succeeds. It explains core parameter semantics for built-in, custom, boolean, and manual checks, details the validation_protocol object, and clarifies edge cases such as negative custom bounds and WAPE being a fraction.

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: 'Save project-specific checks.' It clearly differentiates this from the sibling list_quality_policies by describing creation-side behavior and enumerating the distinct check types the tool supports.

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

Usage Guidelines3/5

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

The description thoroughly explains what the tool can do and the constraints on its use, but it never explicitly states when to choose this tool over alternatives or when not to use it. The intended usage is implied rather than directly framed against sibling tools like list_quality_policies or update_study.

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