Skip to main content
Glama

Correlación (Pearson, Spearman)

stats-correlation
Read-onlyIdempotent

Mide cómo se mueven juntas dos series de igual longitud: coeficiente de Pearson (lineal), de Spearman (por rangos, menos sensible a valores atípicos) y covarianza. Cuándo: un resultado numérico tiene que ser exacto o reproducible y no estimado. No para: calcular el ajuste por mínimos cuadrados y = pendiente·x + intercepto, con R² y predicciones (stats-regression). Efectos secundarios: ninguno (solo lectura, sin red, sin estado guardado). Determinista: la misma entrada da la misma salida. Límites: entrada JSON de hasta 64 KB, 1 s por llamada, resultado de hasta 1 MB.

EN: Measures how two equal-length series move together: the Pearson coefficient (linear), the Spearman coefficient (rank-based, less sensitive to outliers) and the covariance. When: a numeric result has to be exact or reproducible instead of estimated. Not for: least-squaring fit y = slope·x + intercept with R², standard error, and optional predictions for new x values (stats-regression). [EN completo / full EN: inputSchema.description]

Input Schema

NameRequiredDescriptionDefault
xYesX values (array of number; required; at least 2 items).
yYesY values (array of number; required; at least 2 items).

Output Schema

NameRequiredDescriptionDefault
nNo
pearsonNo
spearmanNo
covariance_sampleNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / x / examples
      Added value: +[
      +  [
      +    1,
      +    2,
      +    3,
      +    4,
      +    5
      +  ]
      +]
    • addedInput schema / properties / y / examples
      Added value: +[
      +  [
      +    2,
      +    4,
      +    6,
      +    8,
      +    10
      +  ]
      +]
  2. Changed1 schema field changed
    • addedInput schema / description
      Added value: +"EN: Measures how two equal-length series move together: the Pearson coefficient (linear), the Spearman coefficient (rank-based, less sensitive to outliers) and the covariance. When: a numeric result has to be exact or reproducible instead of estimated. Not for: least-squaring fit y = slope·x + intercept with R², standard error, and optional predictions for new x values (stats-regression). Side effects: none (read-only, no network access, no stored state). Deterministic: the same input gives the same output. Limits: JSON input up to 64 KB, 1 s per call, result up to 1 MB."
  3. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Adds genuinely new behavioral context beyond the annotations: hard limits (64 KB input, 1 s per call, 1 MB result) that tell an agent when the call will fail on large series. The 'sin red, sin estado guardado' and determinism notes largely restate readOnlyHint/idempotentHint/openWorldHint, so it is value-adding but partly redundant with structured data.

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?

Front-loaded with what the tool computes, then consistently sectioned into When / Not for / Side effects / Deterministic / Limits, so an agent can skim the labels. It is longer than necessary because the whole block is duplicated bilingually and the side-effect sentence repeats annotation content.

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?

With a rich annotation set and an output schema, the description covers what is needed to select and invoke: computation outputs, exclusions, determinism, and runtime limits. Only the error behavior for mismatched or too-short series is left unstated, a minor gap for a two-array numeric tool.

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?

Schema coverage is 100% with per-property descriptions and examples, so the baseline is 3. The description lifts it by stating the equal-length constraint across x and y — a real validation rule the schema does not express — though it says nothing about the failure mode when lengths differ.

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 gives a precise verb+resource (measures how two equal-length series move together) and enumerates exactly what is computed: Pearson, Spearman and covariance, including the semantic difference between them (linear vs. rank-based, outlier sensitivity). It contrasts itself with stats-regression by naming the sibling, so an agent can separate the two without inspecting schemas.

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?

Explicit 'Cuándo' condition (a numeric result must be exact/reproducible rather than estimated) plus an explicit 'No para' branch naming the alternative (stats-regression) and the operation it covers. Both use and exclusion are stated, not implied.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources