Skip to main content
Glama

Search catalog

search_catalog
Read-onlyIdempotent

Find which dataset answers a weather question when no dedicated tool fits: ranks the data catalog (model grids, radar, satellite, outlooks, observations) by the question's words and returns the best datasets with variable, units, cadence, a one-line why and the exact call (tool and arguments) to run next. Pass lat/lon, or domain, to keep only datasets covering the place; without one, Alaska/Hawaii twins fold into the CONUS dataset. Calls are ready for "now"; for a past time set time_start/time_end (or at where the tool supports it). Free; no network call.

Input Schema

NameRequiredDescriptionDefault
latNoLatitude of the place (with lon).
lonNoLongitude of the place (with lat).
kindNoOnly this dataset kind.
limitNoHits to return (1-10, default 5).
queryYesThe question or keywords, in the user's words.
domainNoCoverage filter when there is no point; not with lat/lon.
familyNoOnly this source family (e.g. "nbm", "mrms").

Output Schema

NameRequiredDescriptionDefault
hitsYes
noteNo
queryYes
domainNoThe coverage filter applied: the point's domain, or `domain`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedOutput schema / properties / hits / items / properties / call / description
      Previous value: -"The exact call that answers from this dataset. Absent when that tool is not on this connection; see `connect`."New value: +"The exact call that answers from this dataset; through call_tool when that tool is not on this connection."
    • changedOutput schema / properties / hits / items / properties / connect / description
      Previous value: -"With no `call`: the path that serves this connection's toolsets plus that one, e.g. /x/core,catalog,guidance."New value: +"With `toolset`: the path that serves this connection's toolsets plus that one, e.g. /x/core,catalog,guidance."
    • changedOutput schema / properties / hits / items / properties / toolset / description
      Previous value: -"With no `call`: the toolset whose tool answers this dataset."New value: +"When this connection does not list that tool: its toolset."
  2. Changed2 schema fields changed
    • removedInput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
    • removedOutput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
  3. Changed2 schema fields changed
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedOutput schema / properties / hits / items / properties / call / properties / arguments / properties
      Added value: +{}
  4. Changed4 schema fields changed
    • changedOutput schema / properties / hits / items / properties / call / description
      Previous value: -"The exact call that answers from this dataset."New value: +"The exact call that answers from this dataset. Absent when that tool is not on this connection; see `connect`."
    • addedOutput schema / properties / hits / items / properties / connect
      Added value: +{
      +  "description": "With no `call`: the path that serves this connection's toolsets plus that one, e.g. /x/core,catalog,guidance.",
      +  "type": "string"
      +}
    • addedOutput schema / properties / hits / items / properties / toolset
      Added value: +{
      +  "description": "With no `call`: the toolset whose tool answers this dataset.",
      +  "type": "string"
      +}
    • changedOutput schema / properties / hits / items / required
      Previous value: -[
      -  "dataset_id",
      -  "title",
      -  "kind",
      -  "why",
      -  "call"
      -]New value: +[
      +  "dataset_id",
      +  "title",
      +  "kind",
      +  "why"
      +]
  5. Added

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, yet the description still adds real value: it discloses cost ('Free; no network call'), the ranking basis (query words), the returned payload shape (variable, units, cadence, why, exact call), and a non-obvious geographic folding behavior. The only soft spot is that the time_start/time_end mention is ambiguous about whether it is a search_catalog argument (it is not in the schema) or an argument to the returned call.

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 is front-loaded in the first clause and every sentence carries information (ranking basis, return shape, geographic scoping, time handling, cost). The opening sentence is long and parenthetical-heavy, packing the catalog categories and return fields into one breath, which slightly hurts scanability.

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?

With a full output schema and complete annotations, the description only needs to cover routing, scoping, and surprise behaviors — and it does all three, including the non-obvious CONUS folding and the 'calls are ready for now' timing rule. An agent has enough to call this correctly and interpret the response.

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?

Schema coverage is 100%, so the baseline is 3; the description still adds meaning by explaining the lat/lon vs `domain` tradeoff and the AK/HI-to-CONUS folding that the enum alone does not convey. It loses a point for referencing `time_start`/`time_end`/`at`, which appear to be arguments of the suggested downstream call but read as if they were parameters of this tool.

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?

States a specific verb and resource: it ranks the data catalog (grids, radar, satellite, outlooks, observations) by the question's words and returns the best datasets plus the exact downstream `call`. It also positions itself against siblings by scoping itself to cases where 'no dedicated tool fits', which distinguishes it from get_forecast/query_dataset/list_datasets.

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

Usage Guidelines5/5

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

Gives an explicit routing rule ('when no dedicated tool fits'), explicit scoping instructions (pass lat/lon or `domain`; without one, AK/HI twins fold into CONUS), and explicit temporal guidance (calls are ready for 'now'; use time_start/time_end for past times). Little 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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.