Skip to main content
Glama
deenesjakoruzh
leap-laboratories

Disco

by leap-laboratories
OverviewSchemaRelated ServersScoreDiscussions
Python
Remote

Disco

Find novel, statistically validated patterns in tabular data — feature interactions, subgroup effects, and conditional relationships that humans and agents miss.

PyPI License: MIT

Made by Leap Laboratories.

What it actually does

Most data analysis starts with a question. Disco starts with the data.

Without biases or assumptions, it finds combinations of feature conditions that significantly shift your target column — things like "patients aged 45–65 with low HDL and high CRP have 3× the readmission rate" — without you needing to hypothesise that interaction first.

Each pattern is:

  • Validated on a hold-out set — increases the chance of generalisation

  • FDR-corrected — p-values included, adjusted for multiple testing

  • Checked against academic literature — to help you understand what you've found, and identify if it is novel.

The output is structured: conditions, effect sizes, p-values, citations, and a novelty classification for every pattern found.

Use it when: "which variables are most important with respect to X", "are there patterns we're missing?", "I don't know where to start with this data", "I need to understand how A and B affect C".

Not for: summary statistics, visualisation, filtering, SQL queries — use pandas for those

Related MCP server: Discovery Engine MCP Server

Quickstart

pip install discovery-engine-api

Get an API key:

# Step 1: request verification code (no password, no card)
curl -X POST https://disco.leap-labs.com/api/signup \
  -H "Content-Type: application/json" \
  -d '{"email": "you@example.com"}'

# Step 2: submit code from email → get key
curl -X POST https://disco.leap-labs.com/api/signup/verify \
  -H "Content-Type: application/json" \
  -d '{"email": "you@example.com", "code": "123456"}'
# → {"key": "disco_...", "credits": 10, "tier": "free_tier"}

Or create a key at disco.leap-labs.com/developers.

Run your first analysis:

from discovery import Engine

engine = Engine(api_key="disco_...")
result = await engine.discover(
    file="data.csv",
    target_column="outcome",
)

for pattern in result.patterns:
    if pattern.p_value < 0.05 and pattern.novelty_type == "novel":
        print(f"{pattern.description} (p={pattern.p_value:.4f})")

print(f"Explore: {result.report_url}")

Runs take a few minutes. discover() polls automatically and logs progress — queue position, estimated wait, current pipeline step, and ETA. For background runs, see Running asynchronously.

→ Full Python SDK reference · Example notebook

What you get back

Each Pattern in result.patterns looks like this (real output from a crop yield dataset):

Pattern(
    description="When humidity is between 72–89% AND wind speed is below 12 km/h, "
                "crop yield increases by 34% above the dataset average",
    conditions=[
        {"type": "continuous", "feature": "humidity_pct",
         "min_value": 72.0, "max_value": 89.0},
        {"type": "continuous", "feature": "wind_speed_kmh",
         "min_value": 0.0, "max_value": 12.0},
    ],
    p_value=0.003,              # FDR-corrected
    novelty_type="novel",
    novelty_explanation="Published studies examine humidity and wind speed as independent "
                        "predictors, but this interaction effect — where low wind amplifies "
                        "the benefit of high humidity within a specific range — has not been "
                        "reported in the literature.",
    citations=[
        {"title": "Effects of relative humidity on cereal crop productivity",
         "authors": ["Zhang, L.", "Wang, H."], "year": "2021",
         "journal": "Journal of Agricultural Science"},
    ],
    target_change_direction="max",
    abs_target_change=0.34,     # 34% increase
    support_count=847,          # rows matching this pattern
    support_percentage=16.9,
)

Key things to notice:

  • Patterns are combinations of conditions — humidity AND wind speed together, not just "more humidity is better"

  • Specific thresholds — 72–89%, not a vague correlation

  • Novel vs confirmatory — every pattern is classified; confirmatory ones validate known science, novel ones are what you came for

  • Citations — shows what IS known, so you can see what's genuinely new

  • report_url links to an interactive web report with all patterns visualised

The result.summary gives an LLM-generated narrative overview:

result.summary.overview
# "Disco identified 14 statistically significant patterns. 5 are novel.
#  The strongest driver is a previously unreported interaction between humidity
#  and wind speed at specific thresholds."

result.summary.key_insights
# ["Humidity × low wind speed at 72–89% humidity produces a 34% yield increase — novel.",
#  "Soil nitrogen above 45 mg/kg shows diminishing returns when phosphorus is below 12 mg/kg.",
#  ...]

How it works

Disco is a pipeline, not prompt engineering over data. It:

  1. Trains machine learning models on a subset of your data

  2. Uses interpretability techniques to extract learned patterns

  3. Validates every pattern on the held-out data with FDR correction (Benjamini-Hochberg)

  4. Checks surviving patterns against academic literature via semantic search

You cannot replicate this by writing pandas code or asking an LLM to look at a CSV. It finds structure that hypothesis-driven analysis misses because it doesn't start with hypotheses.

Preparing your data

Before running, exclude columns that would produce meaningless findings. Disco finds statistically real patterns — but if the input includes columns that are definitionally related to the target, the patterns will be tautological.

