Skip to main content
Glama

Find research software

find_tools
Read-onlyIdempotent

Find research software for a task from the bio.tools registry (ELIXIR), check each tool's licence, verify the paper behind it (DOI, retractions, corrections), label whether it is still maintained, and give the install line. Describe the task (e.g. "cluster single-cell RNA-seq data") and optionally the file format the data is in (e.g. H5AD, FASTQ, VCF); tools that list that format as an input are favoured. Each result has a match level, a plain-language licence verdict, the paper and whether it checks out, a maintenance label (active, idle, stale, archived) read from the linked GitHub repository, and an install line built from a PyPI, Bioconda, Bioconductor, CRAN or GitHub link the registry lists. Every identifier and command comes from the registry's own records; nothing is generated. The why field lists the facts behind the match: explain the fit in your own words from those facts, and say plainly when no tool matched. Pass keywords with English words when the task is long or not in English. Licence verdicts come from registry and repository metadata and are not legal advice.

Input Schema

NameRequiredDescriptionDefault
keywordsNoEnglish search keywords (e.g. "single-cell clustering"). Recommended.
questionYesThe task in natural language (e.g. "cluster single-cell RNA-seq data").
max_resultsNoNumber of results, 1–5.
input_formatNoThe file format the data is in (e.g. "H5AD", "FASTQ", "VCF"). Tools that read it are favoured.
intended_useNoWhat the software is for. `commercial` demotes anything its licence does not clear.publication
citation_styleNoStyle for the ready-made paper citations.apa

Output Schema

NameRequiredDescriptionDefault
quotaYes
statsYes
resultsYes
questionYes
warningsYes
data_noteYes
takeawaysYes
suggestionsYes
input_formatNo
intended_useYes
search_termsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedOutput schema / properties / quota / properties / hint
      Added value: +{
      +  "enum": [
      +    "low",
      +    "intro"
      +  ],
      +  "type": "string"
      +}
  2. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive, openWorld), and the description goes well beyond them: every identifier and command is taken from registry records with nothing generated, maintenance labels come from the linked GitHub repo, install lines are built from PyPI/Bioconda/Bioconductor/CRAN/GitHub links, and licence verdicts are explicitly not legal advice. That is exactly the kind of provenance and limitation disclosure an agent needs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core action is front-loaded in the first clause, and every sentence carries non-redundant information (filters, result shape, provenance caveats). It is dense as a single long block rather than being broken into scannable parts, which costs it a point but not much else.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 6-parameter, open-world search tool with an output schema, the description covers purpose, inputs, filtering behaviour, result fields, and the provenance/legal caveats. Since an output schema exists, return-format detail is not required, and the description still summarizes result shape usefully.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds real semantics the schema lacks: `keywords` should be English and is the fallback for long or non-English tasks, and `input_format` is used to favour tools that list that format as an input. `why` field handling is also explained. It does not, however, clarify `citation_style` behaviour beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource (find research software from the bio.tools/ELIXIR registry) plus the exact enrichment it performs: licence check, paper verification with retraction/correction checks, maintenance label, install line. It is unmistakably distinct from siblings like find_datasets or search_papers.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear when-to-use context ('Describe the task... and optionally the file format') and a concrete fallback rule ('Pass keywords with English words when the task is long or not in English'), plus the effect of `commercial` on results. It never names or excludes an alternative sibling (e.g. find_datasets for data rather than software), so it stops short of full alternative routing.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.