Skip to main content
Glama

discovery_analyze

Destructive

Run Disco on tabular data to find novel, statistically validated patterns.

This is NOT another data analyst — it's a discovery pipeline that systematically
searches for feature interactions, subgroup effects, and conditional relationships
nobody thought to look for, then validates each on hold-out data with FDR-corrected
p-values and checks novelty against academic literature.

This is a long-running operation. Returns a run_id immediately.
Use discovery_status to poll and discovery_get_results to fetch completed results.

Use this when you need to go beyond answering questions about data and start
finding things nobody thought to ask. Do NOT use this for summary statistics,
visualization, or SQL queries.

Public runs are free but results are published. Private runs cost credits.
Call discovery_estimate first to check cost. Private report URLs require
sign-in — tell the user to sign in at the dashboard with the same email
address used to create the account (email code, no password needed).

Call discovery_upload first to upload your file, then pass the returned file_ref here.

Args:
    target_column: The column to analyze — what drives it, beyond what's obvious.
    file_ref: The file reference returned by discovery_upload.
    analysis_depth: Search depth (1=fast, higher=deeper). Default 1.
    visibility: "public" (free) or "private" (costs credits). Default "public".
    title: Optional title for the analysis.
    description: Optional description of the dataset.
    excluded_columns: Optional JSON array of column names to exclude from analysis.
    column_descriptions: Optional JSON object mapping column names to descriptions. Significantly improves pattern explanations — always provide if column names are non-obvious (e.g. {"col_7": "patient age", "feat_a": "blood pressure"}).
    author: Optional author name for the report.
    source_url: Optional source URL for the dataset.
    use_llms: Slower and more expensive, but you get smarter pre-processing, summary page, literature context and pattern novelty assessment. Only applies to private runs — public runs always use LLMs. Default false.
    api_key: Disco API key (disco_...). Optional if DISCOVERY_API_KEY env var is set.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
titleNo
authorNo
api_keyNo
file_refNo
use_llmsNo
source_urlNo
visibilityNopublic
descriptionNo
target_columnYes
analysis_depthNo
excluded_columnsNo
column_descriptionsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

TDQS

A5/5.0
Behavior5/5

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

The description extensively discloses behavioral traits beyond annotations: it is a long-running operation that returns a run_id immediately, public runs are free but publish results, private runs cost credits, and private report URLs require sign-in. It also reveals side effects like publishing and credit consumption, which aligns with the destructiveHint:true annotation (non-idempotent, resource-consuming). No contradiction found.

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 long but every section earns its place. It opens with a clear summary, then covers workflow, cost/privacy implications, authentication, and prerequisites. Bolded phrases and paragraph breaks make it scannable. No filler or repetition exists; all content is operational guidance an agent needs.

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 complexity (12 parameters, side effects, long-running nature), the description is remarkably complete. It explains the immediate return (run_id), how to retrieve results (discovery_status and discovery_get_results), prerequisites (discovery_upload), cost/publication tradeoffs, and authentication fallback. The output schema likely details result structure, so not explaining it is acceptable. The description leaves no critical operational gap.

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 schema has zero description coverage, the tool description includes a dedicated 'Args' section that explains every parameter: target_column, file_ref, analysis_depth, visibility, title, description, excluded_columns, column_descriptions, author, source_url, use_llms, and api_key. It adds meaningful guidance, such as defaults, the distinction between public/private, and the recommendation to always provide column_descriptions for non-obvious names. This fully compensates for the schema's lack of 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 Disco on tabular data to find novel, statistically validated patterns.' It clearly distinguishes itself from generic data analysis ('NOT another data analyst') and from sibling tools like discovery_upload, discovery_status, and discovery_get_results. The purpose is unmistakable and precisely scoped.

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 states when to use the tool ('when you need to go beyond answering questions... finding things nobody thought to ask') and when NOT to use it ('Do NOT use for summary statistics, visualization, or SQL queries'). It also provides a clear workflow: call discovery_upload first, then pass file_ref, poll with discovery_status, and fetch results with discovery_get_results. Alternatives are named directly.

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.

TDQS

A4.4/5.0
Disambiguation5/5

Each tool targets a distinct operation (account, payment, analysis, plans, login flows, etc.) with no overlap. Even paired tools like signup/login and their verify counterparts are clearly differentiated.

Naming Consistency5/5

All tools follow a consistent 'discovery_' prefix + verb_noun pattern (e.g., discovery_add_payment_method, discovery_get_results). No mixed conventions or vague names.

Tool Count5/5

14 tools cover account management, analysis pipeline, and billing without unnecessary redundancy. The scope is well-matched to the server's purpose.

Completeness4/5

The tool set covers the full user journey from signup and payment to running analyses and retrieving results. Minor gaps exist (e.g., no explicit cancellation of subscriptions), but the core workflow is fully supported.