Skip to main content
Glama

Analyze Correlation

analyze_correlation

Calculate correlations between numerical features in a dataset using its ID to reveal relationships between variables for exploratory analysis.

Instructions

Calculate correlations between numerical features. Args: dataset_id (str): ID of the dataset. Returns: dict: Dataset ID and correlation values between numerical columns (None for constant columns).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "dataset_id": "<dataset_id>"
    },
    "name": "analyze_correlation"
  }
}

Input Schema

NameRequiredDescriptionDefault
dataset_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3/5.0
Behavior3/5

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

No annotations are supplied, so the description carries the full disclosure burden. It does add one genuinely useful behavioral detail — that constant columns yield None — but omits the correlation method (Pearson vs Spearman), handling of non-numeric or missing data, and whether any state is mutated.

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 docstring is short and front-loaded, with a clear purpose line followed by Args and Returns sections. The 'Args:'/'Returns:' scaffolding is boilerplate for a single trivial parameter, but it costs little.

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

Completeness3/5

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

With no annotations and no output schema, the description does describe the return shape (dataset ID plus correlation values, None for constant columns), which is above average. However, it leaves the correlation method and input constraints unspecified for a statistical tool whose defaults materially change the result.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate, yet the Args entry 'dataset_id (str): ID of the dataset' only restates the parameter name and type. It gives no hint about where the ID comes from or its expected form.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first line states a specific verb and resource ('Calculate correlations between numerical features'), so the operation is unambiguous. It does not differentiate from adjacent siblings such as analyze_relationship or analyze_distribution, so the agent must infer the boundary from names alone.

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

Usage Guidelines2/5

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

There is no statement of when to use this tool versus analyze_relationship or analyze_distribution, and no precondition given (e.g., that the dataset must contain numeric columns). Usage is only implied by the verb 'calculate correlations'.

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

Deploy Server

Other Tools