Passage Data — cited environmental limits

Screen a species list against the registers

screen_species

Read-onlyIdempotent

Which species on a list are protected or at risk? A species list in one call: up to 500 names, each answered by find_designations itself, for one place or everywhere: its designations with their cites and the registers searched that are silent on it with what each one's silence means, or its own coded refusal (designations.none_held = no register searched names it; species.ambiguous with candidates). A register's instrument, edition, source URL and sha256 are sent once, in registers. summary counts the names listed, listed only under a population or subspecies, watch-listed, named but not listed, named by no register, ambiguous and refused, and how many names each register lists. A name no register names is a statement about these registers, never that the species is unprotected.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "species": "<species>"
    },
    "name": "screen_species"
  }
}

Input Schema

Name	Required	Description	Default
`place`	No	ISO 3166 code of where the species are: a country (US, CA, GB, FR) or a state or province (US-CA, CA-ON, GB-SCT). Omit to search every register.
`species`	Yes	The names, as the list prints them: scientific names (authorship allowed) or common names exactly as a register prints them.

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 14, 2026

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real behavioral value beyond that: it explains the response shape (per-name designations, silent registers and what silence means, coded refusals via designations.none_held and species.ambiguous), and adds a meaningful caveat that a name no register names is a statement about these registers, not that the species is unprotected.

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?

It is front-loaded with a question and the essential scope, but the central sentence is a run-on clause pile ('its designations with their cites and the registers searched that are silent on it with what each one's silence means, or its own coded refusal') that is hard to parse. Much of the return-shape detail is crammed in rather than structured, so it is packed but not effortlessly readable.

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 no output schema, the description carries the burden of explaining returns, and it does so thoroughly (registers metadata sent once, summary counts, coded refusals). For a complex two-param screening tool it covers what an agent needs to interpret results; minor gaps remain around how 'place' affects which registers are consulted.

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 both parameters are already documented in the schema. The description only restates the semantics ('up to 500 names', 'one place or everywhere') without adding format, matching tolerance, or encoding detail beyond what the schema gives. Baseline 3 is appropriate.

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 opening states a specific outcome — screening a list of species names for protected/at-risk status — and positions it as the batch counterpart to find_designations ('each answered by find_designations itself'). That lets an agent separate it from its sibling. The phrasing is dense but the purpose is unmistakable.

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?

It implies the usage case by noting 'one call: up to 500 names' and 'for one place or everywhere', and it names find_designations as the per-name engine, which hints at when to reach for this instead. However there is no explicit when-to-use/when-not statement or alternative selection rule; the agent must infer the batch-vs-single distinction.

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

All Passage Data — cited environmental limits 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.