Lilambd Data for Agents

biodiversity

Biodiversity by Place. How well is life recorded here? One API for any point on Earth, built from the GBIF occurrence snapshot of 1 October 2026 and counted on a fixed 0.5 degree grid (about 55 km). Routes: /gaps (level, country, admin1, max_records, stale, min_cells, limit, offset); /cells (country, admin1, lat, lon, min_records, max_records, sort, limit, offset); /place (lat*, lon*, top, species); /admin1 (country*, by, limit, offset); /nearby (lat*, lon*, radius_cells, limit, offset); /decades (country); /summary; /countries (by, continent, min_cells, limit, offset); /admin1/{code}; /cells/{cell_id} (scheme); /countries/{iso2}. Paid $0.005 USDC per call via x402 (_meta["x402/payment"]); set sample=true for a free 3-row preview.

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": {
      "route": "<route>"
    },
    "name": "biodiversity"
  }
}

Input Schema

Name	Required	Description
`route`	Yes	One of: /gaps, /cells, /place, /admin1, /nearby, /decades, /summary, /countries, /admin1/{code}, /cells/{cell_id}, /countries/{iso2}. Replace {placeholders} with a value, e.g. /search or /HND.
`params`	No	Query parameters, e.g. {"q":"tokyo","limit":"50"}
`sample`	No	Free preview, max 3 rows

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 3, 2026

TDQS

A3.7/5.0

Behavior4/5

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

No annotations are provided, so the description carries the full burden, and it discloses the expensive behavioral facts an agent needs: every call is a paid x402 transaction at $0.005 USDC with payment passed in _meta['x402/payment'], and a free 3-row sample exists to avoid charges. It also pins the data snapshot date and grid resolution, so results are interpretable. It does not cover failure behavior if payment is missing or rate limits.

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?

Purpose and provenance are front-loaded, then routes are packed into a single semicolon-delimited inventory that carries real information (route -> accepted params) rather than filler. It is dense and hard to scan as one paragraph, but for 11 routes plus payment terms it avoids redundancy. Minor improvement would be line-breaking the route list.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 11-route API with a nested params object and no output schema, the description covers provenance, grid, pricing, route/parameter surface, and the sample flag. What it omits is what each route actually returns — the distinction between /gaps, /cells, /place and /summary is inferable from names only, and parameter value domains are unstated. Adequate to make a call, but not enough to choose confidently among the '/...' siblings.

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?

The top-level schema only describes a generic free-form params bag, so the description is the only source of per-route parameter meaning — it enumerates which keys each route accepts (level, country, admin1, max_records, stale, min_cells, limit, offset, etc.) and star-marks required ones (lat*, lon*, country*). It does not explain what individual values mean (valid level names, units of max_records, allowed sort fields), so an agent can form a request but may misfill it.

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?

Names a specific resource (biodiversity recording completeness) with provenance detail: GBIF occurrence snapshot of 1 October 2026 on a fixed 0.5 degree (~55 km) grid. The purpose question 'How well is life recorded here?' plus the route inventory makes clear it returns species-recording coverage metrics at multiple geographies. Siblings are unrelated APIs (airports, calendars, hazard), so differentiation is implicit but obvious.

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?

Route names and their parameter lists imply what each endpoint is for (e.g. /nearby takes lat/lon/radius_cells, /gaps takes min_cells and stale), but the description never says in prose when to pick /gaps vs /cells vs /place, or what the trade-offs are. The one explicit operating instruction is the pricing/preview path: paid $0.005 USDC per call via x402, or sample=true for a free 3-row preview. Useful, but route-selection guidance is left to inference.

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

All Lilambd Data for Agents 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.

Resources

Need Help?