Skip to main content
Glama
Sign In
.

.

by idss-mesa
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

gbif_occurrence_counts_by_publishing_org

Read-onlyIdempotent

Break down occurrence counts by publishing organization UUID to identify which institutions contribute data for a query, aiding data attribution and provider acknowledgment.

Instructions

Get occurrence counts broken down by publishing organization UUID. Identifies which institutions are contributing the most data for a query. Essential for data attribution, understanding institutional contributions, acknowledging data providers, and analyzing organizational participation. Returns organization UUIDs with occurrence counts.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "gbif_occurrence_counts_by_publishing_org"
  }
}

Input Schema

NameRequiredDescriptionDefault
yearNoFilter by year or range
countryNoFilter by occurrence country
taxonKeyNoFilter to specific taxon. Example: 212 (birds) to see which organizations publish bird data
basisOfRecordNoFilter by record types
hasCoordinateNoFilter to georeferenced records

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

B3.3/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered. The description adds one genuinely useful behavioral fact — the return shape (organization UUIDs with occurrence counts), valuable since there is no output schema — but the remaining sentences are promotional rather than disclosing ordering, ranking, or pagination behavior.

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?

The core purpose and return shape are correctly front-loaded in the first and last sentences. The middle sentence is a four-item promotional list ('data attribution, understanding institutional contributions, acknowledging data providers, analyzing organizational participation') that mostly restates the same idea and does not earn its place.

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?

With annotations covering safety, a 100%-covered schema, and the description supplying the return shape, an agent has enough to call the tool. The missing piece is sibling disambiguation within the large counts_by_* family, which leaves a real risk of selecting the wrong breakdown dimension.

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 all five filters (year, country, taxonKey, basisOfRecord, hasCoordinate) are already documented, including a concrete taxonKey example. The description adds no parameter-level meaning beyond noting that results are 'for a query', so the 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 verb and resource: occurrence counts broken down by publishing organization UUID. It is clear what the tool produces, but it never differentiates itself from the many sibling aggregation tools, notably gbif_occurrence_counts_by_publishing_country and gbif_occurrence_counts_by_dataset, which an agent could easily confuse with this one.

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 implied use contexts (data attribution, acknowledging data providers, analyzing organizational participation), which signals when the tool is relevant. However, it offers no explicit when-to-use vs. when-not, and never names an alternative sibling such as counts_by_dataset or counts_by_country when a different breakdown is wanted.

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

Deploy Server

Other Tools