Exclude:

  1. Identifiers — row IDs, UUIDs, patient IDs, sample codes

  2. Data leakage — the target renamed or reformatted (e.g., diagnosis_text when the target is diagnosis_code)

  3. Tautological columns — alternative encodings of the same construct as the target. If target is serious, then serious_outcome, not_serious, death are all part of the same classification. If target is profit, then revenue and cost together compose it. If target is a survey index, the sub-items are tautological.

Full guidance with examples: SKILL.md

Parameters

await engine.discover(
    file="data.csv",           # path, Path, or pd.DataFrame
    target_column="outcome",   # column to predict/explain
    analysis_depth=2,          # 2=default, higher=deeper analysis, lower = faster and cheaper
    visibility="public",       # "public" (always free, data and report is published) or "private" (costs credits)
    column_descriptions={      # improves pattern explanations and literature context
        "bmi": "Body mass index",
        "hdl": "HDL cholesterol in mg/dL",
    },
    excluded_columns=["id", "timestamp"],  # see "Preparing your data" above
    use_llms=False,                        # Defaults to False. If True, runs are slower and more expensive, but you get smarter pre-processing, summary page, literature context and novelty assessment. Public runs always use LLMs.
    title="My dataset",
    description="...", # improves pattern explanations and literature context
)

Public runs are free but results are published. Set visibility="private" for private data — this costs credits.

Running asynchronously

Runs take a few minutes. For agent workflows or scripts that do other work in parallel:

# Submit without waiting
run = await engine.run_async(file="data.csv", target_column="outcome", wait=False)
print(f"Submitted {run.run_id}, continuing...")

# ... do other things ...

result = await engine.wait_for_completion(run.run_id, timeout=1800)

For synchronous scripts and Jupyter notebooks:

result = engine.run(file="data.csv", target_column="outcome", wait=True)
# or: pip install discovery-engine-api[jupyter] for notebook compatibility

MCP server

Disco is available as an MCP server — no local install required.

{
  "mcpServers": {
    "discovery-engine": {
      "url": "https://disco.leap-labs.com/mcp",
      "env": { "DISCOVERY_API_KEY": "disco_..." }
    }
  }
}

Tools: discovery_list_plans, discovery_estimate, discovery_upload, discovery_analyze, discovery_status, discovery_get_results, discovery_account, discovery_signup, discovery_signup_verify, discovery_login, discovery_login_verify, discovery_add_payment_method, discovery_subscribe, discovery_purchase_credits.

→ Full agent skill file

Pricing

Cost

Public runs

Free — results and data are published

Private runs

Credits vary by file size and configuration — use engine.estimate()

Free tier

10 credits/month, no card required

Researcher

$49/month — 500 credits

Team

$199/month — 2000 credits

Credits

$0.10 per credit

Estimate before running:

estimate = await engine.estimate(file_size_mb=10.5, num_columns=25, analysis_depth=2, visibility="private")
# estimate["cost"]["credits"] → 55
# estimate["account"]["sufficient"] → True/False

Account management is fully programmatic — attach payment methods, subscribe to plans, and purchase credits via the SDK or REST API. See Python SDK reference or SKILL.md.

Expected data format

Disco expects a flat table — columns for features, rows for samples.

| patient_id | age | bmi  | smoker | outcome |
|------------|-----|------|--------|---------|
| 001        | 52  | 28.3 | yes    | 1       |
| 002        | 34  | 22.1 | no     | 0       |
| ...        | ... | ...  | ...    | ...     |

  • One row per observation — a patient, a sample, a transaction, a measurement, etc.

  • One column per feature — numeric, categorical, datetime, or free text are all fine

  • One target column — the outcome you want to understand. Must have at least 2 distinct values.

  • Missing values are OK — Disco handles them automatically. Don't drop rows or impute beforehand.

  • No pivoting needed — if your data is already in a flat table, it's ready to go

Supported formats: CSV, TSV, Excel (.xlsx), JSON, Parquet, ARFF, Feather. Max 5 GB.

Not supported: images, raw text documents, nested/hierarchical JSON, multi-sheet Excel (use the first sheet or export to CSV)

Compared to other tools

Goal

Tool

Summary statistics, data quality

ydata-profiling, sweetviz

Predictive model

AutoML (auto-sklearn, TPOT, H2O)

Quick correlations

pandas, seaborn

Answer a specific question about data

ChatGPT, Claude

Find what you don't know to look for

Disco

Disco isn't a replacement for EDA or AutoML — it finds the patterns those tools miss. We tested 18 data analysis tools on a dataset with known ground-truth patterns. Most confidently reported wrong results. Disco was the only one that found every pattern.

Links

Available Tools

14 tools
discovery_accountA
Read-only
Inspect

Check your Disco account status.

Returns current plan, available credits (subscription + purchased), and
payment method status. Use this to verify you have sufficient credits
before running a private analysis.

Args:
    api_key: Disco API key (disco_...). Optional if DISCOVERY_API_KEY env var is set.
ParametersJSON Schema
NameRequiredDescriptionDefault
api_keyNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.7/5.0
Behavior4/5

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

The annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds valuable context beyond this by specifying the return data (plan, credits, payment method status) and the practical use case for credit verification, which helps the agent understand the tool's behavioral output and purpose. No contradiction with annotations exists.

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 well-structured and front-loaded with the core purpose, followed by return details, usage guidance, and parameter explanation. Every sentence earns its place without redundancy, making it efficient and easy to parse.

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 low complexity (1 optional parameter), the presence of annotations (readOnlyHint) and an output schema (which handles return values), the description is complete. It covers purpose, usage, parameter semantics, and behavioral context adequately without needing to explain return values.

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?

The input schema has 1 parameter with 0% description coverage, but the description compensates by explaining the api_key parameter's purpose (Disco API key), format hint ('disco_...'), and optionality condition (can use env var instead). This adds meaningful semantics beyond the bare schema.

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 the specific action ('Check your Disco account status') and resource ('Disco account'), and distinguishes it from siblings by focusing on account status verification rather than analysis, payment, or other operations. It explicitly mentions what information is returned (plan, credits, payment method status).

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 provides explicit guidance on when to use this tool ('to verify you have sufficient credits before running a private analysis'), which clearly differentiates it from sibling tools like discovery_analyze (for analysis) or discovery_purchase_credits (for buying credits). It establishes a clear prerequisite context.

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

discovery_add_payment_methodA
Idempotent
Inspect

Attach a Stripe payment method to your Disco account.

The payment method must be tokenized via Stripe's API first — card details
never touch Disco's servers. Required before purchasing credits
or subscribing to a paid plan.

To tokenize a card, call Stripe's API directly:
POST https://api.stripe.com/v1/payment_methods
with the stripe_publishable_key from your account info.

Args:
    payment_method_id: Stripe payment method ID (pm_...) from Stripe's API.
    api_key: Disco API key (disco_...). Optional if DISCOVERY_API_KEY env var is set.
ParametersJSON Schema
NameRequiredDescriptionDefault
payment_method_idYes
api_keyNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.7/5.0
Behavior4/5

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

The description adds valuable behavioral context beyond annotations: it explains security architecture ('card details never touch Disco's servers'), clarifies the prerequisite tokenization step via Stripe's API, and mentions the optional API key with environment variable fallback. Annotations provide idempotentHint=true and destructiveHint=false, which the description doesn't contradict but supplements with practical implementation details.

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 efficiently structured with zero waste: first sentence states purpose, second explains security architecture, third gives usage context, fourth provides alternative tool guidance, and the Args section clearly documents parameters. Every sentence earns its place with essential information.

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 (payment integration with external dependencies), the description is complete: it covers purpose, security model, prerequisites, usage context, parameter semantics, and alternative workflows. With annotations covering idempotency and non-destructiveness, and an output schema presumably handling return values, no significant gaps remain.

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?

With 0% schema description coverage, the description fully compensates by explaining both parameters: payment_method_id is described as 'Stripe payment method ID (pm_...) from Stripe's API' and api_key as 'Disco API key (disco_...). Optional if DISCOVERY_API_KEY env var is set.' This adds crucial semantic context about format, source, and optionality that the bare schema lacks.

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 the specific action ('Attach a Stripe payment method') and target resource ('to your Disco account'), distinguishing it from siblings like discovery_purchase_credits or discovery_subscribe which involve using payment methods rather than attaching them. It explicitly mentions the purpose is required before purchasing credits or subscribing to a paid plan.

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 provides explicit when-to-use guidance: 'Required before purchasing credits or subscribing to a paid plan.' It also distinguishes from alternatives by explaining that tokenization must happen via Stripe's API first, not through this tool, and gives the specific Stripe API endpoint to use instead.

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

discovery_analyzeA
Destructive
Inspect

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.
ParametersJSON Schema
NameRequiredDescriptionDefault
target_columnYes
file_refNo
analysis_depthNo
visibilityNopublic
titleNo
descriptionNo
excluded_columnsNo
column_descriptionsNo
authorNo
source_urlNo
use_llmsNo
api_keyNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior4/5

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

Annotations indicate destructiveHint=true and idempotentHint=false, but the description adds valuable behavioral context beyond this: it explains this is a 'long-running operation' with immediate run_id return, mentions cost implications (public vs private runs), authentication requirements for private reports, and workflow dependencies (upload first, then poll). While it doesn't explicitly mention destructive behavior, it provides operational context that complements the annotations.

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 well-structured with clear sections: purpose statement, behavioral context, usage guidelines, prerequisites, and parameter explanations. While comprehensive, some sentences could be more concise (e.g., the LLM explanation is verbose). The information is front-loaded with the core purpose first.

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, destructive operation, long-running nature) and the presence of an output schema (which handles return values), the description provides excellent contextual completeness. It covers workflow dependencies, cost implications, authentication requirements, operational characteristics, and parameter semantics, making it sufficiently complete for an agent to use effectively.

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?

