Passage Data — cited environmental limits

Map columns to Darwin Core

map_to_darwin_core

Read-onlyIdempotent

Which Darwin Core term does each column of a species file map to, before it goes to GBIF? Which Darwin Core term each column of a species occurrence or checklist file maps to, by the header rules our file-to-archive converter runs before it checks values: for each column the term, the rule that decided it (exact name or alias, a word of the name, a packed coordinate pair, a grid reference), the alias that matched and where it came from, or a coded refused block saying why it stays unmapped (no term or alias matches, several columns tie for one term, another column holds the term, blank in the sample). Also names the terms GBIF requires of an occurrence or a checklist dataset that no column carries. Values are not checked here: each mapped column names the value check it must still pass.

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": {
      "columns": "<columns>"
    },
    "name": "map_to_darwin_core"
  }
}

Input Schema

Name	Required	Description	Default
`columns`	Yes	The file's header names, in order, exactly as written.
`sample_rows`	No	Optional data rows, each an array aligned with `columns` or an object keyed by header: a column blank in every row is skipped as the converter skips it, and a column of distinct codes is named an identifier.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 14, 2026

TDQS

A3.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: it enumerates the decision rules (exact/alias, partial word, packed coordinate pair, grid reference), explains the coded `refused` block and its reasons, notes that required-but-absent terms are listed, and discloses that sample_rows change behavior (blank column skipped, distinct-code column treated as identifier).

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 opening question ('Which Darwin Core term does each column of a species file map to...') is immediately restated in a longer variant, wasting the front-loaded position. The remainder is one sprawling sentence with heavily nested clauses, so the substance is present but poorly structured and repetitive.

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 must convey return shape, and it largely does: per-column term, deciding rule, matched alias and its source, or a coded refusal reason, plus the list of GBIF-required terms no column carries. This is substantially complete for a two-parameter deterministic mapper.

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%, with both `columns` and `sample_rows` fully documented in the schema, so the baseline is 3. The description reinforces sample-row effects but adds no syntax or format detail beyond what the schema already supplies.

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 description states a specific verb+resource: it maps each column of a species occurrence or checklist file to a Darwin Core term before GBIF ingestion. It clarifies the scope (header-rule mapping, not value checking), which helps separate it from build_dwc_archive, though no sibling is named explicitly.

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?

Usage context is implied via 'before it goes to GBIF' and 'Values are not checked here: each mapped column names the value check it must still pass,' which hints at a pre-flight step preceding check_value/check_values. However, it never explicitly says when to use this tool versus build_dwc_archive or the check_* siblings, so it stays implied rather than stated.

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.