neon-mcp

Overview Schema Source Related Servers Score Discussions Admin

Search NEON data products

neon_search_products

Read-onlyIdempotent

Search NEON ecological data products by keywords, theme, science team, level, status, site, domain, or date. Filter results with facets, view site counts and month ranges, then check availability or product details.

Instructions

Find NEON data products by keywords, theme, science team, level, status, site, domain or date coverage; ranked results with facets and each product's site count and month range. Served from a cached catalog (no token). A bare code such as DP1.10003.001 matches exactly. Next: call neon_get_availability with a productCode, or neon_get_product for detail.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`site`	No	Only products with data at this site (code or name).
`sort`	No		relevance
`level`	No	Data product level 1-4.
`limit`	No
`query`	No	Free text (all words must match names, keywords, themes or descriptions; small typos tolerated) or a product code such as DP1.10003.001.
`theme`	No	Theme prefix, case-insensitive: Atmosphere, Biogeochemistry, Ecohydrology, 'Land Use', 'Organisms'.
`offset`	No
`status`	No	ACTIVE (default), FUTURE, RETIRED or ALL.	ACTIVE
`release`	No	Evaluate availability within one release (RELEASE-YYYY).
`domain_code`	No	Only products with data in this domain (D01-D20).
`available_to`	No	Only products with data on or before this month.
`has_expanded`	No	Only products with (or without) an expanded package.
`science_team`	No	TIS, TOS, AIS, AOS or AOP.
`available_from`	No	Only products with data on or after this month.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`page`	Yes
`items`	Yes
`notes`	No
`facets`	Yes
`source`	No
`resolved`	No
`nextSteps`	No
`didYouMean`	No
`indexSource`	Yes
`indexAgeSeconds`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 10, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already declare readOnlyHint and idempotentHint, and the description adds valuable behavioral context: it is served from a cached catalog, requires no token, returns ranked results with facets, includes site count and month range, and matches bare product codes exactly. No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences: the first states scope and filters, the second explains the cache/no-token access and exact-code matching, the third routes to follow-up tools. Every sentence earns its place and the key information is front-loaded.

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

Completeness5/5

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

For a 14-parameter search tool, the description covers purpose, filter dimensions, access behavior (cached, no token), result features, exact-match behavior, and follow-up workflows. The output schema and high parameter coverage handle the remaining details.

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 79%, so the schema already documents most parameters. The description reinforces the query semantics ('bare code matches exactly') but does not meaningfully add parameter-level details beyond what the schema provides for the uncovered sort/limit/offset parameters.

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?

The description states a specific verb ('Find') and resource ('NEON data products') and enumerates the filter dimensions (keywords, theme, science team, level, status, site, domain, date coverage). This clearly differentiates it from sibling search tools like neon_search_prototype_datasets and neon_search_taxonomy.

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 description gives clear context: search across many dimensions, served from a cached catalog. It also provides explicit next steps ('Next: call neon_get_availability... or neon_get_product') but does not explicitly state when not to use this tool versus a direct get_product lookup.

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