ameriflux-mcp

Overview Schema Source Related Servers Discussions Admin

Preview a local AmeriFlux or FLUXNET data file

amf_preview_data

Read-onlyIdempotent

Preview and summarize local AmeriFlux, FLUXNET, or FLUXNET2015 CSV files in place or in zip archives, including column stats, time-window filters, QC checks, and paged rows.

Instructions

Summarize or page through a local BASE, AmeriFlux FLUXNET or FLUXNET2015 CSV, in place or inside its zip: time step and range, per-column count, missing (-9999), min, max, mean and out-of-range counts, units per resolution, a time window, a QC filter, UTC timestamps from the site's BIF, a SUBSET column view, and aux tables. Stops within a byte and time budget. stdio only. Next: call amf_describe_variables on columns to decode.

Input Schema

Name	Required	Description	Default
`end`	No	Last time (inclusive): end='2012' keeps all of 2012.
`file`	No	A file or 'archive.zip::member.csv', relative to a local root (see amf_list_files). Or give site and product instead.
`mode`	No	summary: per-column statistics; rows: a window of rows.	summary
`site`	No	Newest local file of this site.
`view`	No	subset: only FLUXNET2015 SUBSET variables (AmeriFlux FLUXNET files).	full
`start`	No	First time, e.g. 2012, 2012-06, 2012-06-01T12:00.
`offset`	No	Rows to skip within the time window.
`qc_max`	No	HH/HR FLUXNET: keep values whose _QC flag is at most this.
`to_utc`	No	Add UTC timestamps (offset from the site's BIF).
`columns`	No	Columns by name (default: up to 80 in summaries).
`product`	No	With site: BASE-BADM (default), FLUXNET or FLUXNET2015.
`max_rows`	No	Rows per page (capped by the server).
`resolution`	No	Member of an archive to read (default HH; HR sites match HH).
`qc_min_fraction`	No	DD and coarser FLUXNET: keep values whose _QC fraction is at least this.

Output Schema

Name	Required	Description	Default
`page`	No
`rows`	No
`scan`	Yes
`notes`	No
`source`	No
`columns`	Yes
`fileInfo`	Yes
`resolved`	No
`nextSteps`	No
`rowColumns`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 25, 2026

TDQS

A3.7/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. The description adds useful operational context: output 'stops within a byte and time budget' and the tool is 'stdio only', which matters for an agent's expectations around scope and environment.

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?

The description front-loads the core purpose and uses dense but informative phrasing. The first sentence is a long feature list that could be more structured, but every item maps to a real capability and there is no filler.

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 complex 14-parameter local preview tool with an output schema, the description covers data sources, high-level output content, resource budget limits, stdio-only operation, and the recommended next step. It leaves details like file-vs-site/product mutual exclusivity to the schema, which is reasonable.

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?

The schema has 100% description coverage across 14 parameters, so the baseline is 3. The description adds high-level feature mapping (time step/range, QC filter, BIF-based UTC timestamps, SUBSET view, aux tables) but does not add parameter-specific syntax or defaults beyond what the schema already provides.

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?

States specific verbs ('summarize or page through') and a precise resource ('local BASE, AmeriFlux FLUXNET or FLUXNET2015 CSV, in place or inside its zip'). It is clearly scoped to local files and previewing, though sibling differentiation appears mainly as a next-step reference to amf_describe_variables rather than an explicit comparison.

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?

Implies the tool is used to preview before decoding, via 'Next: call amf_describe_variables on columns to decode', and notes 'stdio only'. However, it does not say when to choose this over amf_list_files, amf_get_badm, or other siblings, nor when not to use it.

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

Deploy Server