Skip to main content
Glama

Disco

by com.leap-labs

discovery_upload

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
api_keyNo
file_urlNo
file_nameNodata.csv
file_pathNo
file_contentNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

TDQS

A4.8/5.0
Behavior4/5

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

Annotations provide only idempotentHint=false and destructiveHint=false, which are minimal. The description adds meaningful operational context: the server downloads URLs directly, file_path only works locally with no size limit, file_content is base64 with context window limits, and API key can come from an env var. This exceeds annotation coverage, though it doesn't detail failure behaviors or retry semantics.

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 action and workflow, then provides a clean bulleted list for parameters. Each sentence adds value without redundancy, and the format is easy to scan.

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?

With five parameters and an output schema present, the description covers the full workflow: upload prerequisites (API key), three mutually exclusive input modes, filename behavior, and the intended use of the returned file reference. It is complete for an AI agent to successfully invoke the tool.

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 coverage is 0% (no descriptions in input schema), so the description must fully explain each parameter. It does: file_url, file_path, file_content, file_name (with default and usage constraint), and api_key (optional if env var set). Every parameter is addressed with usage context and 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 uses a specific verb and resource: 'Upload a dataset file and return a file reference for use with discovery_analyze.' This clearly distinguishes it from sibling tools like discovery_analyze and discovery_get_results, stating both the action and its downstream purpose.

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?

Provides explicit call order: 'Call this before discovery_analyze. Pass the returned result directly to discovery_analyze as the file_ref argument.' It also gives guidance on choosing between file_url, file_path, and file_content based on context (remote vs local, size limits), making alternatives clear.

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

All Disco toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation5/5

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

Naming Consistency5/5

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

Tool Count5/5

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

Completeness4/5

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

Resources