With 0% schema description coverage, the description carries the full burden of parameter documentation. It provides meaningful context for most parameters: explains target_column purpose ('what drives it, beyond what's obvious'), file_ref dependency, analysis_depth meaning, visibility cost implications, and gives specific guidance for column_descriptions. However, it doesn't cover all 12 parameters equally well (e.g., author, source_url get minimal explanation).

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 the tool's purpose with specific verbs ('Run Disco on tabular data to find novel, statistically validated patterns') and distinguishes it from alternatives by explicitly stating what it is NOT ('NOT another data analyst', 'Do NOT use this for summary statistics, visualization, or SQL queries'). It differentiates from siblings by explaining its unique discovery pipeline approach.

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 provides explicit guidance on when to use ('Use this when you need to go beyond answering questions about data and start finding things nobody thought to ask') and when not to use ('Do NOT use this for summary statistics, visualization, or SQL queries'). It also mentions prerequisites ('Call discovery_upload first') and alternatives ('Use discovery_status to poll and discovery_get_results to fetch completed results').

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

discovery_estimateA
Read-only
Inspect

Estimate cost, time, and credit requirements before running an analysis.

Returns credit cost, estimated duration in seconds, whether you have
sufficient credits, and whether a free public alternative exists. Always call
this before discovery_analyze for private runs.

Args:
    file_size_mb: Size of the dataset in megabytes.
    num_columns: Number of columns in the dataset.
    num_rows: Number of rows (optional, improves time estimate).
    analysis_depth: Search depth (1=fast, higher=deeper). Default 1.
    visibility: "public" (free, results published) or "private" (costs credits).
    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.
ParametersJSON Schema
NameRequiredDescriptionDefault
file_size_mbYes
num_columnsYes
num_rowsNo
analysis_depthNo
visibilityNopublic
use_llmsNo
api_keyNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.7/5.0
Behavior4/5

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

The description adds valuable behavioral context beyond the readOnlyHint annotation. It explains that this is a pre-check tool to avoid unexpected costs, describes the different visibility modes (public vs private), clarifies the LLM behavior difference between public and private runs, and mentions the API key fallback to environment variable. While the annotation covers safety, the description provides important operational context.

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 well-structured and appropriately sized. It starts with the core purpose, then lists outputs, provides critical usage guidance, and details each parameter with meaningful explanations. While comprehensive, every sentence earns its place by adding necessary information for tool selection and invocation.

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 (7 parameters, cost estimation function) and the presence of an output schema, the description is complete. It explains the tool's role in the workflow, distinguishes it from siblings, provides parameter semantics that the schema lacks, and gives operational context. The output schema existence means the description doesn't need to detail return values.

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 0% schema description coverage, the description fully compensates by providing detailed semantic explanations for all 7 parameters. It explains what each parameter means (e.g., 'analysis_depth: Search depth (1=fast, higher=deeper)', 'use_llms: Slower and more expensive, but you get smarter pre-processing...'), specifies defaults, and clarifies optional vs required parameters with practical implications.

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 the tool's purpose: to estimate cost, time, and credit requirements before running an analysis. It specifies the exact outputs (credit cost, duration, credit sufficiency, free alternative existence) and distinguishes it from sibling tools by explicitly mentioning its relationship to discovery_analyze for private runs.

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 provides explicit usage guidance: 'Always call this before discovery_analyze for private runs.' It also distinguishes between public (free) and private (costs credits) runs, and clarifies that LLMs only apply to private runs while public runs always use them. This gives clear when-to-use and when-not-to-use criteria.

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

discovery_get_resultsA
Read-only
Inspect

Fetch the full results of a completed Disco run.

Returns discovered patterns (with conditions, p-values, novelty scores,
citations), feature importance scores, a summary with key insights, column
statistics, and suggestions for what to explore next.

The response includes a `dashboard_urls` object with direct links to each
page of the interactive report — use these to direct the user to the most
relevant view:
- **summary**: AI-generated overview with key insights, novel findings, and plain-language explanation of the most important findings
- **patterns**: Full list of discovered patterns with conditions, effect sizes, p-values, novelty scores, citations, and interactive visualisations
- **features**: Feature importances, feature statistics and distribution plots, and correlation matrix
- **territory**: Interactive 3D map showing how patterns select different regions of the data

Only call this after discovery_status returns "completed".

Args:
    run_id: The run ID returned by discovery_analyze.
    api_key: Disco API key (disco_...). Optional if DISCOVERY_API_KEY env var is set.
ParametersJSON Schema
NameRequiredDescriptionDefault
run_idYes
api_keyNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.7/5.0
Behavior4/5

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

The annotations provide readOnlyHint=true, indicating a safe read operation. The description adds valuable context beyond this by detailing what the response includes (patterns, feature importance, summary, etc.) and the dashboard_urls object with links to interactive reports. It doesn't contradict annotations and enriches understanding of the tool's behavior and output structure.

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 well-structured and front-loaded, starting with the core purpose, then detailing the response, usage guideline, and parameters. Every sentence adds value without redundancy, making it efficient and easy for an agent to parse quickly.

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 (fetching results of a data analysis run), the description is complete: it explains the purpose, output content, usage timing, and parameters. With annotations covering safety and an output schema presumably detailing the return structure, no critical gaps remain for effective agent use.

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?

With 0% schema description coverage, the description compensates by explaining both parameters: run_id ('The run ID returned by discovery_analyze') and api_key ('Optional if DISCOVERY_API_KEY env var is set'). It adds meaning beyond the bare schema, clarifying sources and optionality, though it could provide more detail on format or constraints.

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 the specific action ('Fetch the full results') and resource ('a completed Disco run'), distinguishing it from siblings like discovery_status (which checks status) or discovery_analyze (which initiates analysis). It precisely defines what the tool does without being vague or tautological.

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 this tool: 'Only call this after discovery_status returns "completed".' It provides a clear prerequisite and distinguishes it from alternatives by specifying the required state of the Disco run, guiding the agent on proper sequencing.

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

discovery_list_plansA
Read-only
Inspect

List available Disco plans with pricing.

No authentication required. Returns all available subscription tiers with credit allowances and pricing. Use this to help users choose a plan.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.7/5.0
Behavior4/5

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

The annotation readOnlyHint=true already indicates a safe read operation, but the description adds valuable context by stating 'No authentication required' and specifying that it returns 'all available subscription tiers with credit allowances and pricing.' This enhances transparency beyond the annotation, though it doesn't detail rate limits or error behaviors.

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 front-loaded with the core purpose in the first sentence, followed by authentication and usage context in two additional sentences. Each sentence adds value without redundancy, making it efficient and well-structured for quick understanding.

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 simplicity (0 parameters, read-only, with output schema), the description is complete. It covers purpose, authentication, usage guidance, and output content, which is sufficient for an AI agent to select and invoke this tool correctly without needing further explanation of return values due to the output schema.

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?

The input schema has 0 parameters with 100% coverage, so the schema fully documents the lack of inputs. The description doesn't need to add parameter details, but it implicitly confirms no inputs are required by focusing on the output, which is appropriate. A baseline of 4 is given as it compensates adequately for the zero-parameter case.

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 the verb 'List' and resource 'available Disco plans with pricing,' distinguishing it from siblings like discovery_purchase_credits or discovery_subscribe that involve transactions. It specifies the scope as 'all available subscription tiers with credit allowances and pricing,' making the purpose explicit and distinct.

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 'Use this to help users choose a plan,' providing clear context for when to invoke this tool. It also mentions 'No authentication required,' which implicitly distinguishes it from tools like discovery_login or discovery_account that require authentication, offering guidance on alternatives.

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

discovery_loginA
Idempotent
Inspect

Get a new API key for an existing Disco account.

Sends a 6-digit verification code to the email address. Call
discovery_login_verify with the code to receive a new API key.
Use this when you need an API key for an account that already exists
(e.g. the key was lost or this is a new agent session).

Returns 404 if no account exists with this email — use discovery_signup instead.

Args:
    email: Email address of the existing account.
ParametersJSON Schema
NameRequiredDescriptionDefault
emailYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.7/5.0
Behavior4/5

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

The description adds valuable behavioral context beyond annotations: it explains the verification flow (sends a 6-digit code, requires follow-up with discovery_login_verify), specifies error conditions (404 if account doesn't exist), and clarifies use cases (lost key or new agent session). Annotations cover idempotency and non-destructiveness, but the description enriches this with practical workflow details.

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 well-structured and front-loaded with the core purpose, followed by workflow details, usage guidelines, and parameter explanation. Every sentence adds value without redundancy, making it efficient and easy to parse.

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 (authentication flow with verification), the description is complete: it covers purpose, workflow, error handling, alternatives, and parameter semantics. With annotations providing safety hints and an output schema presumably handling return values, no critical gaps remain.

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?

With 0% schema description coverage, the description fully compensates by explaining the 'email' parameter's purpose ('Email address of the existing account'). It adds semantic meaning that the schema lacks, though it doesn't detail format constraints like email validation rules.

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 the specific action ('Get a new API key for an existing Disco account') and distinguishes it from sibling tools by explicitly mentioning when to use discovery_signup instead. It provides a verb+resource combination that is precise and differentiated.

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 this tool ('Use this when you need an API key for an account that already exists') and when not to ('Returns 404 if no account exists with this email — use discovery_signup instead'). It also references the alternative tool discovery_login_verify for the next step, providing comprehensive guidance.

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

discovery_login_verifyA
Idempotent
Inspect

Complete login and receive a new API key.

Call this after discovery_login returns {"status": "verification_required"}.
The user receives a 6-digit code by email — pass it here along with the
same email address. Returns a new API key on success.

Args:
    email: Email address used in the discovery_login call.
    code: 6-digit verification code from the email.
ParametersJSON Schema
NameRequiredDescriptionDefault
emailYes
codeYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior4/5

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

Annotations indicate non-destructive and idempotent behavior, which the description doesn't contradict. The description adds valuable context beyond annotations: it explains the verification process (6-digit code from email), specifies the expected input (same email as previous call), and mentions the output (new API key on success). However, it doesn't detail error cases or rate limits.

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 front-loaded with the main purpose, followed by usage guidelines and parameter details in a structured 'Args' section. Every sentence adds value without redundancy, making it efficient and easy to parse.

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?

Given the tool's complexity (authentication flow with verification), annotations cover safety aspects, and an output schema exists (so return values are documented elsewhere). The description provides good context on when and how to use it, parameter meanings, and the expected outcome. It could be more complete by mentioning error handling or dependencies, but it's largely adequate.

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 description coverage is 0%, so the description carries the full burden. It explains both parameters: 'email' as the address used in the previous call and 'code' as the 6-digit verification code from email. This adds clear meaning beyond the schema's basic types, though it could specify format constraints (e.g., email validation, code length).

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 the specific action ('Complete login and receive a new API key'), distinguishes it from sibling tools like 'discovery_login' by specifying it's called after that tool returns a verification status, and identifies the resource involved (API key). It's not a tautology and provides clear differentiation.

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 this tool ('Call this after discovery_login returns {"status": "verification_required"}') and provides clear prerequisites (user receives a 6-digit code by email). It distinguishes it from the sibling 'discovery_login' by specifying the workflow sequence, though it doesn't mention other alternatives explicitly, but the context is sufficiently detailed.

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

discovery_purchase_creditsA
Destructive
Inspect

Purchase Disco credit packs using a stored payment method.

Credits cost $0.10 each, sold in packs of 100 ($10/pack). Credits are used
for private analyses (public analyses are free). Requires a payment method
on file — use discovery_add_payment_method first.

Args:
    packs: Number of 100-credit packs to purchase. Default 1.
    api_key: Disco API key (disco_...). Optional if DISCOVERY_API_KEY env var is set.
ParametersJSON Schema
NameRequiredDescriptionDefault
packsNo
api_keyNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.7/5.0
Behavior4/5

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

Annotations indicate destructiveHint=true and idempotentHint=false, but the description adds valuable context beyond this: it specifies the cost ($0.10 per credit, $10 per pack), clarifies that credits are used for private analyses (with public ones free), and mentions the optional API key with environment variable fallback. This enriches understanding without contradicting annotations.

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 well-structured and front-loaded with the core purpose, followed by pricing details, usage context, prerequisites, and parameter explanations. Every sentence adds value—no fluff or repetition—making it efficient and easy for an agent to parse quickly.

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 (a purchase operation with financial implications), the description is complete: it covers purpose, pricing, usage context, prerequisites, and parameters. With an output schema present, return values need not be explained, and annotations handle destructive/idempotent hints, so no gaps remain for effective agent use.

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 description coverage is 0%, so the description must compensate. It effectively explains both parameters: 'packs' is defined as 'Number of 100-credit packs to purchase' with a default, and 'api_key' is clarified as optional with an env var alternative. This adds essential meaning beyond the bare schema, though it could note data types or constraints more explicitly.

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 the specific action ('Purchase Disco credit packs') and resource ('using a stored payment method'), distinguishing it from siblings like discovery_add_payment_method (which sets up payment) and discovery_analyze (which uses credits). It specifies the purpose is for buying credits, not other account actions.

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?

It explicitly states when to use this tool ('Purchase Disco credit packs') and provides clear prerequisites ('Requires a payment method on file — use discovery_add_payment_method first'). It also distinguishes usage context by noting credits are for private analyses (public ones are free), guiding the agent away from unnecessary purchases.

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

discovery_signupA
Idempotent
Inspect

Create a Disco account and get an API key.

Provide an email address to start the signup flow. If email verification
is required, returns {"status": "verification_required"} — the user will
receive a 6-digit code by email, then call discovery_signup_verify to
complete signup and receive the API key. The free tier (10 credits/month,
unlimited public runs) is active immediately. No authentication required.

Returns 409 if the email is already registered.

Args:
    email: Email address for the new account.
    name: Display name (optional — defaults to email local part).
ParametersJSON Schema
NameRequiredDescriptionDefault
emailYes
nameNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.7/5.0
Behavior4/5

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

Annotations provide destructiveHint=false and idempotentHint=true, but the description adds valuable behavioral context beyond this: it explains the verification flow with specific return values, mentions the free tier details, notes the 409 conflict response for existing emails, and clarifies authentication requirements. No contradiction with annotations.

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 efficiently structured with clear sections: purpose, process flow, tier details, authentication note, error case, and parameter explanations. Every sentence adds value without redundancy, and key information is front-loaded.

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 (signup with verification flow), the description is comprehensive: it covers purpose, usage flow, behavioral details, parameters, and error cases. With an output schema present, it appropriately omits detailed return value explanations, focusing on process context.

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?

With 0% schema description coverage, the description compensates well by explaining both parameters: 'email' is for the new account and 'name' is optional with a default behavior (defaults to email local part). This adds meaningful semantics beyond the bare schema.

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 the specific action ('Create a Disco account and get an API key') and distinguishes it from sibling tools like 'discovery_signup_verify' by explaining the verification flow. It explicitly names the resource (Disco account) and outcome (API key).

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 provides explicit guidance on when to use this tool (to start signup) and when to use an alternative ('discovery_signup_verify' for completing verification). It also states 'No authentication required' and mentions prerequisites like email verification, making usage context clear.

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

discovery_signup_verifyA
Idempotent
Inspect

Complete Disco signup using an email verification code.

Call this after discovery_signup returns {"status": "verification_required"}.
The user receives a 6-digit code by email — pass it here along with the
same email address used in discovery_signup. Returns an API key on success.

Args:
    email: Email address used in the discovery_signup call.
    code: 6-digit verification code from the email.
ParametersJSON Schema
NameRequiredDescriptionDefault
emailYes
codeYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.7/5.0
Behavior4/5

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

Annotations indicate non-destructive and idempotent behavior, which the description doesn't contradict. The description adds valuable context beyond annotations: it explains the verification flow (6-digit code from email), success outcome (returns API key), and prerequisite state from discovery_signup. However, it doesn't mention rate limits or auth needs explicitly.

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?

Well-structured and front-loaded: first sentence states purpose, second provides usage context, third explains parameters and outcome. Every sentence adds value with zero waste, and the bullet-point style for args enhances readability without verbosity.

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 moderate complexity (verification step), annotations cover safety/idempotency, and an output schema exists (so return values needn't be explained), the description is complete. It covers purpose, usage, parameters, and outcome adequately without redundancy.

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 description coverage is 0%, so the description must compensate. It adds meaningful semantics for both parameters: 'email' is described as 'Email address used in the discovery_signup call' (tying it to prerequisite), and 'code' as '6-digit verification code from the email' (specifying format and source). This goes beyond the bare schema, though it doesn't detail validation rules.

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 the specific action ('Complete Disco signup using an email verification code'), identifies the resource (signup process), and distinguishes it from sibling tools by referencing discovery_signup as a prerequisite. It goes beyond restating the name/title by explaining the verification mechanism.

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?

Explicitly states when to use this tool ('Call this after discovery_signup returns {"status": "verification_required"}'), provides a clear prerequisite, and distinguishes it from alternatives by specifying it's for verification after signup. No misleading or missing guidance.

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

discovery_statusA
Read-only
Inspect

Check the status of a Disco run.

Returns current status and progress details:
- status: "pending" | "processing" | "completed" | "failed"
- job_status: underlying job queue status
- queue_position: position in queue when pending (1 = next up)
- current_step: active pipeline step (preprocessing, training, interpreting, reporting)
- estimated_seconds: estimated total processing time in seconds
- estimated_wait_seconds: estimated queue wait time in seconds (pending only)

Poll this after calling discovery_analyze — runs typically take 3–15 minutes.
Use discovery_get_results to fetch full results once status is "completed".

Args:
    run_id: The run ID returned by discovery_analyze.
    api_key: Disco API key (disco_...). Optional if DISCOVERY_API_KEY env var is set.
ParametersJSON Schema
NameRequiredDescriptionDefault
run_idYes
api_keyNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

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

The description adds valuable behavioral context beyond the readOnlyHint annotation: it specifies this is a polling tool for monitoring asynchronous runs, describes typical processing times (3-15 minutes), and explains the relationship with other tools in the workflow. No contradiction with the read-only annotation exists.

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?

Perfectly structured and concise: purpose statement first, detailed return value documentation, clear usage guidelines, and parameter explanations. Every sentence adds essential information with zero wasted words.

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 (asynchronous status checking), the description provides complete context: purpose, detailed return values (making output schema redundant), workflow integration, parameter explanations, and behavioral expectations. The readOnlyHint annotation covers safety, and the description fills all other gaps.

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

Parameters3/5

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

With 0% schema description coverage, the description compensates by explaining both parameters: run_id ('The run ID returned by discovery_analyze') and api_key ('Optional if DISCOVERY_API_KEY env var is set'). However, it doesn't provide format details or constraints beyond what's implied, leaving some semantic gaps.

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 the tool's purpose with specific verb ('Check') and resource ('status of a Disco run'), distinguishing it from siblings like discovery_analyze (which initiates runs) and discovery_get_results (which fetches completed results). It provides a complete functional definition.

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 guidance is provided: 'Poll this after calling discovery_analyze' (when to use), 'Use discovery_get_results to fetch full results once status is "completed"' (alternative tool for next step), and context about typical runtime (3-15 minutes). This clearly defines the tool's role in the workflow.

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

discovery_subscribeA
DestructiveIdempotent
Inspect

Subscribe to or change your Disco plan.

Available plans:
- "free_tier": Explorer — free, 10 credits/month
- "tier_1": Researcher — $49/month, 50 credits/month
- "tier_2": Team — $199/month, 200 credits/month

Paid plans require a payment method on file. Credits roll over on paid plans.

Args:
    plan: Plan tier ID ("free_tier", "tier_1", or "tier_2").
    api_key: Disco API key (disco_...). Optional if DISCOVERY_API_KEY env var is set.
ParametersJSON Schema
NameRequiredDescriptionDefault
planYes
api_keyNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior4/5

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

Annotations provide destructiveHint=true (indicating a state-changing operation) and idempotentHint=true (safe to retry). The description adds valuable context beyond this: it specifies that paid plans require a payment method, credits roll over on paid plans, and the api_key can be omitted if set via environment variable. This clarifies authentication needs and billing implications.

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 well-structured and front-loaded with the core purpose, followed by plan details and parameter explanations. Every sentence earns its place by providing critical information without redundancy, making it efficient and easy to parse.

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 (subscription management with billing implications), the description is complete. It covers purpose, plans, requirements, and parameters. With annotations covering safety aspects and an output schema present (though not detailed here), no significant gaps remain for agent usage.

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?

Schema description coverage is 0%, so the description fully compensates by explaining both parameters. It defines the 'plan' parameter with specific tier IDs and their details (names, prices, credits), and clarifies that 'api_key' is optional if DISCOVERY_API_KEY is set. This adds essential meaning not in the schema.

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 the tool's purpose: 'Subscribe to or change your Disco plan.' It specifies the verb ('Subscribe to or change') and resource ('Disco plan'), and distinguishes it from sibling tools like discovery_list_plans (which lists plans) or discovery_add_payment_method (which handles payment setup).

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 provides clear context for when to use this tool by listing available plans and noting that paid plans require a payment method. It implies usage for subscription management but doesn't explicitly state when not to use it or name alternatives like discovery_purchase_credits for credit top-ups without plan changes.

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

discovery_uploadAInspect

Upload a dataset file and return a file reference for use with discovery_analyze.

Call this before discovery_analyze. Pass the returned result directly to
discovery_analyze as the file_ref argument.

Provide exactly one of: file_url, file_path, or file_content.

Args:
    file_url: A publicly accessible http/https URL. The server downloads it directly.
              Best option for remote datasets.
    file_path: Absolute path to a local file. Only works when running the MCP server
               locally (not the hosted version). Streams the file directly — no size limit.
    file_content: File contents, base64-encoded. For small files when a URL or path
                  isn't available. Limited by the model's context window.
    file_name: Filename with extension (e.g. "data.csv"), for format detection.
               Only used with file_content. Default: "data.csv".
    api_key: Disco API key (disco_...). Optional if DISCOVERY_API_KEY env var is set.
ParametersJSON Schema
NameRequiredDescriptionDefault
file_contentNo
file_nameNodata.csv
file_pathNo
file_urlNo
api_keyNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.8/5.0
Behavior4/5

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

The description adds valuable behavioral context beyond what annotations provide. While annotations only indicate it's non-destructive and non-idempotent, the description explains the tool's role in a workflow (precursor to discovery_analyze), provides practical constraints (size limits, context window limitations, local vs hosted server considerations), and clarifies authentication behavior (optional API key with fallback to env var). No contradiction with annotations exists.

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 well-structured and efficiently organized. It starts with the core purpose and workflow integration, then provides clear parameter guidance. Every sentence serves a specific purpose with no wasted words. The bullet-point style parameter explanations are particularly effective for readability.

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 (5 parameters, workflow integration, multiple input methods) and the presence of an output schema (which handles return value documentation), the description is complete. It covers purpose, workflow context, parameter semantics, behavioral constraints, and authentication - everything needed for an agent to use this tool correctly without needing to infer missing information.

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 0% schema description coverage, the description fully compensates by providing comprehensive semantic information for all parameters. It explains the purpose of each parameter, when to use which one, practical constraints, and default behavior. The description adds significant value beyond the bare schema, especially with the mutually exclusive guidance about providing exactly one of file_url, file_path, or file_content.

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 the specific action ('Upload a dataset file') and the resource ('dataset file'), and distinguishes it from sibling tools by explicitly mentioning its relationship with 'discovery_analyze'. It provides a clear verb+resource combination with contextual differentiation.

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 provides explicit guidance on when to use this tool ('Call this before discovery_analyze') and how to use the output ('Pass the returned result directly to discovery_analyze as the file_ref argument'). It also offers clear alternatives within the tool itself (file_url vs file_path vs file_content) with context about when each is appropriate.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 14 tool updatesv0.1.0
    • First observeddiscovery_account
    • First observeddiscovery_add_payment_method
    • First observeddiscovery_analyze
    • First observeddiscovery_estimate
    • First observeddiscovery_get_results
    • First observeddiscovery_list_plans
    • First observeddiscovery_login
    • First observeddiscovery_login_verify
    • First observeddiscovery_purchase_credits
    • First observeddiscovery_signup
    • First observeddiscovery_signup_verify
    • First observeddiscovery_status
    • First observeddiscovery_subscribe
    • First observeddiscovery_upload
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.7/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap. Account management (discovery_account, discovery_add_payment_method), authentication (discovery_login, discovery_login_verify, discovery_signup, discovery_signup_verify), analysis workflow (discovery_upload, discovery_estimate, discovery_analyze, discovery_status, discovery_get_results), and billing (discovery_list_plans, discovery_purchase_credits, discovery_subscribe) are all cleanly separated. An agent can easily distinguish between tools like discovery_analyze (run analysis) and discovery_estimate (check cost/time) despite both relating to analysis preparation.

Naming Consistency5/5

All 14 tools follow a perfect 'discovery_verb_noun' pattern with consistent snake_case throughout. The naming convention is highly predictable: discovery_account, discovery_analyze, discovery_estimate, discovery_get_results, discovery_list_plans, etc. This consistency makes the tool set immediately understandable and navigable.

Tool Count5/5

14 tools is ideal for this server's comprehensive scope covering authentication, data upload, analysis execution, results retrieval, and billing management. Each tool serves a specific, necessary function in the end-to-end workflow. The count is neither too thin (missing critical operations) nor bloated (no redundant tools), perfectly matching the domain of a sophisticated data analysis platform.

Completeness5/5

The tool surface provides complete coverage for the Disco platform's domain. It includes full authentication flow (signup/login with verification), account management, billing operations (plans, payments, credits), data upload, analysis estimation, execution, status monitoring, and results retrieval. There are no dead ends or gaps—every logical step in the workflow has a corresponding tool, creating a coherent end-to-end experience.

Maintenance

ActivityActive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/leap-laboratories/discovery-engine'

If you have feedback or need assistance with the MCP directory API, please join our Discord server