Disco
Server Details
Find novel, statistically validated patterns in tabular data — hypothesis-free.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- leap-laboratories/discovery-engine
- GitHub Stars
- 6
- Server Listing
- Disco
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.7/5 across 14 of 14 tools scored. Lowest: 3.7/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.
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.
14 tools cover account management, analysis pipeline, and billing without unnecessary redundancy. The scope is well-matched to the server's purpose.
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.
Available Tools
14 toolsdiscovery_accountARead-onlyInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, consistent with checking. Description adds details on returned data (credits, plan, payment) and mentions optional API key with env var fallback.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences with the main purpose front-loaded. The Args section is slightly redundant but not excessive; overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, description covers key return fields and usage context. Covers parameter and environment variable handling well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description adds full parameter meaning: explains the format (disco_...), optionality, and environment variable fallback. This compensates completely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks 'Disco account status' and lists specific returns: current plan, available credits, and payment method status. This differentiates from siblings like discovery_status and discovery_analyze.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'verify you have sufficient credits before running a private analysis.' No mention of when not to use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
discovery_add_payment_methodAIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | ||
| payment_method_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (idempotentHint=true, destructiveHint=false), the description adds critical behavioral details: card details never touch Disco's servers, payment must be tokenized via Stripe first, and the format of the API key. This fully informs the agent of side effects and prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct and well-structured with a clear introductory sentence, role context, a note on tokenization, and an Args section. Every sentence adds value, and there is no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description covers prerequisites (Stripe tokenization), how to obtain the payment method ID, optional API key sourcing, and the relationship to other actions (purchasing credits/subscribing). An output schema exists, so omitting return details is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description compensates by detailing both parameters: payment_method_id is a Stripe ID (pm_...) and api_key is a Disco API key (disco_...) with an optional environment variable fallback. This adds substantial meaning beyond the schema's type and title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Attach a Stripe payment method to your Disco account.' It uses a specific verb and resource, and distinguishes from sibling tools like discovery_purchase_credits or discovery_subscribe by indicating it is a prerequisite.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies when to use this tool with 'Required before purchasing credits or subscribing to a paid plan.' This provides clear context and implies that other tools (like purchase or subscribe) should be used after this one. No explicit alternatives are named, but the prerequisite relationship is strong guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
discovery_analyzeADestructiveInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | ||
| author | No | ||
| api_key | No | ||
| file_ref | No | ||
| use_llms | No | ||
| source_url | No | ||
| visibility | No | public | |
| description | No | ||
| target_column | Yes | ||
| analysis_depth | No | ||
| excluded_columns | No | ||
| column_descriptions | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations. It states it's a long-running operation that returns a run_id immediately, and details the publish/subscribe nature (public runs free but published, private costs credits, report URLs require sign-in). Annotations indicate destructiveHint: true, and description confirms mutation by creating a run.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, then provides critical information on what it is not, operational details, prerequisites, and parameter descriptions. Every sentence adds value without being verbose. The structure is logical and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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, long-running, pricing, and integration with other tools), the description covers everything needed: prerequisites (discovery_upload), cost estimation (discovery_estimate), result retrieval (discovery_status, discovery_get_results), and parameter details. Even without output schema shown, it explains return of run_id and the polling process.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description provides clear explanations for all 12 parameters. For example, it explains 'column_descriptions: significantly improves pattern explanations', 'use_llms: slower and more expensive...', and 'analysis_depth: search depth (1=fast, higher=deeper)'. This adds substantial meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Run Disco on tabular data to find novel, statistically validated patterns.' It uses specific verbs and resources, and distinguishes from sibling tools like discovery_status and discovery_get_results by explaining the pipeline workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool ('go beyond answering questions...') and when not to ('Do NOT use this for summary statistics, visualization, or SQL queries'). It also provides step-by-step guidance: call discovery_upload first, then check cost with discovery_estimate, and poll with discovery_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
discovery_estimateARead-onlyInspect
Estimate the credits required to run a Disco analysis.
Returns `required_credits` for public (always 0) and private, with private
split by whether LLMs are enabled (use_llms=False is faster, use_llms=True
adds smarter preprocessing, literature context and a written summary).
Also returns per-visibility depth caps and accepted file formats. No
authentication required — when an API key is supplied, also returns the
caller's available credits.
Call this before discovery_analyze whenever cost or feasibility is unclear.
Args:
file_size_mb: Size of the dataset in megabytes.
num_columns: Number of columns in the dataset.
analysis_depth: Search depth (1=fast, higher=deeper). Used to compute the
private-run cost. Default 2.
api_key: Disco API key (disco_...). Optional. When provided, the response
includes `account.available_credits`.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | ||
| num_columns | Yes | ||
| file_size_mb | Yes | ||
| analysis_depth | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses read-only nature (matches readOnlyHint), no authentication needed, and describes returned fields including per-visibility caps and account credits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections, though slightly verbose; each sentence adds value but could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description adequately covers return values, error conditions, and authentication behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description fully explains all 4 parameters: file_size_mb, num_columns, analysis_depth (default 2), and optional api_key.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool estimates credits required for a Disco analysis, distinguishing it from sibling tools like discovery_analyze.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to call this before discovery_analyze when cost or feasibility is unclear, and explains when public vs private costs apply.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
discovery_get_resultsARead-onlyInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| run_id | Yes | ||
| api_key | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, consistent with description. Description adds rich behavioral details: lists returned components (patterns, feature importance, summary, etc.) and internal structure like dashboard_urls with specific page links. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections, bullet points, and bold emphasis. Key information is front-loaded (purpose, ordering constraint). Every sentence adds value; the dashboard URLs breakdown is detailed but justified by complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and the tool returns a complex result set, the description provides comprehensive context: lists all major response components, explains the dashboard_urls object, and specifies prerequisite conditions. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, description fully documents both parameters: run_id (origin from discovery_analyze) and api_key (with note about optionality and env var). This adds complete semantic context beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches full results of a completed Disco run, using specific verbs ('Fetch') and resource ('completed Disco run'). It distinguishes from sibling tools like discovery_status (which checks completion) and discovery_analyze (which initiates analysis).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises 'Only call this after discovery_status returns "completed"', providing clear when-to-use and ordering constraints. Also explains optional api_key and env var fallback, guiding proper invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
discovery_list_plansARead-onlyInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true; description adds 'No authentication required' and details about return content (subscription tiers, credit allowances, pricing), enriching behavioral understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, every sentence adds value: purpose, auth requirement, return content, usage advice. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, existing annotations, and presence of output schema, the description fully informs an agent about what the tool does, its safety profile, and when to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, schema coverage is 100%, baseline is 4. Description adds no parameter info as none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'List' and resource 'Disco plans with pricing', clearly distinguishing this tool from siblings like discovery_login or discovery_analyze.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use this to help users choose a plan' and notes 'No authentication required', providing clear usage context. Lacks explicit when-not-to-use but sibling differentiation is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
discovery_loginAIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that it sends a 6-digit verification code to the email, indicating a side effect. However, annotations set idempotentHint=true, which contradicts this behavior (each call sends a new code, not idempotent). This is a clear annotation contradiction, so the score is 1 as per rules.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-sentence purpose, then process overview, usage context, error handling note, and explicit Args. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one parameter, an output schema (not shown but present), and clear error handling, the description provides sufficient context. It covers the two-step process and alternative tool usage, making it complete for agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully explains the single parameter 'email' as 'Email address of the existing account.' This adds essential meaning beyond the schema's type-only definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it obtains a new API key for an existing Disco account, distinguishing it from discovery_signup (new accounts) and discovery_login_verify (verification step). The verb 'get' combined with resource 'API key' and context of existing account makes the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (key lost, new agent session) and when not to use (404 indicates no account, use discovery_signup instead). It also mentions the required next step (call discovery_login_verify). This provides excellent guidance for tool selection and invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
discovery_login_verifyAIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | ||
| Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotent and non-destructive. The description adds that it returns a new API key on success, which is key behavioral info. It doesn't contradict annotations and provides useful context about the two-step login flow.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three short paragraphs. The first line summarizes the action, followed by context and explicit Args section. Every sentence is purposeful with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (two required params, part of a two-step flow), the description covers all necessary information: prerequisite, inputs, output (new API key). The presence of an output schema supports this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has no descriptions (0% coverage), but the description explains both parameters: email is the same as used in discovery_login, code is the 6-digit verification code from email. This adds essential meaning beyond type strings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: complete login and receive a new API key. It specifies the prerequisite condition (after discovery_login returns verification_required) and distinguishes from siblings like discovery_login and discovery_signup_verify.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool (after verification_required response) and provides step-by-step guidance (user receives email code, pass it with email). It doesn't explicitly state when not to use or alternatives, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
discovery_purchase_creditsADestructiveInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| packs | No | ||
| api_key | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set destructiveHint=true, indicating a financial transaction. The description adds detail about the cost structure ($0.10/credit, $10/pack) and the need for a payment method, which gives the agent a clear understanding of the impact. No contradictions 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using a clear structure with a brief introductory sentence, bullet points in 'Args:', and no redundant information. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (financial transaction, credit system), the description covers the purpose, cost, prerequisite, default parameter values, and alternative API key provision. Since there is an output schema, it is acceptable not to describe return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description fully compensates by documenting both parameters: 'packs' is explained as number of 100-credit packs with default 1, and 'api_key' is described with its format and fallback to environment variable. This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool purchases Disco credit packs using a stored payment method, which is a specific verb+resource. It distinguishes itself from sibling tools like discovery_add_payment_method and discovery_analyze by focusing on purchasing credits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context for when to use the tool, including the prerequisite of having a payment method on file, and explains credit cost and usage. It does not provide explicit when-not-to-use instructions or alternatives, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
discovery_signupAIdempotentInspect
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).
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses behavioral traits beyond annotations: email verification flow, 6-digit code, API key retrieval, free tier activation, and 409 response for duplicates. No contradiction with idempotentHint or destructiveHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with summary, flow, and parameter details. Slightly verbose but every sentence adds value; could be slightly more concise without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers signup flow, expected responses (verification_required, 409), and ties to sibling tools. With output schema existing, description provides sufficient context for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Compensates for 0% schema description coverage by explaining email is for starting signup flow and name is optional with a default. Adds meaning that is not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool creates a Disco account and obtains an API key. It distinguishes from sibling tools like discovery_login and discovery_signup_verify by detailing the signup flow and verification steps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit context on when to use (sign up), prerequisites (no auth), and when not to (email already registered leads to 409). Also mentions alternative flow for verification using discovery_signup_verify.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
discovery_signup_verifyAIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | ||
| Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide idempotency and non-destructive hints. The description adds context about the flow, return of an API key, and parameter roles. It could mention error behavior, but given annotation coverage, it is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: first sentence states purpose, followed by prerequisite, user action, return value, and parameter clarifications. No redundant sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple verification tool with two required parameters and an output schema, the description covers all necessary context: when to use, what to pass, what to expect. It is complete and actionable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully explains both parameters: email is from the signup call, code is the 6-digit verification code, adding meaning beyond property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool completes a signup using an email verification code, and explicitly links it to the discovery_signup process, distinguishing it from siblings like discovery_signup or discovery_login_verify.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit prerequisite: 'Call this after discovery_signup returns {"status": "verification_required"}.' It also instructs to use same email and 6-digit code, guiding correct parameter reuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
discovery_statusARead-onlyInspect
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_wait_seconds: estimated queue wait time in seconds (pending only)
Poll this after calling discovery_analyze.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| run_id | Yes | ||
| api_key | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description discloses return fields, status values, and polling behavior. Annotations already indicate readOnlyHint=true, and description adds detailed behavioral context without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with front-loaded purpose, structured into clear sections, and every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's polling nature, description covers when to use, what it returns, parameter details, and references to sibling tools. Output schema exists, so return details are adequately addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but description fully documents both parameters, including purpose of run_id and optionality of api_key with env var fallback, adding significant meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool checks status of a Disco run, with specific verb and resource. Sibling tools like discovery_analyze and discovery_get_results are differentiated by usage guidance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to poll after discovery_analyze and to use discovery_get_results once completed, providing clear when-to-use and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
discovery_subscribeADestructiveIdempotentInspect
Subscribe to or change your Disco plan.
Available plans:
- "free_tier": Explorer — free, 10 credits/month
- "tier_1": Researcher — $49/month, 500 credits/month
- "tier_2": Team — $199/month, 2000 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.
| Name | Required | Description | Default |
|---|---|---|---|
| plan | Yes | ||
| api_key | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include idempotentHint and destructiveHint, which already indicate state modification and idempotency. The description adds that paid plans require a payment method and credits roll over, offering some behavioral context. But it does not fully disclose consequences like proration or downgrade effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a leading sentence, a bullet list, and an Args section. It is reasonably concise, though the plan IDs are repeated in both the list and the parameter description, causing slight redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the action, plans, payment requirement, and parameter details. With an existing output schema, return values are not required. However, it could be more complete by clarifying whether subscribing to free_tier cancels a paid plan and whether there are prorated charges.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description provides an 'Args' section that explains the 'plan' parameter with a list of valid IDs and the 'api_key' parameter with its optionality and format. This significantly adds meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Subscribe to or change your Disco plan.' with a specific verb and resource. It lists available plans, which helps specify the action. However, it does not explicitly differentiate from siblings like discovery_purchase_credits, though the sibling names suggest different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions that paid plans require a payment method and credits roll over, providing some usage context. However, it does not explicitly guide when to use this tool versus alternatives (e.g., for one-time credit purchases), leaving the agent to infer.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | ||
| file_url | No | ||
| file_name | No | data.csv | |
| file_path | No | ||
| file_content | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide non-destructive hint but not idempotency. Description adds constraints on file sources and local-only file_path. Missing info on idempotency and potential side effects of repeated uploads.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Efficiently structured: purpose, then sequence, then parameter details. No redundant sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers parameter selection and chaining with discovery_analyze. Output schema exists, so return details are covered. Minor gap: no mention of error handling or size limits for URL downloads.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has zero description coverage; the description fully explains each parameter's usage, constraints, and best practices (e.g., file_path only locally, file_content limited by context).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Upload a dataset file'), the resource, and the output ('file reference for use with discovery_analyze'). It distinguishes itself from sibling tools like discovery_analyze.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call this before discovery_analyze and pass the result as file_ref. Also specifies the constraint of providing exactly one of file_url, file_path, or file_content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Your Connectors
Sign in to create a connector for this server.