Skip to main content
Glama

Passage Data — cited environmental limits

Find a species' designations

find_designations
Read-onlyIdempotent

Is a species protected or at risk, and under which act, list and edition? What the species registers we hold say about one species: its status under each list that names it (the US Endangered Species Act lists, Canada's Species at Risk Act and COSEWIC, provincial acts, the IUCN Red List, CITES, CMS, the EU Habitats and Birds Directives' annexes, UK schedules). Each row gives the status as printed, an outcome (listed, listed_qualified = only under a population or subspecies you must confirm, watch_listed, assessed_not_listed, ...) and a cite block (instrument, edition, the line the register prints, source URL and sha256). Registers searched that do not name the species are in silent, each with what its silence means. When none names it the answer is a refused block naming every register searched and its edition: say that these registers do not name it, 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": "find_designations"
  }
}

Input Schema

NameRequiredDescriptionDefault
placeNoISO 3166 code of where the species is: a country (US, CA, GB, FR) or a state or province (US-CA, CA-ON, GB-SCT). Only the registers that reach it are searched, with the global ones (IUCN, CITES, and CMS where the country is a Party). Omit to search every register.
speciesYesA scientific name (Myotis lucifugus, Rana draytonii; authorship allowed) or a common name exactly as a register prints it (little brown myotis, caribou).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.2/5.0
Behavior5/5

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

Annotations cover safety (readOnlyHint, idempotentHint, destructiveHint=false), and the description adds substantial behavioral context beyond them: the meaning of `outcome` values (listed, listed_qualified requiring confirmation, watch_listed, assessed_not_listed), the contents of the `cite` block (instrument, edition, printed line, source URL, sha256), and the `silent`/`refused` semantics. This tells the agent exactly what it will receive and how to phrase the answer.

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?

The description is dense and front-loads the core question before detailing output structure. It is long, but nearly every clause carries new information (register list, outcome vocabulary, cite fields, refusal rule) rather than restating the title.

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?

There is no output schema, so the description must carry the return-value burden, and it does: rows with status/outcome/cite, `silent` registers, and the `refused` block are all explained. An agent has everything needed to invoke the tool and interpret every response shape.

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 fully documented, including the `place` ISO-code syntax and the 'omit to search every register' behavior. The description adds no parameter-level detail beyond the schema, so the baseline 3 applies.

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?

The description opens with a precise framing question ('Is a species protected or at risk, and under which act, list and edition?') and then names the exact resource: one species' status under each register that names it, enumerating the instruments (ESA, SARA, COSEWIC, IUCN, CITES, CMS, EU Directives, UK schedules). This is a specific verb+resource and is easily distinguished from siblings like screen_species or find_limits.

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?

The description gives strong operational guidance for interpreting and reporting results (the `refused` case and the warning never to say 'unprotected'), which is genuinely useful. However, it never states when to choose this tool over siblings such as screen_species or check_dmr, so tool-selection 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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.