Skip to main content
Glama

jean — Molecular Biology & Genomics

blast_project_sequences

Read-only

Search a sequence against THIS PROJECT'S OWN records with blastn or blastp, on this machine: the local database is built from every project record of the program's alphabet, and every E-value is computed from that database's own size. Use it to ask which of my constructs, reads or proteins carry this span. Nothing leaves the machine; for public databases use blast_search.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
_filesNoThe project: record references shaped like _subject. Their records become library documents a tool names in sequences/parts/document; a trace or alignment is found by file name.
regionNowhich part of the open record to search, when no sequence is wired in. Values: whole (the whole record), selection (the current selection), feature (a named feature).whole
featureNothe feature's name, matched case-insensitively on the open record. Only applies when region is feature.
programNoblastn searches the nucleotide records, blastp the protein records. Values: blastn (blastn · nucleotide query), blastp (blastp · protein query).blastn
_subjectNoThe record to act on: exactly one of sequence, accession (+source), sample (an id from list_samples) or file ({name, text} or {name, base64}); record_index picks one record of several.
sequenceNothe query. Wire a record or a sequence output, or paste raw/FASTA. Left empty, the region below is taken from the open record.
maxExpectNoE-value cutoff (BLAST+'s -evalue); hits above it are not reported.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
hitsYesevery hit, with its HSPs, accession, organism and the links the service sent
topHitYesthe best hit by E-value: what a "what is this?" step reads
tabularYesthe hits as BLAST's own outfmt 6 table, for download or a downstream parser
hitCountYeshow many subjects matched
sequencesYesthe hit subjects as FASTA, ready to wire straight into an alignment or a tree
topExpectYesthe best hit's E-value; wire into a $when to branch on significance
provenanceYesthe binary, the command line EBI ran, the databases as built, and the search space the E-values are relative to
topCoverageYeswhat fraction of the query the best hit covers, 0–1
topIdentityYespercent identity of the best hit's best HSP

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnly/non-destructive/closed-world, and the description adds real value beyond them: the local DB is built from every project record of the program's alphabet and E-values are computed against that database's own size, which changes how hits should be interpreted. It also states "nothing leaves the machine," a meaningful privacy/scope trait. Only minor gap is that it says nothing about result size or runtime for large projects.

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?

Four short sentences, front-loaded with the scope and database-construction constraint before the use case and the alternative. Every sentence carries distinct information, though the middle clause about database size and E-values is dense and could be tightened.

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?

An output schema exists, so return values need not be described, and annotations cover the safety profile. The description supplies everything else an agent needs to choose this over blast_search and understand the E-value basis of the results.

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

Parameters3/5

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

Schema coverage is 100%, so the schema already documents program, region/feature, maxExpect, and the query/subject shapes; baseline is 3. The description reinforces the blastn=nucleotide / blastp=protein mapping but adds no syntax or semantics the schema does not already carry.

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?

States a specific verb (search) and a tightly scoped resource (THIS PROJECT'S OWN records), plus the concrete scope constraints: the local database is built from every project record of the matching alphabet. It explicitly names the sibling it is not (blast_search for public databases), so an agent can distinguish the two without opening schemas.

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

Usage Guidelines5/5

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

Gives the positive trigger ("ask which of my constructs, reads or proteins carry this span") and the exclusion with an alternative ("for public databases use blast_search"). When-to-use and when-not-to-use are both explicit, and the local-vs-public boundary is the exact decision an agent faces here.

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.

Resources