Skip to main content
Glama

Jean — Molecular Biology & Genomics

match_part_by_sequence

Read-only

Identify a stretch of DNA by asking the iGEM Registry which published part carries exactly those bases, and hand back that part's own description, Sequence-Ontology role, literature citation and license.

Input Schema

NameRequiredDescriptionDefault
capNomost candidate sequences to fetch and compare before stopping and saying so.
nameNoa name to narrow the candidates by (a feature name, or a part id like BBa_R0040). It only narrows: the bases decide the match. Leave it empty to compare every candidate of this exact length, which is slower and can be far more requests.
_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.
_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.
sequenceYesthe bases to identify — a feature’s span, an assembled fragment, a pasted oligo.

Output Schema

NameRequiredDescriptionDefault
pageYesthe registry page, so the claim can be checked without us
partYesthe best match’s registry id, exact before reverse-complement
roleYesits Sequence-Ontology role, as the registry files it
titleYesthe registry’s own short title for that part
strandYes`exact` when the bases agree as given, `reverse-complement` when they agree flipped
licenceYesthe SPDX identifier the registry states for that part
matchedYeswhether any compared part carries these exact bases
matchesYesevery part that carries these bases — several may, and the registry keeps them apart
coverageYeswhat was and was not compared: the population at this length, the candidates the narrowing produced, how many were read back, and whether the cap stopped it. A null answer is only as strong as this.
descriptionYesthe registry’s own prose — the half a coordinate cannot tell you

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety and external-service profile is largely covered. The description adds that results come from the iGEM Registry and enumerates the returned fields, but says nothing about no-match behavior, request volume, or rate limits — the cap parameter hints at cost only inside the schema.

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

Conciseness5/5

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

A single front-loaded sentence with no filler: the action, the source, the matching rule, and the payload are all stated once. Nothing is repeated or padding.

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

Completeness4/5

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

With an output schema present and full schema coverage, the description need only frame purpose, and it does so accurately for a read-only exact-match lookup. The remaining gap is the outcome when no published part carries those exact bases, which the description never addresses.

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 description coverage is 100%, so cap, name, _files, _subject and sequence are all documented in the schema itself, including the narrowing-only semantics of name. The description contributes no additional parameter meaning, which is the baseline case when the schema does the work.

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

Purpose4/5

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

The description names a specific verb ("Identify") and resource ("a stretch of DNA"), and pins the data source to the iGEM Registry with an exact-base match criterion. That exactness implicitly separates it from alignment/BLAST-style siblings, but no sibling is named explicitly.

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

Usage Guidelines3/5

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

Usage is only implied: an agent infers this is the tool for 'given these bases, what published part is it?' There is no statement of when to prefer it over blast_search, search_records, or find_accessions, and no prerequisites or exclusions are given.

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