data-analysis-agent

Overview Schema Source Related Servers Discussions Admin

find_outliers

Detect outliers in a numeric column using IQR or z-score, returning count, percentage, bounds, and sample row IDs without modifying the dataset.

Instructions

Read-only outlier inspection on a numeric column using 'iqr' (Interquartile Range) or 'zscore'. Returns outlier count, percentage, bounds, and sample row IDs without altering the dataset.

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": {
      "session_id": "<session_id>",
      "column": "<column>"
    },
    "name": "find_outliers"
  }
}

Input Schema

Name	Required	Default
`column`	Yes
`method`	No	iqr
`sample`	No
`threshold`	No
`session_id`	Yes

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 4, 2026

TDQS

A4/5.0

Behavior4/5

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

No annotations are provided, so the description carries the behavioral transparency burden. It explicitly discloses non-destructive behavior and the specific outputs: outlier count, percentage, bounds, and sample row IDs. It does not cover edge cases like non-numeric columns or threshold interactions, but it provides solid transparency for a read-only tool.

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 a single dense sentence with no filler. It front-loads the core purpose and includes only information that helps an agent understand and use the tool.

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?

The description covers core purpose and return values, and the output schema exists, so return value detail is not required. However, with 5 parameters and 0% schema description coverage, the optional 'sample' and 'threshold' parameters remain unexplained, leaving the definition incomplete for full invocation confidence.

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 for missing parameter meaning. It adds context about numeric columns and method choices, but it does not explain the 'sample' or 'threshold' parameters, their defaults, or how they affect the calculation. An agent would not know what values to pass beyond the required session_id and column.

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 it performs read-only outlier inspection on a numeric column using 'iqr' or 'zscore'. It explicitly says it does not alter the dataset, which directly differentiates it from the sibling tool 'remove_outliers'.

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

Usage Guidelines4/5

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

The description conveys its use case through 'Read-only' and 'without altering the dataset', signaling it is for detection/inspection rather than transformation. It does not explicitly name an alternative tool, but the sibling list and non-destructive language make the intended usage reasonably clear.

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