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-or-brackish 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.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "worms_resolve_taxon"
  }
}

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 taxa WoRMS flags marine or brackish; false also admits freshwater-only and terrestrial 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.

Changed1 schema field changedOct 29, 2026

changedInput schema / properties / marineOnly / description

Previous value: -"Filter scientific names to marine taxa; vernacular cannot filter and rejects false."New value: +"Filter scientific names to taxa WoRMS flags marine or brackish; false also admits freshwater-only and terrestrial taxa. Vernacular cannot filter and rejects false."

First observedOct 24, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Annotations already declare readOnly/openWorld/idempotent, and the description layers on real behavioral context: defaults to marine-or-brackish extant taxa, vernacular cannot filter, 50-match upstream groups are completeness-unknown, and accepted-name fields do not disambiguate. These are non-obvious constraints an agent could not derive from the annotations.

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?

Front-loaded with purpose, but the remainder is a dense run-on paragraph mixing purpose, filtering defaults, and a multi-offset resume protocol without structure. Every clause is relevant, yet the jargon (nextInputOffset, partialGroup, resultOffset) is introduced with no scaffolding, hurting scanability.

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?

An output schema exists so return values need not be explained, and the description covers modes, filters, pagination, and completeness caveats. The only gap is that output-field names like inputIndex and partialGroup are referenced without stating they are response fields, which may briefly confuse an agent.

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; the description earns a bump by explaining cross-parameter coordination (scientific vs vernacular mode exclusivity, keeping names/options unchanged while advancing nextInputOffset/nextMatchOffset, consuming nextResultOffset before page.nextOffset). It adds interaction semantics rather than repeating individual field docs.

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?

States a specific verb (resolve/search) and resource (scientific names, vernacular names) with the two operating modes spelled out. It does not name or contrast with any sibling such as worms_get_taxon, so the agent must infer that 'resolve' differs from 'get', which keeps it below a 5.

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?

Gives concrete selection rules: fuzzy only for scientific names, vernacularMatch 'contains' for substring common names, and explicit resume protocol with continuation offsets. It omits when to prefer a sibling tool (e.g., worms_get_taxon for a known ID), so there is clear context but no exclusions.

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.