Skip to main content
Glama

Passage Data — cited environmental limits

Screen occurrence records for exposed listed species

screen_exposure
Read-onlyIdempotent

Do these occurrence records publish where a listed species lives too precisely? Occurrence records in one call, up to 5000: each record's species name and coordinates as published, optionally coordinateUncertaintyInMeters, a place, and what the file declares about the point (dataGeneralizations, informationWithheld, the eventID, locationID or locality it shares with other records, an iNaturalist export's coordinates_obscured, geoprivacy, public_positional_accuracy). Our engine's names screen answers as it answers a file dropped on passage-data.com: for each species a register lists, listed_by gives which register lists it (its status, whether it applies where the records are, the line the register prints) and exposure how many of its records sit at a coordinate finer than a 0.01 degree grid (about 1.1 km, precise enough to walk to), and how many of those a rounding would not protect because another record states the same position (withhold those). treatment is Chapman 2020's, GBIF's best practice for sensitive species: the category the data holder's documented answers to its questions reach (send them as determinations) with its grid, the Darwin Core terms to fill and how many records it would round and withhold; without answers, a coded refusal (sensitivity.criteria_unevaluated) naming the next question, beside what each category would do. A listing is not that determination. Every register screened is named with its edition: a species no register lists is a statement about those registers, never that it is unprotected. Nothing sent is kept.

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": {
      "records": "<records>"
    },
    "name": "screen_exposure"
  }
}

Input Schema

NameRequiredDescriptionDefault
placeNoISO 3166 code of where the records are: a country (CA, US, FR, GB) or a subdivision (CA-QC, US-CA, GB-SCT). Omit it and the screen places them by their own points against public boundaries, and says so.
recordsYesThe occurrence records, in order. Fields other than these are not read (their names are listed back in `query.fields_ignored`).
determinationsNoThe data holder's documented answers to Chapman 2020's questions, by number: {"1.1": true, "1.2": false, ...}. An answer without them lists every question in `treatment.questions`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

B3.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds meaningful context beyond annotations: 'Nothing sent is kept' (no data retention), the exposure computation logic (0.01 degree grid, rounding/withholding rules), and the shape of the treatment output. It does not contradict any annotation.

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

Conciseness2/5

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

The description is a dense, run-on wall of text with nested parentheticals and undefined terminology, far exceeding what is needed. Only the first sentence is front-loaded; the remainder is difficult to scan and would benefit from clear headings or bullet points.

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 return values, and it does so: listed_by (register status), exposure (counts at fine grids and same-position records to withhold), treatment (Chapman categories, Darwin Core terms, records rounded/withheld), and sensitivity.criteria_unevaluated. It also notes fields_ignored and the 5000-record limit. The coverage is broad, though the prose is hard to parse and could omit error-handling details.

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 the schema already documents all three parameters and the 5000-record limit. The description largely restates what the schema already provides (list of accepted fields, place omission behavior) without adding syntax, format, or edge-case semantics that the schema lacks. 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 first sentence states a specific screening question ('Do these occurrence records publish where a listed species lives too precisely?') and the rest describes the processing and outputs, so the core verb+resource is clear. However, it never explicitly distinguishes itself from the sibling screen_species tool, and the dense jargon ('Chapman 2020's', 'passage-data.com', 'register') forces the reader to reverse-engineer the exact purpose.

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

Usage Guidelines2/5

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

The description never says when to use this tool versus alternatives, nor does it name any sibling tool as an alternative. The passing reference to 'Our engine's names screen' does not function as usage guidance; an agent gets no explicit condition that selects this tool over screen_species or map_to_darwin_core.

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.