worms-marine-taxa-mcp-server

Worms Resolve Taxon

worms_resolve_taxon

Read-onlyIdempotent

Resolve exact or explicitly fuzzy scientific names, or search one vernacular name as a whole recorded common name or, with vernacularMatch: "contains", as part of one. Names default to marine and extant taxa; vernacular cannot filter. Resume scientific segments with nextInputOffset and nextMatchOffset against unchanged names and options; inputIndex preserves duplicates and partialGroup identifies split groups. For vernacular, consume nextResultOffset within the same upstream offset before advancing page.nextOffset and resetting resultOffset to zero. Full 50-match upstream groups remain completeness-unknown; accepted-name fields do not choose an ambiguous match.

Input Schema

Name	Required	Description	Default
`fuzzy`	No	Explicit fuzzy scientific-name matching; unavailable for vernacular.
`names`	No	Nonempty original scientific-name list, with no total-input ceiling; at most 50 positions fetched per call. Resubmit unchanged with continuation offsets, preserving duplicates.
`offset`	No	Vernacular only: one-based upstream starting record, advancing by 50; default 1. Scientific names accept only 1.
`extantOnly`	No	Filter scientific names to extant taxa; vernacular cannot filter and rejects false.
`marineOnly`	No	Filter scientific names to marine taxa; vernacular cannot filter and rejects false.
`vernacular`	No	Common name, mutually exclusive with names; blank means unset.
`inputOffset`	No	Zero-based original scientific names position; inactive for vernacular.
`matchOffset`	No	Zero-based match within the scientific-name group at inputOffset; inactive for vernacular.
`resultOffset`	No	Zero-based match within the fetched vernacular page; keep upstream offset until consumed. Inactive for scientific names.
`vernacularMatch`	No	Vernacular only: exact matches a whole recorded common name; contains matches every recorded common name containing the text, such as grouper in Nassau grouper. Names accept only exact; blank means exact.	exact

Output Schema

Name	Required	Description
`echo`	No	Effective matching options.
`mode`	No	Matching mode.
`page`	No	Vernacular page only.
`error`	No	Present when the call failed. Absent on success.
`notice`	No	Empty vernacular-page guidance, or the inputIndex of each returned 50-match scientific-name group, whose completeness is unknown, with the change that narrows it.
`results`	No	One result per processed input.
`byteBudget`	No	Complete serialized response byte target.
`totalCount`	No	Known local sequence length before pagination.
`attribution`	No	WoRMS source attribution.
`resultOffset`	No	Zero-based starting position in the complete local sequence.
`budgetLimited`	No	Whether the byte budget ended this local page early.
`deferredCount`	No	Original input positions not fully consumed.
`oversizedItem`	No	One indivisible scientific item exceeds the target; retained intact with forward progress.
`requiredBytes`	No	Serialized paired-surface result bytes for an oversized item, excluding transport-added metadata.
`returnedCount`	No	Whole scientific items returned on this segment.
`nextInputOffset`	No	Next original names position; resubmit unchanged names and options.
`nextMatchOffset`	No	Next match position at nextInputOffset; null when names consumed.
`nextResultOffset`	No	Next local position; null when consumed.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 24, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/openWorld, so the safety profile is covered; the description adds real caveats beyond them: full 50-match upstream groups are completeness-unknown, and accepted-name fields do not disambiguate an ambiguous match. Those are non-obvious result-integrity warnings an agent would otherwise miss.

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

Conciseness3/5

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

Purpose is front-loaded, but the body is a single dense block of run-on clauses dense with internal jargon (inputOffset, nextMatchOffset, partialGroup) that is never unpacked. It is information-rich but poorly structured for an agent scanning under time pressure.

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, return values need not be described, and the description still covers the resume protocol, completeness caveat, and ambiguity caveat. Only the unexplained output-side identifiers (inputIndex, partialGroup, nextResultOffset) keep it from being fully self-contained.

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 baseline is 3; the description earns above that by explaining the cross-parameter pagination protocol (consume nextResultOffset within the same upstream offset before advancing page.nextOffset and resetting resultOffset) and the meaning of inputIndex/partialGroup, which are not derivable from the input schema alone.

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?

Starts with a specific verb+resource: "Resolve exact or explicitly fuzzy scientific names, or search one vernacular name...", which distinguishes this from worms_get_taxon or worms_get_synonyms. The dual mode (scientific list vs. single vernacular) is stated, though the second half of the sentence is tangled enough that an agent must re-read to parse it.

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?

Gives in-tool usage constraints (names vs. vernacular mutual exclusivity, vernacular cannot filter, scientific names accept only offset 1), which is genuinely useful. However it never says when to choose this tool over siblings like worms_get_taxon or worms_crosswalk_id, so the alternatives guidance is only implied.

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

All worms-marine-taxa-mcp-server tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.