The ENCODE Toolkit is a comprehensive genomics research server for searching, downloading, tracking, and analyzing ENCODE data through natural language, with integration across 14 databases.
Search & Discovery
Search ENCODE experiments with 20+ filters (assay type, organism, organ, biosample, ChIP target, life stage, treatment, date range, etc.)
Get full experiment details by accession, including files, quality metrics, replicates, and audit info
Search files across experiments with combined filters; explore data availability via faceted counts
Get valid filter values to avoid typos in searches
File Download & Management
Download files with MD5 verification and flexible directory organization (flat, by experiment, by format)
Batch search and download with dry-run preview mode
Securely manage ENCODE API credentials via OS keyring for accessing restricted datasets
Experiment Tracking & Citation
Track experiments locally in a SQLite database with publications, pipeline info, and notes
Compare experiments for compatibility (organism, assembly, assay, biosample, target mismatches)
Export tracked data as CSV/TSV/JSON; generate BibTeX/RIS citations and publication-ready methods sections
Summarize your collection with statistics grouped by assay, target, organ, and lab
Provenance & Cross-Referencing
Log derived files with full audit trails (tool, parameters, source accessions)
View provenance chains tracing derived files back to original ENCODE sources
Link external references (PubMed, DOI, bioRxiv, GEO, ClinicalTrials.gov NCT IDs) to tracked experiments
Cross-Database Integration & Analysis
Access 14 databases including GTEx, ClinVar, GWAS Catalog, JASPAR, CellxGene, gnomAD, Ensembl, UCSC, GEO, PubMed, bioRxiv, ClinicalTrials.gov, and Open Targets
Run 7 Nextflow pipelines for ChIP-seq, ATAC-seq, RNA-seq, WGBS, Hi-C, DNase-seq, and CUT&RUN with ENCODE-standard QC
Access 47 guided skills covering quality assessment, regulatory analysis, multi-omics integration, variant annotation, motif analysis, and scientific writing
Installation: Available via Claude Code, pip, npx, or as a plugin for Claude Desktop, VS Code, Cursor, and Windsurf. Runs locally with encrypted credential storage and no telemetry.
Enables literature search and citation retrieval to cross-reference genomics experiments with scientific publications and track research provenance.
Search ENCODE, cross-reference 14 databases, run 7 analysis pipelines, and generate publication-ready methods — all from natural language in Claude Code.
Start from ENCODE but go everywhere: discover histone peaks, cross-reference with GWAS variants, check ClinVar pathogenicity, pull GTEx expression, analyze TF binding motifs from JASPAR, run pipelines, and generate publication-ready methods with full provenance — in one conversation.
If you use ENCODE-Toolkit, please cite:
Alex M. Mawla. (2026). ENCODE-Toolkit: an MCP server, Claude plugin, and skills suite for ENCODE genomic data access and analysis. Zenodo. https://doi.org/10.5281/zenodo.18917511
@software{mawla_2026_encode_toolkit,
author = {Mawla, Alex M.},
title = {ENCODE-Toolkit: an MCP server, Claude plugin, and skills suite for ENCODE genomic data access and analysis},
year = {2026},
publisher = {Zenodo},
doi = {10.5281/zenodo.18917511},
url = {https://doi.org/10.5281/zenodo.18917511}
}Related MCP server: BioLab MCP Server
Start a new Claude Code session and enter:
/plugin marketplace add ammawla/encode-toolkit
/plugin install encode-toolkitThat's it. All 20 tools, 47 skills, and the MCP connector are now available.
If you only need the 20 MCP tools without the 47 workflow skills:
claude mcp add encode -- uvx encode-toolkitnpx encode-toolkitOr in MCP client config: { "command": "npx", "args": ["encode-toolkit"] }
pip install encode-toolkitThen use encode-toolkit as the command in any MCP client configuration:
{
"mcpServers": {
"encode": {
"command": "encode-toolkit"
}
}
}Add to your claude_desktop_config.json:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"encode": {
"command": "uvx",
"args": ["encode-toolkit"]
}
}
}No installation needed when using
uvx. Just add the config and restart Claude.
Add to .vscode/mcp.json in your workspace:
{
"mcp": {
"servers": {
"encode": {
"command": "uvx",
"args": ["encode-toolkit"]
}
}
}
}Add to .cursor/mcp.json:
{
"mcpServers": {
"encode": {
"command": "uvx",
"args": ["encode-toolkit"]
}
}
}Add to .windsurf/mcp.json:
{
"mcpServers": {
"encode": {
"command": "uvx",
"args": ["encode-toolkit"]
}
}
}ENCODE Toolkit integrates 14 databases through live API tools and guided skills.
Database | Access Method | Use Case |
ENCODE | 20 MCP tools (live API) | ChIP-seq, ATAC-seq, RNA-seq, Hi-C, WGBS, CUT&RUN data |
GTEx | REST API (skill) | Tissue-specific gene expression across 54 tissues |
ClinVar | E-utilities (skill) | Variant clinical significance and pathogenicity |
GWAS Catalog | REST API (skill) | Trait-variant associations from genome-wide studies |
JASPAR | REST API (skill) | Transcription factor binding motif profiles |
CellxGene | Census API (skill) | Single-cell expression atlas across tissues |
gnomAD | GraphQL (skill) | Population allele frequencies and gene constraint |
Ensembl | REST API (skill) | VEP annotation, Regulatory Build, coordinate liftover |
UCSC Genome Browser | REST API (skill) | cCRE tracks, TF clusters, sequence retrieval |
GEO | E-utilities (skill) | Complementary expression/epigenomic datasets |
PubMed | MCP server | Literature search and citation |
bioRxiv | MCP server | Preprint discovery |
ClinicalTrials.gov | MCP server | Clinical trial cross-reference |
Open Targets | MCP server | Drug target identification |
"Find all histone ChIP-seq experiments for human pancreas tissue"
"What ATAC-seq data is available for mouse brain?"
"Search for RNA-seq on GM12878 cell line"
"What histone marks have ChIP-seq data for pancreas?"
"Download all BED files from ENCSR133RZO to ~/data/encode"
"Track experiment ENCSR133RZO with its publications"
"Export citations for my tracked experiments as BibTeX"
"What GWAS variants overlap islet enhancers?"
"Check ClinVar pathogenicity for rs7903146"
"Pull GTEx expression for TCF7L2 across tissues"
"Find JASPAR motifs for HNF4A binding sites"
"Set up a ChIP-seq pipeline for my H3K27ac experiments"
"Run ATAC-seq analysis with ENCODE-standard QC thresholds"
"Log that I created filtered_peaks.bed from ENCSR133RZO using bedtools"
"Generate a methods section for my analysis with citations"
"Show me the full details for experiment ENCSR133RZO"
"What files are available for ENCSR133RZO?"
"List only the BED files from ENCSR133RZO"
"Download all FASTQs from human pancreas ChIP-seq to /data/fastqs"
"Get the IDR thresholded peaks from these experiments"
"Download the bigWig signal tracks for H3K27me3 in GRCh38"
"Are experiments ENCSR133RZO and ENCSR000AKS compatible for combined analysis?"
"Compare these two ChIP-seq experiments"
"Show me the provenance chain for my derived files"
"What files have I derived from ENCSR133RZO?"
Using genomics databases today means:
Navigate web portals, click through dozens of filters
Manually find the right experiments and files across multiple databases
Write custom scripts to batch download
Lose track of which files came from where
With ENCODE Toolkit, just tell Claude what you need:
"Find all histone ChIP-seq data for human pancreas tissue"
Claude searches ENCODE, returns a structured table of 66 experiments with targets, replicates, and file counts. Downloads are organized by experiment with MD5 verification and full provenance tracking.
Five core tools are shown below. The remaining 15 are collapsed for readability.
encode_search_experimentsSearch ENCODE experiments with 20+ filters.
Parameter | Type | Description |
| string | Assay type: "Histone ChIP-seq", "ATAC-seq", "RNA-seq", "Hi-C", etc. |
| string | Species (default: "Homo sapiens") |
| string | Organ: "pancreas", "brain", "liver", "heart", "kidney", etc. |
| string | "tissue", "cell line", "primary cell", "organoid" |
| string | ChIP target: "H3K27me3", "H3K4me3", "CTCF", etc. |
| string | Specific biosample: "GM12878", "HepG2", etc. |
| int | Max results (default: 25) |
encode_get_experimentGet full details for a single experiment including all files, quality metrics, and audit info.
Parameter | Type | Description |
| string | Experiment ID (e.g., "ENCSR133RZO") |
encode_download_filesDownload specific files by accession to a local directory.
Parameter | Type | Description |
| list[str] | File IDs to download (e.g., ["ENCFF635JIA"]) |
| string | Local path to save files |
| string | "flat", "experiment", "format", "experiment_format" |
| bool | Verify file integrity (default: true) |
encode_batch_downloadSearch + download in one step. Runs in preview mode by default.
Parameter | Type | Description |
| string | Local path to save files |
| string | File format to download |
| string | Assay type filter |
| string | Organ filter |
| bool | Preview only (default: true). Set false to download. |
encode_track_experimentTrack an experiment locally with its publications, methods, and pipeline info.
Parameter | Type | Description |
| string | Experiment ID to track |
| bool | Fetch associated publications (default: true) |
| bool | Fetch pipeline/analysis info (default: true) |
| string | Optional notes to attach |
encode_list_filesList files for a specific experiment with format/type filters.
Parameter | Type | Description |
| string | Experiment ID |
| string | "fastq", "bam", "bed", "bigWig", "bigBed", etc. |
| string | "reads", "peaks", "signal", "alignments", etc. |
| string | "GRCh38", "mm10", etc. |
| bool | Only return recommended files |
encode_search_filesSearch files across all experiments with combined experiment + file filters.
Parameter | Type | Description |
| string | File format filter |
| string | Assay type of parent experiment |
| string | Organ of parent experiment |
| string | ChIP/CUT&RUN target |
| string | Output type filter |
| string | Genome assembly |
encode_get_metadataList valid filter values for any parameter.
Parameter | Type | Description |
| string | "assays", "organisms", "organs", "biosample_types", "file_formats", "output_types", "assemblies" |
encode_get_facetsGet live counts from ENCODE showing what data exists for given filters.
Parameter | Type | Description |
| string | Pre-filter by assay |
| string | Pre-filter by organism |
| string | Pre-filter by organ |
encode_get_file_infoGet detailed metadata for a single file.
Parameter | Type | Description |
| string | File ID (e.g., "ENCFF635JIA") |
encode_manage_credentialsStore, check, or clear ENCODE credentials for restricted data access.
Parameter | Type | Description |
| string | "store", "check", or "clear" |
| string | ENCODE access key (for "store") |
| string | ENCODE secret key (for "store") |
encode_list_trackedList all experiments in your local tracker with metadata, publication counts, and derived file counts.
Parameter | Type | Description |
| string | Filter by assay type |
| string | Filter by organism |
| string | Filter by organ |
encode_get_citationsGet publications for tracked experiments. Export as BibTeX or RIS for reference managers.
Parameter | Type | Description |
| string | Specific experiment (or all if omitted) |
| string | "json" (default), "bibtex", or "ris" |
encode_compare_experimentsAnalyze whether two experiments are compatible for combined analysis.
Parameter | Type | Description |
| string | First experiment ID |
| string | Second experiment ID |
encode_summarize_collectionGet grouped statistics of your tracked experiment collection.
Parameter | Type | Description |
| string | Filter by assay type |
| string | Filter by organism |
| string | Filter by organ |
encode_log_derived_fileLog a file you created from ENCODE data for provenance tracking.
Parameter | Type | Description |
| string | Path to your derived file |
| list[str] | ENCODE accessions this was derived from |
| string | What the file contains |
| string | Tool/software used |
| string | Command or parameters used |
encode_get_provenanceView provenance chains from derived files back to source ENCODE data.
Parameter | Type | Description |
| string | Get provenance for a specific file |
| string | List all files derived from an accession |
encode_export_dataExport tracked experiments as a table (CSV, TSV, or JSON) for Excel, R, pandas.
Parameter | Type | Description |
| string | "csv" (default), "tsv", or "json" |
| string | Filter by assay type |
encode_link_referenceLink external references (PubMed, bioRxiv, ClinicalTrials, GEO) to tracked experiments.
Parameter | Type | Description |
| string | ENCODE experiment accession |
| string | "pmid", "doi", "nct_id", "preprint_doi", "geo_accession", "other" |
| string | The identifier value |
encode_get_referencesGet external references linked to tracked experiments for cross-server workflows.
Parameter | Type | Description |
| string | Filter by experiment (optional) |
| string | Filter by type (optional) |
Most ENCODE data is public and requires no authentication. Just install and use.
For restricted/unreleased data, ask Claude: "Store my ENCODE credentials"
Credentials are encrypted using your OS keyring (macOS Keychain, Linux Secret Service, Windows Credential Locker) and never stored in plaintext. Get your access keys from your ENCODE profile.
When installed as a Claude Code plugin, ENCODE Toolkit includes 47 literature-backed workflow skills that guide Claude through complex genomics tasks. Each analysis skill includes evidence-based quality thresholds, assay-specific metrics, and citations to primary literature.
Skill | Description |
| Install and configure the ENCODE Toolkit server |
| Search and explore ENCODE experiments and files |
| Download files with organization and verification |
| Track experiments, citations, and provenance locally |
| Connect ENCODE data to PubMed, bioRxiv, ClinicalTrials.gov |
Skill | Description |
| Evaluate experiment quality using ENCODE metrics — assay-specific thresholds for ChIP-seq (FRiP, NSC, RSC, NRF, IDR), ATAC-seq (TSS enrichment, NFR ratio), RNA-seq (mapping rate, gene body coverage), WGBS (bisulfite conversion, CpG coverage), Hi-C (cis/trans ratio), and CUT&RUN/CUT&Tag. Backed by Landt 2012, Buenrostro 2013, ENCODE Phase 3 (2020), Li 2011 |
| Combine multiple experiments with batch effect awareness — integration strategies (peak overlap, signal correlation, DiffBind, DESeq2, ChromHMM, ABC model). Backed by Ernst & Kellis 2012, Ross-Innes 2012, Love 2014, Fulco 2019 |
| Discover enhancers, promoters, insulators from combinatorial histone marks — ENCODE cCRE classification (926,535 elements), ChromHMM state interpretation. Backed by ENCODE Phase 3 (2020), Roadmap Epigenomics (2015), Whyte 2013 |
| Build comprehensive chromatin state profiles — three-tiered histone panels, ChromHMM 15-state model, bivalent chromatin analysis. References the chromatin biology catalog |
| Compare experiments across tissues and cell types — biosample hierarchy, tissue-specific regulation, batch effect detection. Backed by Roadmap Epigenomics (2015), Leek 2010 |
| Generate publication-quality visualizations: genome browser tracks, heatmaps, and signal profiles |
| Discover and analyze TF binding motifs in regulatory regions using HOMER, MEME, and JASPAR |
| Annotate genomic peaks with features (promoter/enhancer/intergenic), nearest genes, and functional categories |
| Batch processing and QC screening across multiple ENCODE experiments with systematic quality filtering |
Skill | Description |
| Analyze CRISPR screens, MPRA, and STARR-seq data from ENCODE — MAGeCK, BAGEL2, MPRAflow integration |
Skill | Description |
| Union merge of histone ChIP-seq peaks across studies — signalValue-based noise filtering, sample-of-origin tagging, ENCODE blacklist removal. Backed by ChIP-Atlas (Oki 2018), Amemiya 2019, Perna 2024 |
| Union merge of ATAC-seq and DNase-seq peaks — cross-platform integration, peak summit preservation. Backed by Corces 2017, Amemiya 2019, Zhao 2020 |
| Union catalog of Hi-C chromatin loops (BEDPE) — resolution-aware anchor matching, loop caller concordance tracking. Backed by Loop Catalog (Reyna 2025), Mustache (Roayaei Ardakany 2020) |
| Aggregate WGBS methylation profiles — per-CpG weighted averaging, HMR/UMR/PMD identification. Backed by Schultz 2015, DMRcate (Peters 2021), Zhou 2020 |
Skill | Description |
| Cross-study meta-analysis of scRNA-seq data — reproducibility assessment, TIN-based quality filtering, ambient RNA quantification. Backed by Tran 2020, Luecken & Theis 2019, Stuart 2019, Korsunsky 2019 |
| Integrate RNA-seq, ATAC-seq, Histone ChIP-seq, and TF ChIP-seq — ABC model regulatory predictions, signal correlation. Backed by Fulco 2019, Corces 2018, ENCODE Phase 3 (2020) |
Skill | Description |
| Full reproducibility tracking — tool versions, reference files, scripts, exact commands, timestamps, source-to-derived provenance chains |
| Generate proper citations, BibTeX/RIS export, data availability statements |
| Annotate GWAS/disease variants with ENCODE functional data — variant-to-gene mapping via cCREs. Backed by Finucane 2015, Maurano 2012 |
| Understand ENCODE uniform analysis pipelines and output types — pipeline specifications, Nextflow integration |
| Work with scRNA-seq and scATAC-seq data — platform comparison, cross-study integration, WNN multimodal analysis. Backed by Hao 2021, Stuart 2019 |
| Disease-focused workflows — GWAS variant interpretation, disease-tissue mapping, heritability enrichment, drug target identification via Open Targets. Backed by Buniello 2019, Finucane 2015 |
| Publication integrity assessment — 5-level trust scoring, retraction/erratum detection, citation analysis. Integrates with PubMed, bioRxiv, and Consensus |
| Install all bioinformatics tools for ENCODE analyses — 7 conda environment YAMLs, 3 install scripts, 134+ tools across ChIP-seq, ATAC-seq, RNA-seq, WGBS, Hi-C, DNase-seq, CUT&RUN |
| Generate publication-ready methods sections, figure legends, supplementary tables, and data availability statements with full tool citations |
| Convert genomic coordinates between assembly versions (hg19/hg38, mm9/mm10) using UCSC liftOver, CrossMap, Ensembl REST API, and rtracklayer |
Skill | Description |
| Query GTEx tissue expression data via REST API for gene expression context across 54 tissues |
| Annotate variants with ClinVar clinical significance, pathogenicity, and review status |
| Query CellxGene single-cell atlas for cell type expression context across tissues |
| Search NHGRI-EBI GWAS Catalog for trait associations, risk alleles, and study metadata |
| Query JASPAR database for transcription factor binding motifs and matrix profiles |
| Ensembl VEP variant annotation, Regulatory Build, coordinate liftover, gene lookup via REST API |
| Search NCBI GEO for complementary datasets, cross-reference with ENCODE, FTP downloads |
| gnomAD population allele frequencies, gene constraint (LOEUF/pLI), structural variants via GraphQL |
| UCSC Genome Browser REST API for cCRE tracks, TF binding clusters, and sequence retrieval |
Pipeline | Assay | Aligner | Caller |
| ChIP-seq | BWA-MEM | MACS2 + IDR |
| ATAC-seq | Bowtie2 | MACS2 (Tn5-adjusted) |
| RNA-seq | STAR | RSEM + Kallisto |
| WGBS | Bismark | MethylDackel |
| Hi-C | BWA | Juicer + HiCCUPS |
| DNase-seq | BWA | Hotspot2 |
| CUT&RUN | Bowtie2 | SEACR |
Each pipeline includes a SKILL.md overview, 5-stage reference files (preprocessing through QC), a complete Nextflow DSL2 pipeline, a Dockerfile, and deployment configurations for local, SLURM, GCP, and AWS.
File | Description |
| Comprehensive chromatin biology catalog (1,442 lines) — 21 histone marks with writers/erasers/readers, 5 novel acylation marks, ChromHMM state models (5 to 51 states), TF co-binding patterns, chromatin remodeling complexes, DNA methylation-chromatin interplay, nucleosome dynamics, 3D genome organization, chromatin in disease. 74 primary references |
| 33 per-skill literature reference documents — ~250 papers cataloged with DOI, PMID, citation counts, and skill-relevant key findings |
Most genomics tools give you one thing. ENCODE Toolkit gives you the full research loop:
Capability | ENCODE Toolkit | Typical MCP servers |
Live database access | 20 tools across 14 databases | Single database, read-only |
Executable pipelines | 7 Nextflow DSL2 pipelines with Docker and cloud configs | None |
Provenance tracking | Full audit trail from source data to derived files | None |
Publication output | BibTeX/RIS citations, auto-generated methods sections | None |
Literature backing | 100+ primary references with assay-specific QC thresholds | None |
Workflow skills | 47 guided skills covering search to publication | Static documentation |
Category | Assays |
Histone/Chromatin | Histone ChIP-seq, TF ChIP-seq, ATAC-seq, DNase-seq, CUT&RUN, CUT&Tag, MNase-seq |
Transcription | RNA-seq, total RNA-seq, small RNA-seq, long read RNA-seq, CAGE, RAMPAGE, PRO-seq, GRO-seq |
3D Genome | Hi-C, intact Hi-C, Micro-C, ChIA-PET, HiChIP, PLAC-seq, 5C |
DNA Methylation | WGBS, RRBS, MeDIP-seq, MRE-seq |
Functional | STARR-seq, MPRA, CRISPR screen, eCLIP, iCLIP |
Single Cell | scRNA-seq, snATAC-seq, 10x multiome, SHARE-seq, Parse SPLiT-seq |
Perturbation | CRISPRi + RNA-seq, shRNA + RNA-seq, siRNA + RNA-seq |
Supported file formats: fastq bam bed bigWig bigBed tsv csv hic tagAlign bedpe pairs fasta vcf tar
100% local execution — no telemetry, no analytics, no tracking
Credentials encrypted at rest via OS keyring with Fernet fallback
Certificate verification enforced — no verify=False
Rate limited to respect ENCODE's 10 req/sec policy
MD5 verification on all downloads by default
No data leaves your machine except queries to public APIs over HTTPS
Step-by-step walkthroughs showing real Claude sessions, including actual API output and scientific interpretation.
Vignette | Skills Demonstrated |
Facets, search, metadata, quality-aware selection | |
File listing, download, tracking, citations, provenance | |
Histone marks, ATAC-seq, aggregation skills | |
GWAS catalog, ClinVar, GTEx, JASPAR, gnomAD | |
RNA-seq, scRNA-seq, GTEx, CellxGene, meta-analysis | |
TF ChIP-seq, chromatin states, HOMER/MEME | |
Hi-C loops, WGBS methylation, integrative analysis | |
ChIP-seq/ATAC-seq/RNA-seq pipelines, Nextflow | |
GEO, PubMed, Ensembl, UCSC, multi-omics |
Every skill has a dedicated vignette in docs/skill-vignettes/ with a complete example session. Highlights:
Skill | Vignette Scenario |
Download, blacklist-filter, liftover, auto-generate methods section | |
Union merge of H3K27ac across 5 pancreas experiments | |
rs7903146 in TCF7L2 with islet enhancer evidence scoring | |
Full Nextflow pipeline execution with ENCODE QC thresholds | |
T2D GWAS variants overlaid on islet H3K27ac enhancers | |
Trust assessment of artemisinin transdifferentiation claim | |
3-study islet integration following Mawla et al. 2019 framework |
See the full showcase for 15 detailed examples.
git clone https://github.com/ammawla/encode-toolkit.git
cd encode-toolkit
python -m venv .venv
source .venv/bin/activate
pip install -e ".[dev]"Run the server locally:
encode-toolkitRun tests:
pytestMake sure you restarted Claude Desktop after adding the config
Verify uvx is installed: pip install uv or curl -LsSf https://astral.sh/uv/install.sh | sh
Check your internet connection
ENCODE API rate limit is 10 requests/sec — the server handles this automatically
The file may require authentication. Ask Claude: "Store my ENCODE credentials"
Or check if the file status is "released" on encodeproject.org
Try broader filters (remove biosample_type or organ)
Use encode_get_facets to see what data actually exists for your filters
Use encode_get_metadata to check valid filter values
Dr. Alex M. Mawla, PhD
AGPL-3.0. See LICENSE for full terms.
For commercial licensing inquiries: ammawla@ucdavis.edu
Search for files and download them all in batch.
First searches for files matching the criteria, then downloads them. By default runs in dry_run mode to preview what would be downloaded. Set dry_run=False to actually download.
WHEN TO USE: Use for searching and downloading files in one step. Always use dry_run=True first to preview. For specific file accessions, use encode_download_files. RELATED TOOLS: encode_download_files, encode_search_files
Examples:
Download all BED files from human pancreas ChIP-seq: file_format="bed", assay_title="Histone ChIP-seq", organ="pancreas", download_dir="/data/encode", dry_run=False
Preview FASTQ downloads for mouse brain RNA-seq: file_format="fastq", assay_title="total RNA-seq", organ="brain", organism="Mus musculus", download_dir="/data/encode"
Download IDR peaks for H3K27me3 in GRCh38: output_type="IDR thresholded peaks", target="H3K27me3", assembly="GRCh38", download_dir="/data/encode", dry_run=False
Args: download_dir: Local directory to save files file_format: File format filter ("fastq", "bam", "bed", "bigWig", etc.) output_type: Output type filter ("reads", "peaks", "signal", etc.) output_category: Output category ("raw data", "alignment", "annotation", etc.) assembly: Genome assembly ("GRCh38", "mm10", etc.) assay_title: Assay type ("Histone ChIP-seq", "ATAC-seq", "total RNA-seq", etc.) organism: Organism (default: "Homo sapiens") organ: Organ/tissue ("pancreas", "brain", "liver", etc.) biosample_type: Biosample type ("tissue", "cell line", "primary cell", etc.) target: ChIP/CUT&RUN target ("H3K27me3", "CTCF", etc.) preferred_default: If True, only download default/recommended files organize_by: File organization ("flat", "experiment", "format", "experiment_format") verify_md5: Verify downloads with MD5 checksums (default True) limit: Max files to download (default 100, safety limit) dry_run: If True (default), only preview what would be downloaded. Set False to download.
Returns: JSON with download preview (dry_run=True) or download results (dry_run=False).
| Name | Required | Description | Default |
|---|---|---|---|
| download_dir | Yes | ||
| file_format | No | ||
| output_type | No | ||
| output_category | No | ||
| assembly | No | ||
| assay_title | No | ||
| organism | No | Homo sapiens | |
| organ | No | ||
| biosample_type | No | ||
| target | No | ||
| preferred_default | No | ||
| organize_by | No | experiment | |
| verify_md5 | No | ||
| limit | No | ||
| dry_run | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the two-step process (search then download) and the default dry_run mode. The annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=true) are consistent with the description's behavior: downloading is not read-only but is idempotent and not destructive. 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?
The description is comprehensive but slightly verbose. It includes a parameter list with repeated explanations; some could be shortened. However, it is well-structured with clear sections (purpose, behavior, when-to-use, examples, args) and front-loads key information.
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 (15 parameters, 1 required) and the presence of an output schema, the description covers all necessary aspects: purpose, behavior, when-to-use, examples, and parameter descriptions. The return value is described as 'JSON with download preview or download results.' No gaps.
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%, so the description fully compensates by explaining each parameter's meaning, default values, and example values (e.g., file_format='bed', assay_title='Histone ChIP-seq'). This adds significant value 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's purpose: 'Search for files and download them all in batch.' It uses specific verbs ('search and download') and resource ('files'). It distinguishes itself from siblings encode_download_files (for specific files) and encode_search_files (only search).
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: 'Use for searching and downloading files in one step.' Provides guidance to always use dry_run=True first. Names alternative tool for specific file accessions: 'use encode_download_files.' Lists related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze whether two ENCODE experiments are compatible for combined analysis.
Compares organism, genome assembly, assay type, biosample, organ, target, replication strategy, and lab to identify potential issues.
Both experiments must be tracked first (use encode_track_experiment).
WHEN TO USE: Use to check if two experiments are compatible for combined analysis. Both must be tracked first. RELATED TOOLS: encode_track_experiment, encode_list_tracked
Args: accession1: First experiment accession (e.g., "ENCSR133RZO") accession2: Second experiment accession (e.g., "ENCSR000AKS")
Returns: JSON compatibility report with verdict, issues, warnings, and recommendations.
| Name | Required | Description | Default |
|---|---|---|---|
| accession1 | Yes | ||
| accession2 | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only, idempotent, and non-destructive behavior. The description adds value by listing the compared fields (organism, genome assembly, etc.) and mentioning the output format, which are beyond what annotations provide.
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 concisely structured with a clear purpose, comparison details, prerequisites, usage guidance, and parameter documentation in a well-organized format 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?
The description covers prerequisites, parameter semantics, and what fields are compared. It references an output schema, which is sufficient given the existence of a structured output schema.
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 explains both parameters with examples (e.g., 'ENCSR133RZO') and context that they are accession strings of tracked experiments.
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: 'Analyze whether two ENCODE experiments are compatible for combined analysis.' It specifies the verb (analyze/compare) and resource (two experiments), and distinguishes from siblings by requiring prior tracking.
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 includes explicit 'WHEN TO USE' guidance and prerequisites: 'Use to check if two experiments are compatible for combined analysis. Both must be tracked first (use encode_track_experiment).' It also lists related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download specific ENCODE files by accession to a local directory.
Downloads files from ENCODE to your local machine. Supports MD5 verification, concurrent downloads, and skip-if-already-downloaded.
WHEN TO USE: Use for downloading specific files by accession. For bulk downloads, prefer encode_batch_download. RELATED TOOLS: encode_batch_download, encode_search_files, encode_log_derived_file
Args: file_accessions: List of file accessions to download (e.g., ["ENCFF635JIA", "ENCFF388RZD"]) download_dir: Local directory path to save files (e.g., "./data/encode") organize_by: How to organize downloaded files: - "flat": All files in download_dir (default) - "experiment": download_dir/ENCSR.../filename - "format": download_dir/bed/filename - "experiment_format": download_dir/ENCSR.../bed/filename verify_md5: Verify file integrity with MD5 checksum (default True)
Returns: JSON with download results for each file (path, size, success/error, MD5 status).
| Name | Required | Description | Default |
|---|---|---|---|
| file_accessions | Yes | ||
| download_dir | Yes | ||
| organize_by | No | flat | |
| verify_md5 | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses MD5 verification, concurrent downloads, and skip-if-already-downloaded behavior. Annotations indicate readOnlyHint false, destructiveHint false, idempotentHint true, openWorldHint true, with no contradictions. The description adds valuable context beyond 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 well-structured with a brief summary, detailed features, usage guidance, and a parameter list. It is concise, with no extraneous information, and each sentence adds value.
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 4 parameters, 0% schema coverage, output schema presence, and annotations, the description provides complete guidance: parameter details, return format, and behavioral traits. 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 description coverage, the description includes a detailed 'Args' section explaining each parameter with examples, defaults, and enum options for 'organize_by'. This fully compensates for the missing schema descriptions.
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 name and title clearly indicate downloading ENCODE files. The description specifies 'Download specific ENCODE files by accession to a local directory,' using a specific verb and resource, and distinguishes from sibling tools like encode_batch_download.
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 states 'WHEN TO USE: Use for downloading specific files by accession. For bulk downloads, prefer encode_batch_download.' It also lists related tools, providing clear guidance on when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export tracked experiments as a table (CSV, TSV, or JSON).
Creates a tabular export of all tracked experiments with metadata, publication counts, PMIDs, and derived file counts. Useful for loading into Excel, R, pandas, or sharing with collaborators.
PMIDs in the output can be directly used with PubMed MCP tools for further literature analysis.
WHEN TO USE: Use to create shareable tables of tracked experiments (CSV, TSV, JSON). Good for manuscripts and reports. RELATED TOOLS: encode_list_tracked, encode_summarize_collection
Args: format: Output format: - "csv": Comma-separated values (default, for Excel/spreadsheets) - "tsv": Tab-separated values (for R, pandas) - "json": JSON array (for programmatic use) assay_title: Filter by assay type (partial match) organism: Filter by organism (partial match) organ: Filter by organ (partial match)
Returns: Formatted table data in the requested format.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | csv | |
| assay_title | No | ||
| organism | No | ||
| organ | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, non-destructive, and idempotent. The description adds that the output includes specific fields, filters support partial matching, and that generated PMIDs are usable with PubMed MCP tools. However, it does not disclose potential export limits or pagination behavior.
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 sections for purpose, content details, usage context, related tools, parameters, and returns. Every sentence serves a purpose, and the most important information (what it exports and format options) appears first.
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 an output schema, the description adequately explains what the tool does, its parameters, and how results can be used. It covers filtering, format variants, and integration with other tools, making it sufficiently complete for an agent to understand and invoke 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?
The schema provides 4 parameters with no descriptions (0% coverage). The description compensates by explaining format options with use cases (csv for Excel, tsv for R/pandas, json for programmatic use) and clarifying that filter parameters use partial matching. This adds meaningful context 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 'Export tracked experiments as a table (CSV, TSV, or JSON)' and lists included metadata, publication counts, PMIDs, and derived file counts. It distinguishes from related tools like encode_list_tracked and encode_summarize_collection.
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 includes a 'WHEN TO USE' section ('Use to create shareable tables... for manuscripts and reports') and lists related tools. It explains the output's utility with PubMed MCP tools, but does not explicitly state when not to use or provide alternative selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get publications and citations for tracked experiments.
Returns publication data with authors, journal, DOI, PMID. Can export as BibTeX or RIS (Endnote/Zotero/Mendeley compatible).
WHEN TO USE: Use to get publication data for tracked experiments. Supports BibTeX and RIS export for reference managers. RELATED TOOLS: encode_track_experiment, encode_link_reference
Args: accession: Specific experiment accession. If None, returns all publications. export_format: Output format: - "json": Structured data (default) - "bibtex": BibTeX format for LaTeX - "ris": RIS format (Endnote, Zotero, Mendeley)
Returns: Publications in the requested format.
| Name | Required | Description | Default |
|---|---|---|---|
| accession | No | ||
| export_format | No | json |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, not destructive, and idempotent. The description adds context about return structure and export capabilities but does not disclose additional behavioral traits beyond the annotations. 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 sections for purpose, usage, args, and returns. Moderately concise; every sentence adds value. Could be slightly tighter but effective overall.
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 (2 optional parameters) and the presence of an output schema, the description provides sufficient context: lists return fields, export options, and a usage section. No major gaps.
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's 'Args' section explains both parameters in detail, including the meaning of accession and the available export_format enum values. This compensates fully for the lack of schema descriptions.
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 gets publications and citations for tracked experiments, listing returned fields (authors, journal, DOI, PMID) and export formats. However, it does not explicitly differentiate from a potentially similar sibling tool 'encode_get_references', which may serve a similar purpose.
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?
Includes a dedicated 'WHEN TO USE' section and mentions related tools. Provides guidance on export formats for reference managers. Lacks explicit exclusions or alternatives for when this tool should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full details for a specific ENCODE experiment by accession ID.
Returns complete experiment metadata including all associated files, quality metrics, controls, replicate information, and audit status.
WHEN TO USE: Use when you have a specific accession and need full details including files, quality metrics, and audit status. RELATED TOOLS: encode_list_files, encode_track_experiment, encode_compare_experiments
Args: accession: ENCODE experiment accession (e.g., "ENCSR133RZO", "ENCSR000AKS")
Returns: JSON with full experiment details and file listing.
| Name | Required | Description | Default |
|---|---|---|---|
| accession | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide safety (readOnlyHint=true, destructiveHint=false, idempotentHint=true). The description adds behavioral context beyond what annotations convey: it explains the tool returns 'complete experiment metadata including all associated files, quality metrics, controls, replicate information, and audit status.' No contradictions with annotations; this is excellent transparency.
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 minimal sentences, each earning its place. It is well-structured with clear sections: purpose, when-to-use, related tools, parameters, and returns. No redundant information.
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 (one parameter, rich annotations, output schema exists), the description fully explains the return value (files, quality metrics, controls, replicates, audit status). It covers all necessary context for proper invocation.
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?
Only one parameter (accession) exists, and schema coverage is 0% (no description in schema). The description provides an example ('ENCSR133RZO') and explains it is an ENCODE experiment accession, adding meaning beyond the schema's title. While schema coverage is low, the description compensates well.
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 retrieves full details for a specific ENCODE experiment by accession ID, using precise verbs ('Get full details') and resource ('specific ENCODE experiment'). It distinguishes from siblings like encode_list_files (lists files) and encode_compare_experiments (comparison), so the agent can select it correctly.
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 includes a 'WHEN TO USE' section specifying when to use this tool ('when you have a specific accession and need full details including files, quality metrics, and audit status'). It also lists related tools, but does not explicitly state when not to use it or alternatives. The guidance is clear but lacks exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get live filter counts from ENCODE to discover what data is available.
Returns faceted counts showing how many experiments/files exist for each filter value. Useful for exploring what's available before searching.
WHEN TO USE: Use to explore what data exists before searching. Shows counts per filter value. Best first step for unknown datasets. RELATED TOOLS: encode_get_metadata, encode_search_experiments
Examples:
What assays are available for pancreas? organ="pancreas"
What organs have Histone ChIP-seq data? assay_title="Histone ChIP-seq"
What targets are available for mouse brain ChIP-seq? assay_title="Histone ChIP-seq", organism="Mus musculus", organ="brain"
Args: search_type: Object type ("Experiment" or "File") assay_title: Pre-filter by assay type organism: Pre-filter by organism organ: Pre-filter by organ biosample_type: Pre-filter by biosample type
Returns: JSON with facet names and their term counts.
| Name | Required | Description | Default |
|---|---|---|---|
| search_type | No | Experiment | |
| assay_title | No | ||
| organism | No | ||
| organ | No | ||
| biosample_type | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds detail about returning faceted counts and that it is exploratory, not modifying data. 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?
The description is well-structured with a header, usage guidelines, examples, and return type. Every sentence adds value, and it is front-loaded with the 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?
Despite no output schema, the description explains the return format ('JSON with facet names and term counts'). All parameters are covered with examples, making it complete for exploration.
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 the description lists all 5 parameters with clear explanations and examples (e.g., organ='pancreas'). 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's purpose: 'Get live filter counts from ENCODE to discover what data is available.' It specifies the verb (get), resource (filter counts), and distinguishes from sibling tools like encode_search_experiments.
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?
Explicit 'WHEN TO USE' section: 'Use to explore what data exists before searching. Shows counts per filter value. Best first step for unknown datasets.' Also lists related tools and provides examples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific ENCODE file.
WHEN TO USE: Use when you need detailed metadata for a specific file (size, md5, assembly, biological replicate info). RELATED TOOLS: encode_download_files, encode_list_files
Args: accession: File accession ID (e.g., "ENCFF635JIA")
Returns: JSON with file metadata including format, size, download URL, MD5, assembly, etc.
| Name | Required | Description | Default |
|---|---|---|---|
| accession | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds that it returns JSON with specific metadata fields, consistent with annotation. 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?
Short, front-loaded with purpose, then structured sections for usage, parameters, and returns. Every sentence adds value; 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?
For a simple read-only tool with one parameter and an output schema, the description covers all necessary context: purpose, when to use, parameter meaning, and return type. No gaps.
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?
Single parameter 'accession' is explained in the description as 'File accession ID' with an example value, compensating fully for 0% schema description coverage.
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 explicitly states 'Get detailed information about a specific ENCODE file' with a clear verb and resource. It lists specific metadata fields (size, md5, assembly), distinguishing it from siblings like encode_download_files (download) and encode_list_files (list).
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 a dedicated 'WHEN TO USE' section: 'Use when you need detailed metadata for a specific file' and lists related tools, giving clear usage context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get available filter values for ENCODE searches.
Use this to discover valid values for search parameters.
WHEN TO USE: Use to discover valid filter values before searching. Helps prevent typos in assay_title, organ, biosample_type etc. RELATED TOOLS: encode_get_facets, encode_search_experiments
Args: metadata_type: Type of metadata to retrieve. Options: - "assays": Available assay types (Histone ChIP-seq, ATAC-seq, total RNA-seq, etc.) - "organisms": Available organisms (Homo sapiens, Mus musculus, etc.) - "organs": Available organ/tissue systems (pancreas, brain, liver, etc.) - "biosample_types": Biosample classifications (tissue, cell line, primary cell, etc.) - "file_formats": File format types (fastq, bam, bed, bigWig, etc.) - "output_types": Output data types (reads, peaks, signal, etc.) - "output_categories": Output categories (raw data, alignment, signal, etc.) - "assemblies": Genome assemblies (GRCh38, hg19, mm10, etc.) - "life_stages": Life stages (embryonic, adult, child, etc.) - "replication_types": Replication types (isogenic, anisogenic, unreplicated) - "statuses": Experiment statuses (released, archived, etc.) - "file_statuses": File statuses (released, archived, in progress, etc.)
Returns: JSON list of valid values for the specified metadata type.
| Name | Required | Description | Default |
|---|---|---|---|
| metadata_type | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds that it returns a JSON list, but does not provide additional behavioral details beyond what annotations convey. There is no contradiction, but the description adds limited transparency beyond 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 well-structured with sections (purpose, when to use, related tools, args, returns). While slightly lengthy, every sentence adds value and the key information is front-loaded. Minor reduction could be possible, but overall concise for the coverage provided.
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 and an output schema (mentioned as JSON list), the description covers all essential aspects: purpose, usage context, all parameter options with examples, and return type. It is complete and leaves no ambiguity about how to use the tool.
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 compensates by documenting each enum value with examples (e.g., 'assays: Available assay types (Histone ChIP-seq, ATAC-seq...)). This adds significant meaning beyond the schema's enum list, making parameters self-explanatory.
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 'Get available filter values for ENCODE searches' with a specific verb and resource. It distinguishes itself from sibling tools like encode_search_experiments by focusing on retrieving valid filter values rather than executing searches.
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 includes 'WHEN TO USE' and 'RELATED TOOLS' sections. It advises using this tool before searching to prevent typos and mentions alternative tools (encode_get_facets, encode_search_experiments), providing clear context for when to use this tool versus others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get provenance information for derived files.
Shows the chain from your derived files back to original ENCODE data, including what tools and parameters were used.
WHEN TO USE: Use to trace a derived file back to original ENCODE data. Shows tools and parameters used. RELATED TOOLS: encode_log_derived_file
Args: file_path: Get provenance for a specific derived file source_accession: List all files derived from a specific ENCODE accession
Returns: JSON provenance chain or list of derived files.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | No | ||
| source_accession | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds that the tool shows the provenance chain and returns JSON, and explains the behavior of tracing back to original data, which adds value beyond annotations. 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?
The description is well-structured with headers for 'WHEN TO USE' and 'RELATED TOOLS', and it includes parameter descriptions. It is appropriately sized, with every sentence adding value, though it could be slightly more concise.
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 an output schema and annotations covering safety, the description sufficiently explains the purpose, parameters, and return type. It is complete enough for an agent to use the tool correctly, though more detail on the output format could be included.
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?
The input schema has no descriptions (0% coverage), but the description clarifies each parameter: 'file_path: Get provenance for a specific derived file' and 'source_accession: List all files derived from a specific ENCODE accession'. This adds meaningful semantics that the schema lacks.
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: 'Get provenance information for derived files' and explains it traces the chain back to original ENCODE data including tools and parameters. It also references a related sibling tool, distinguishing it from others.
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 a 'WHEN TO USE' section and mentions a related tool, but does not explicitly state when not to use it or offer alternatives beyond one sibling. The distinction between the two parameters (file_path vs source_accession) is given in the parameter descriptions, but not in a clear usage scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get external references linked to tracked experiments.
Returns PMIDs, DOIs, NCT IDs, GEO accessions and other identifiers linked to experiments. These identifiers can be directly passed to PubMed, bioRxiv, ClinicalTrials.gov, or other MCP tools.
WHEN TO USE: Use to retrieve external references linked to experiments. PMIDs can be passed to PubMed MCP tools. RELATED TOOLS: encode_link_reference, encode_get_citations
Args: experiment_accession: Filter by specific experiment (optional) reference_type: Filter by reference type (optional): "pmid", "doi", "nct_id", "preprint_doi", "geo_accession", "other"
Returns: JSON with linked external references.
| Name | Required | Description | Default |
|---|---|---|---|
| experiment_accession | No | ||
| reference_type | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a safe read-only operation. Description adds value by specifying the types of identifiers returned and that they can be passed to external tools, but does not disclose additional behavioral traits.
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 sections and bullet points. Slightly redundant between the first sentence and the WHEN TO USE section, but overall efficient and easy to scan.
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 and annotations, the description covers the core functionality well. Mentions integration with PubMed/bioRxiv, which is useful context. Lacks error or edge-case handling, but acceptable for this tool.
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 the description thoroughly explains both parameters: experiment_accession and reference_type with its enum values. This compensates fully for the missing schema descriptions.
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?
Clearly states the tool retrieves external references (PMIDs, DOIs, etc.) linked to experiments. Distinguishes from siblings by mentioning related tools encode_link_reference and encode_get_citations.
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?
Includes a WHEN TO USE section explaining the tool is for retrieving references to pass to other tools (e.g., PubMed). Mentions related tools but does not explicitly state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Link an external reference to a tracked ENCODE experiment.
This is the cross-server bridge. Attach PubMed IDs, bioRxiv DOIs, ClinicalTrials.gov NCT IDs, GEO accessions, or any external identifier to your tracked experiments for provenance and cross-referencing.
After finding a relevant paper with PubMed MCP or a preprint on bioRxiv, link it to the ENCODE experiment for future reference.
WHEN TO USE: Use to attach external IDs (PMID, DOI, GEO, NCT) to tracked experiments for cross-referencing. RELATED TOOLS: encode_get_references, encode_get_citations
Args: experiment_accession: ENCODE experiment accession (e.g., "ENCSR133RZO") reference_type: Type of external reference: - "pmid": PubMed ID (e.g., "32728249") - "doi": DOI (e.g., "10.1038/s41586-020-2493-4") - "nct_id": ClinicalTrials.gov ID (e.g., "NCT04567890") - "preprint_doi": bioRxiv/medRxiv DOI - "geo_accession": GEO accession (e.g., "GSE123456") - "other": Any other identifier reference_id: The actual identifier value description: Optional description of why this reference is linked
Returns: JSON with linking result.
| Name | Required | Description | Default |
|---|---|---|---|
| experiment_accession | Yes | ||
| reference_type | Yes | ||
| reference_id | Yes | ||
| description | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a write operation (readOnlyHint=false) that is non-destructive and idempotent. The description adds that it creates a 'link' and returns JSON, but does not elaborate on side effects, authentication, or duplicate handling beyond 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 well-structured with a brief summary, cross-server bridge context, usage scenario, dedicated sections for WHEN and RELATED TOOLS, and clear parameter documentation. 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 low complexity (4 parameters, 3 required) and presence of an output schema, the description covers purpose, usage, and parameters adequately. The return description is minimal but acceptable. A slightly more detailed return format would elevate completeness.
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 thorough explanations for each parameter, including format examples, enum values, and usage contexts (e.g., 'experiment_accession: ENCODE experiment accession (e.g., "ENCSR133RZO")'). This fully compensates for the schema gap.
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 specifies the action: linking an external reference to a tracked ENCODE experiment. It provides concrete examples (PubMed, DOI, GEO) and distinguishes from sibling tools like encode_get_references which retrieve references.
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?
A 'WHEN TO USE' section explicitly states the tool's purpose for attaching external IDs after finding a paper. Related tools are mentioned, but no direct exclusion or alternative scenarios are provided, leaving some ambiguity about when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all files for a specific ENCODE experiment, with optional filters.
Examples:
All BED files: experiment_accession="ENCSR133RZO", file_format="bed"
FASTQs only: experiment_accession="ENCSR133RZO", file_format="fastq"
Signal tracks: experiment_accession="ENCSR133RZO", output_category="signal"
Default/recommended files: preferred_default=True
Peaks from GRCh38: file_format="bed", output_type="IDR thresholded peaks", assembly="GRCh38"
Common file_format values: "fastq", "bam", "bed", "bigWig", "bigBed", "tsv", "hic"
Common output_type values: "reads", "alignments", "signal of unique reads", "signal of all reads", "fold change over control", "IDR thresholded peaks", "pseudoreplicated peaks", "replicated peaks", "gene quantifications", "transcript quantifications", "contact matrix"
WHEN TO USE: Use to browse files within a known experiment. Use encode_search_files instead to find files across experiments. RELATED TOOLS: encode_search_files, encode_get_file_info, encode_download_files
Args: experiment_accession: ENCODE experiment accession (e.g., "ENCSR133RZO") file_format: Filter by format ("fastq", "bam", "bed", "bigWig", "bigBed", etc.) file_type: Filter by specific type ("bed narrowPeak", "bed broadPeak", etc.) output_type: Filter by output type ("reads", "peaks", "signal", etc.) output_category: Filter by category ("raw data", "alignment", "signal", "annotation") assembly: Filter by genome assembly ("GRCh38", "hg19", "mm10") status: Filter by status ("released", "archived", "in progress") preferred_default: If True, return only default/recommended files limit: Max files to return (default 200)
Returns: JSON list of files with accession, format, size, download URL, and metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| experiment_accession | Yes | ||
| file_format | No | ||
| file_type | No | ||
| output_type | No | ||
| output_category | No | ||
| assembly | No | ||
| status | No | ||
| preferred_default | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description confirms it is a listing operation and mentions the return format, but does not add significant behavioral context beyond what annotations provide. 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?
The description is well-structured with a concise summary, followed by examples, parameter list, usage guidance, and related tools. It is front-loaded and every section is informative and necessary.
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 complexity (9 parameters, 1 required) and the presence of an output schema, the description adequately covers functionality, examples, common values, and return type. It is complete for an agent to correctly select and invoke the tool.
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%, so the description bears full responsibility. It provides detailed explanations for all 9 parameters, including common values and examples (e.g., file_format: 'Common file_format values: "fastq", "bam", "bed", ...'). This adds substantial meaning 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 lists files for a specific ENCODE experiment with optional filters. It distinguishes from siblings like encode_search_files (which searches across experiments) and encode_get_file_info (which gets info for a single file).
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 states 'WHEN TO USE: Use to browse files within a known experiment. Use encode_search_files instead to find files across experiments.' It also provides a list of related tools, offering clear guidance on when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all experiments you've tracked locally, with optional filters.
Shows your local library of tracked ENCODE experiments, their metadata, publication counts, and derived file counts.
WHEN TO USE: Use to see all experiments in your local library. Filter by assay, organism, or organ. RELATED TOOLS: encode_summarize_collection, encode_export_data
Args: assay_title: Filter by assay type (partial match) organism: Filter by organism (partial match) organ: Filter by organ (partial match)
Returns: JSON with tracked experiments metadata table and tracker stats.
| Name | Required | Description | Default |
|---|---|---|---|
| assay_title | No | ||
| organism | No | ||
| organ | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds that the tool returns JSON with metadata and tracker stats, and notes it shows 'local library' and includes publication/derived file counts. This adds behavioral context beyond annotations 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?
The description is concise and well-structured: a one-sentence purpose, a usage section, args list, and returns statement. Every sentence adds value 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 (3 optional params, no required params, output schema exists), the description covers purpose, usage, parameter semantics, and return value. Annotations provide safety context. No gaps for effective agent invocation.
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?
Input schema has 0% description coverage, but the description provides clear semantic meaning for each parameter: assay_title, organism, and organ filters with partial match behavior. While it lacks format constraints or examples, it compensates for the schema gap.
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 explicitly states the tool lists all locally tracked experiments with optional filters. It distinguishes from siblings by specifying 'tracked experiments' and referencing related tools like encode_summarize_collection. The verb 'list' and object 'tracked experiments' are clear.
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 includes a 'WHEN TO USE' section advising to use for seeing all experiments in the local library and mentions filtering capabilities. It lists related tools (encode_summarize_collection, encode_export_data), providing context for alternatives. However, it does not explicitly state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Log a file you've derived from ENCODE data for provenance tracking.
Use this when you create new files from ENCODE data (e.g., running a pipeline, filtering peaks, merging samples). This creates a provenance record linking your derived file back to the original ENCODE source data.
WHEN TO USE: Use after creating files from ENCODE data (filtered peaks, merged signals). Creates provenance chain back to source. RELATED TOOLS: encode_get_provenance, encode_download_files
Args: file_path: Path to the derived file you created source_accessions: List of ENCODE accessions this file was derived from (experiment or file accessions, e.g., ["ENCSR133RZO", "ENCFF635JIA"]) description: What this derived file contains file_type: Type of file (e.g., "filtered_peaks", "merged_signal", "differential") tool_used: Tool/software used to create it (e.g., "bedtools intersect", "DESeq2") parameters: Parameters or command used
Returns: JSON with the provenance record ID.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | ||
| source_accessions | Yes | ||
| description | No | ||
| file_type | No | ||
| tool_used | No | ||
| parameters | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes creating a provenance record, consistent with annotations (readOnlyHint=false, destructiveHint=false). Idempotency hinted by idempotentHint=true but not elaborated; otherwise transparent.
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 sections and bulleted args. Slightly verbose but every sentence contributes to understanding.
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 all necessary aspects: purpose, usage, parameters, return value (output schema exists), and context relative to siblings. No gaps evident.
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 provides thorough explanations for all 6 parameters with examples, adding substantial value over 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 'Log a file you've derived from ENCODE data for provenance tracking' with specific examples. It distinguishes from siblings like encode_get_provenance and encode_download_files.
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 includes 'WHEN TO USE' and 'RELATED TOOLS' sections, guiding the agent on appropriate context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage ENCODE API credentials for accessing restricted/unreleased data.
Most ENCODE data is public and requires no authentication. Credentials are only needed for unreleased or restricted datasets.
Credentials are stored securely in your OS keyring (macOS Keychain, Linux Secret Service, Windows Credential Locker) and never in plaintext.
WHEN TO USE: Use only for accessing unreleased/restricted ENCODE data. Public data requires no authentication. RELATED TOOLS: encode_search_experiments
Args: action: What to do: - "store": Save new credentials (requires access_key and secret_key) - "check": Check if credentials are configured - "clear": Remove stored credentials access_key: Your ENCODE access key (only for action="store") secret_key: Your ENCODE secret key (only for action="store")
Returns: JSON with action result.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | ||
| access_key | No | ||
| secret_key | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and idempotent behavior. The description adds security context (OS keyring storage, no plaintext) and confirms action results as JSON. 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: purpose, security note, when-to-use, related tools, args, returns. 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?
For a credential management tool with output schema present, the description covers all necessary information: purpose, usage, parameter details, security, and return format. No gaps.
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, the description thoroughly explains each parameter: action's three values and when access_key/secret_key are required, adding meaning beyond the schema's enum and types.
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 manages ENCODE API credentials for restricted/unreleased data, with specific actions (store, check, clear). It is distinct from siblings like encode_search_experiments which focus on data queries.
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 tells when to use (only for unreleased/restricted data) and when not (public data needs no auth). Names related tool encode_search_experiments, providing clear context for alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search ENCODE experiments with comprehensive filters.
Examples:
Find all Histone ChIP-seq on human pancreas tissue: assay_title="Histone ChIP-seq", organ="pancreas", biosample_type="tissue"
Find ATAC-seq on human brain: assay_title="ATAC-seq", organ="brain"
Find RNA-seq on GM12878 cell line: assay_title="total RNA-seq", biosample_term_name="GM12878"
Find ChIP-seq targeting H3K27me3: assay_title="Histone ChIP-seq", target="H3K27me3"
Find all mouse liver experiments: organism="Mus musculus", organ="liver"
Free text search: search_term="CRISPR screen pancreatic"
Common assay_title values: "Histone ChIP-seq", "TF ChIP-seq", "ATAC-seq", "DNase-seq", "total RNA-seq", "polyA plus RNA-seq", "WGBS", "intact Hi-C", "CUT&RUN", "CUT&Tag", "STARR-seq", "MPRA", "eCLIP", "CRISPR screen"
Common organ values: "pancreas", "liver", "brain", "heart", "kidney", "lung", "intestine", "skin of body", "blood", "spleen", "thymus"
biosample_type values: "tissue", "cell line", "primary cell", "in vitro differentiated cells", "organoid"
WHEN TO USE: Use as the primary entry point when users want to find experiments. Start with encode_get_facets if unsure what filters to use. RELATED TOOLS: encode_get_facets, encode_get_metadata, encode_search_files
Args: assay_title: Assay type (e.g., "Histone ChIP-seq", "ATAC-seq", "total RNA-seq") organism: Species (default: "Homo sapiens"). Also: "Mus musculus" organ: Organ/tissue system (e.g., "pancreas", "brain", "liver") biosample_type: Sample classification ("tissue", "cell line", "primary cell", "organoid") biosample_term_name: Specific cell/tissue name (e.g., "GM12878", "HepG2", "pancreas") target: ChIP/CUT&RUN target (e.g., "H3K27me3", "CTCF", "p300") status: Data status (default: "released"). Also: "archived", "revoked" lab: Submitting lab name award: Funding project assembly: Genome assembly (e.g., "GRCh38", "mm10") replication_type: "isogenic", "anisogenic", or "unreplicated" life_stage: "embryonic", "postnatal", "child", "adult" sex: "male", "female", "mixed" treatment: Treatment name if perturbation experiment genetic_modification: Modification type ("CRISPR", "RNAi") perturbed: True for perturbation experiments only search_term: Free text search across all fields date_released_from: Start date (YYYY-MM-DD) for date range filter date_released_to: End date (YYYY-MM-DD) for date range filter limit: Max results to return (default 25, use larger for comprehensive searches) offset: Skip first N results (for pagination)
Returns: JSON with experiment results, total count, and pagination info.
| Name | Required | Description | Default |
|---|---|---|---|
| assay_title | No | ||
| organism | No | Homo sapiens | |
| organ | No | ||
| biosample_type | No | ||
| biosample_term_name | No | ||
| target | No | ||
| status | No | released | |
| lab | No | ||
| award | No | ||
| assembly | No | ||
| replication_type | No | ||
| life_stage | No | ||
| sex | No | ||
| treatment | No | ||
| genetic_modification | No | ||
| perturbed | No | ||
| search_term | No | ||
| date_released_from | No | ||
| date_released_to | No | ||
| limit | No | ||
| offset | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds useful behavioral context, such as pagination via limit/offset, default status 'released', and that it returns JSON with results, total count, and pagination info. No contradictions, and the description enhances transparency beyond 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 well-structured with a clear opening, examples, common values, usage guidance, and parameter list. It is front-loaded with purpose. However, it is somewhat lengthy due to the many examples and parameter details, but this is justified by the need to compensate for zero schema coverage. Nearly all sentences earn their place.
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 (21 parameters, no required fields, no enums, has output schema), the description is remarkably complete. It explains the return format (JSON with results, count, pagination), provides usage examples, lists common values, and gives guidance on when to use alternative tools. The output schema existence reduces the need to detail return values, but the description handles it 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 description coverage is 0%, but the description provides detailed explanations for all 21 parameters, including common values, defaults, and usage examples. Examples like 'assay_title="Histone ChIP-seq", organ="pancreas", biosample_type="tissue"' illustrate how to combine parameters effectively. This fully compensates for the lack of schema descriptions.
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 'Search ENCODE experiments with comprehensive filters.' The verb 'search' and resource 'ENCODE experiments' are specific. Examples and common values further clarify the scope, and the tool is distinguished from siblings like encode_search_files and encode_get_facets.
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 includes explicit 'WHEN TO USE' guidance: 'Use as the primary entry point when users want to find experiments. Start with encode_get_facets if unsure what filters to use.' It also lists related tools, providing clear context for when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search files across ALL experiments with combined experiment + file filters.
This is powerful for finding specific file types across many experiments.
Examples:
All BED files from human pancreas ChIP-seq: file_format="bed", assay_title="Histone ChIP-seq", organ="pancreas"
FASTQs from mouse liver RNA-seq: file_format="fastq", assay_title="total RNA-seq", organ="liver", organism="Mus musculus"
All IDR peak files for H3K27me3: output_type="IDR thresholded peaks", target="H3K27me3"
BigWig signal tracks from ATAC-seq on brain tissue: file_format="bigWig", assay_title="ATAC-seq", organ="brain", biosample_type="tissue"
WHEN TO USE: Use to find specific file types across ALL experiments. More powerful than encode_list_files for cross-experiment file discovery. RELATED TOOLS: encode_list_files, encode_batch_download, encode_get_file_info
Args: file_format: File format ("fastq", "bam", "bed", "bigWig", etc.) file_type: Specific file type ("bed narrowPeak", "bed broadPeak", etc.) output_type: Output type ("reads", "peaks", "signal", etc.) output_category: Output category ("raw data", "alignment", "signal", "annotation") assembly: Genome assembly ("GRCh38", "hg19", "mm10") assay_title: Filter by assay type of parent experiment organism: Filter by organism of parent experiment organ: Filter by organ of parent experiment biosample_type: Filter by biosample type ("tissue", "cell line", etc.) target: Filter by ChIP/CUT&RUN target status: File status (default: "released") preferred_default: If True, only default/recommended files search_term: Free text search limit: Max results (default 25) offset: Skip first N results (pagination)
Returns: JSON with file results, total count, and pagination info.
| Name | Required | Description | Default |
|---|---|---|---|
| file_format | No | ||
| file_type | No | ||
| output_type | No | ||
| output_category | No | ||
| assembly | No | ||
| assay_title | No | ||
| organism | No | ||
| organ | No | ||
| biosample_type | No | ||
| target | No | ||
| status | No | released | |
| preferred_default | No | ||
| search_term | No | ||
| limit | No | ||
| offset | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds behavioral context such as returning JSON with results, total count, and pagination. No contradictions or missing critical information.
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: a clear purpose statement, illustrative examples, usage notes, and parameter list. It is front-loaded and each section adds value, though slightly verbose in places.
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 (15 parameters, no enums, but output schema exists), the description comprehensively explains usage with examples, pagination, and relationship to siblings. It covers all key aspects for effective invocation.
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 compensates by listing all 15 parameters with brief, informative descriptions and concrete examples of usage. While not exhaustive, it adds significant meaning beyond the schema titles.
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: 'Search files across ALL experiments with combined experiment + file filters.' It provides multiple examples and explicitly distinguishes itself from sibling tools like encode_list_files by emphasizing cross-experiment capability.
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 includes a 'WHEN TO USE' section that advises using this tool for cross-experiment file discovery and compares it with encode_list_files. However, it does not explicitly state when not to use it or provide specific exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summarize your tracked experiment collection with grouped statistics.
Provides an overview of tracked experiments grouped by assay type, target, organism, organ, biosample type, and lab. Shows total counts for publications, derived files, and external references.
Useful when tracking 10+ experiments and needing a bird's-eye view of your research data collection.
WHEN TO USE: Use for a bird's-eye view of tracked experiments grouped by assay, target, organ. Best for 10+ tracked experiments. RELATED TOOLS: encode_list_tracked, encode_export_data
Args: assay_title: Filter by assay type (partial match) organism: Filter by organism (partial match) organ: Filter by organ (partial match)
Returns: JSON summary with experiment counts grouped by multiple dimensions.
| Name | Required | Description | Default |
|---|---|---|---|
| assay_title | No | ||
| organism | No | ||
| organ | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description doesn't need to repeat that. It adds value by noting partial match parameter behavior, but no extra details on auth or rate limits. Still, it goes beyond 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?
Well-structured with clear sections (description, when to use, related tools, args). The phrase 'bird's-eye view' appears twice, slightly redundant, but overall concise and informative.
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 an output schema exists, the description appropriately summarizes return type (JSON summary). Covers parameters, usage context, and grouping dimensions. No gaps for a summarization tool.
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 compensates by explaining each parameter's purpose (filter by assay, organism, organ) and noting partial match behavior. Lacks format details but provides essential 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 tool summarizes tracked experiments with grouped statistics, specifying grouping dimensions (assay, target, organism, etc.) and distinguishing it from siblings like encode_list_tracked and encode_export_data.
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?
Explicit WHEN TO USE guidance is provided: 'best for 10+ tracked experiments' and 'bird's-eye view.' Also lists related tools (encode_list_tracked, encode_export_data) to help differentiate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Track an ENCODE experiment locally with its publications, methods, and pipeline info.
Fetches full experiment metadata from ENCODE and stores it in a local SQLite database along with any associated publications (PMIDs, DOIs, authors, journal) and pipeline/analysis information (software versions, methods).
This is like adding an experiment to your "library" - similar to Endnote for papers.
WHEN TO USE: Use to save an experiment to your local library with publications and pipeline info. Required before compare or citations. RELATED TOOLS: encode_compare_experiments, encode_get_citations, encode_export_data
Args: accession: ENCODE experiment accession (e.g., "ENCSR133RZO") fetch_publications: Also fetch and store publications/citations (default True) fetch_pipelines: Also fetch and store pipeline/analysis info (default True) notes: Optional notes to attach to this experiment
Returns: JSON with tracking result including publications and pipeline info found.
| Name | Required | Description | Default |
|---|---|---|---|
| accession | Yes | ||
| fetch_publications | No | ||
| fetch_pipelines | No | ||
| notes | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the tool fetches external data, stores in a local SQLite database, and associates publications and pipeline info. Annotations already indicate idempotency and open-world behavior, so the description adds useful 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?
The description is structured with a clear first sentence, metaphor, usage guidelines, and parameter list. While slightly verbose, every section adds value. Could be more concise but still effective.
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 and annotations, the description covers the main functionality and use case. Minor omission: no mention of error handling for invalid accessions, but overall sufficient for an agent.
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 compensates by explaining each parameter: accession (example), fetch_publications (default true), fetch_pipelines (default true), and notes (optional). This 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 the action ('track') and the resource ('experiment'), specifying that it stores metadata locally with publications and pipeline info. It distinguishes itself from siblings by explaining its unique role as a prerequisite for comparison and citation tools.
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 'WHEN TO USE' guidance, stating it is required before using compare or citations. It also lists related sibling tools, helping the agent choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.3.0-beta.1encode_batch_downloadencode_compare_experimentsencode_download_filesencode_export_dataencode_get_citationsencode_get_experimentencode_get_facetsencode_get_file_infoencode_get_metadataencode_get_provenanceencode_get_referencesencode_link_referenceencode_list_filesencode_list_trackedencode_log_derived_fileencode_manage_credentialsencode_search_experimentsencode_search_filesencode_summarize_collectionencode_track_experimentEach tool has a clearly distinct purpose: searching experiments vs. files, downloading batches vs. specific files, tracking vs. comparing, etc. No two tools perform overlapping functions, and descriptions clearly differentiate them.
All 20 tools follow a consistent 'encode_verb_noun' pattern in snake_case. Verbs like get, list, search, track, compare are used uniformly, making the tool surface predictable and easy to navigate.
20 tools is well-suited for the ENCODE domain, covering discovery, retrieval, tracking, comparison, citations, provenance, and credentials. Each tool earns its place without being overwhelming.
The toolkit covers the full lifecycle: data exploration (search, facets, metadata), retrieval (download, batch download), local management (track, list, export, summarize), comparison, citations, references, provenance tracking, and credentials. There are no obvious gaps for a comprehensive ENCODE workflow.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP gateway federating 21 biomedical MCP servers behind one endpoint: gnomAD, ClinVar, HPO, VEP.
AI-powered bioprotocol optimization — generate, search, and manage lab protocols via MCP
Auditable MCP server for PubMed, Europe PMC, ClinicalTrials.gov, and bioRxiv/medRxiv queries
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ammawla/encode-toolkit'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
