ameriflux-mcp

Overview Schema Source Related Servers Discussions Admin

Search AmeriFlux and FLUXNET sites

amf_search_sites

Read-onlyIdempotent

Search AmeriFlux, FLUXNET2015 and FLUXNET-CH4 tower sites by location, ecosystem, climate, network, variables, data product or years; get compact site summaries, facets and paging.

Instructions

Find flux tower sites in the AmeriFlux (856), FLUXNET2015 (212) and FLUXNET-CH4 (81) catalogs by words, place (bbox or near a point), IGBP ecosystem, Köppen climate, country/state, status, member network (NEON, LTER, ...), data product and policy, years with data, measured variables or gas species. Returns compact site summaries with years per product, facets over all matches, and paging. Next: call amf_get_site for one site or amf_get_availability for exact years.

Input Schema

Name	Required	Description	Default
`gas`	No	Flux gas species, e.g. ['CH4'] or ['CO2', 'H2O'].
`bbox`	No	[west, south, east, north] in decimal degrees (no antimeridian crossing).
`igbp`	No	IGBP classes, e.g. ['DBF', 'ENF'] (see the vocabulary).
`near`	No	Sites within radius_km of a point.
`sort`	No	Default: distance with near, relevance with query, else site_id.
`limit`	No
`query`	No	Words matched against site ID, name, state, country, NEON code and networks (every word must match; prefixes count, e.g. 'harv').
`state`	No	US state or province codes, e.g. ['NM', 'AZ'].
`years`	No	Data overlapping a year or range ('2015', '2010-2015') in the chosen product (default: BASE for AmeriFlux sites, the FLUXNET tier range otherwise).
`offset`	No
`policy`	No	CCBY4.0, LEGACY (AmeriFlux) or TIER2 (Tier-Two-only FLUXNET2015/CH4 sites). CC-BY-4.0, Legacy and Tier2 spellings are accepted.
`status`	No	AmeriFlux tower status.	any
`country`	No	Country codes as in site IDs ('US', 'CA', 'BR') or names ('Canada').
`koeppen`	No	Köppen codes or prefixes, e.g. ['Dfb'] or ['B'].
`network`	No	Member networks besides AmeriFlux, e.g. ['NEON'], ['LTER'], ['Phenocam'].
`product`	No	Only sites with data in BASE-BADM, FLUXNET (FLUXNET-1F), FLUXNET2015 or FLUXNET-CH4.
`min_years`	No	At least this many data years.
`collection`	No	ameriflux (856 sites), fluxnet2015 (212), fluxnet_ch4 (81) or all.	all
`base_variable`	No	FP Standard base names every site must measure, e.g. ['FCH4', 'SWC'].

Output Schema

Name	Required	Description	Default
`page`	Yes
`notes`	No
`sites`	Yes
`facets`	Yes
`source`	No
`resolved`	No
`nextSteps`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 25, 2026

TDQS

A3.9/5.0

Behavior3/5

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds that results include years per product, facets over all matches, and paging — useful behavioral context, though an output schema exists and covers the return shape in more detail.

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?

Two dense sentences: the search capabilities are front-loaded after the verb, and the routing advice comes last. The long filter list is information-packed but borders on a run-on; still, every clause corresponds to an actual query dimension.

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?

For a 19-parameter search tool with full annotations and an output schema, the description covers what can be searched (place, ecosystem, climate, networks, products, variables), what comes back, and where to go next. No major gap an agent needs to call it correctly.

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 89%, so the schema documents nearly all 19 parameters including defaults and formats. The description's enumeration of filter categories largely restates what the schema already provides, adding little syntactic or semantic detail beyond it. 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?

Opens with a specific verb and resource ('Find flux tower sites') and names the three catalogs with site counts. The enumerated filter dimensions make its scope clearly distinct from siblings like amf_get_site or amf_search_variables.

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

Usage Guidelines4/5

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

The closing sentence routes the agent explicitly: use amf_get_site for a single site, amf_get_availability for exact years. That is a clear next-step rule, but it does not state when to prefer this search over the sibling amf_search_variables, nor any exclusions.

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

Deploy Server