Skip to main content
Glama
Wewoc

Garmin Local Archive

by Wewoc
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

query_context

Query weather, pollen, and air quality context for a field over a date range, with alias and bundle resolution and daily or intraday results.

Instructions

Query external context data (weather, pollen, air quality) for a field over a date range. Fans out across all sources that recognize the field.

v1.7.1.3 field-filter fix: field is now passed through to the SQLite branch — previously it was silently dropped (this call site never forwarded it at all), so every call returned all four context categories (weather/brightsky/airquality/pollen) regardless of what was asked for, inflating a single-value answer to hundreds of KB and confusing small local LLMs summarizing the result. Same fix as query_health()'s v1.7.1.1/v1.7.1.2 field-filter, applied here with a one-session delay.

v1.7.1.4 unknown-field detection (this session): a field that is valid for query_context() but unregistered anywhere in the context domain previously returned the same silent {"context": {}} as a registered field with no data in the requested range — the caller (LLM or human) could not tell "field does not exist" apart from "field exists, no data here". This is checked BEFORE the _route_query() switch below, so the check applies regardless of which branch (sqlite/live) ends up serving the request — the field registry itself (mcp_map.list_available_fields) is unrelated to that routing decision.

Three unknown-field outcomes, checked in this order:

  1. Unambiguous near-match against the known context field names (e.g. a typo) -> auto-resolved, field_used replaces the caller's input transparently, but the substitution is always visible via _meta.field_resolved_from / _meta.field_used — never a silent rewrite.

  2. The field IS registered, but under query_health's domain, not query_context's (e.g. "sleep") -> a domain-specific error naming query_health, no did_you_mean list (a context-domain suggestion would be wrong here).

  3. Neither of the above (e.g. a category name like "weather", or no close match at all) -> a generic "unknown field" error, with a did_you_mean suggestion list when difflib found any candidates, without one when it found none.

A valid field's result (with or without data in range) is returned exactly as before this session — none of the above runs unless field is unrecognized.

v1.7.1.5 category bundles (this session): a field value naming a known bundle key ("weather"/"pollen"/"air") is resolved BEFORE any of the three unknown-field outcomes above -- a bundle name is never a registered field itself, so without this check it would always fall through to the generic "unknown field" branch. Each bundle field is queried individually through the SAME sqlite/live routing weiche used everywhere else in this function -- the bundle path only adds collection, flattening, and collision tie-breaking on top, it does not bypass or duplicate the existing data-access path. See _CONTEXT_CATEGORY_BUNDLES above for the priority-list mechanics.

v1.7.1.11 Session 4 -- resolution is decided by the field name itself, same principle as query_health(): a "_series" suffix always means intraday/timeseries data, a plain field name always means a single daily value -- no field in this archive offers both under one name, so the caller already knows which shape to expect before the query even runs. This holds regardless of which branch (sqlite/live) below ends up serving the request -- both branches return the same "values" contract (see mcp_sql.get_context_range() / clients/mcp_sql.py, and maps/_context_io.py's read_summary_field()/ read_raw_field() for the underlying {"date","value"} vs. {"date","series"} shapes).

v1.7.1.12 -- CONTEXT_FIELD_ALIASES / CONTEXT_FIELD_AMBIGUOUS checked here, BEFORE the bundle check, mirroring query_health()'s HEALTH_FIELD_ALIASES ordering (an alias hit is more certain than a near-match and should not have to pass through the bundle or difflib logic). Three outcomes now precede the pre-existing bundle/ unknown-field handling below:

  1. CONTEXT_FIELD_ALIASES hit -> auto-resolved, field_used/ field_resolved_from set, same as the alias path in query_health().

  2. CONTEXT_FIELD_AMBIGUOUS hit -> NOT resolved. Returns the existing error/did_you_mean shape with a field-specific error message and the known candidate list as did_you_mean -- no new response shape (see CONTEXT_FIELD_AMBIGUOUS's own comment for the rationale). field_used/field_resolved_from are NOT set.

  3. Neither -> falls through unchanged to the bundle check and the existing unknown-field difflib logic below. See NOTES_v1.7.1.12.md for the full candidate-by-candidate analysis behind both tables.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fieldYes
date_toYes
date_fromYes
resolutionNodaily

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.9/5.0
Behavior4/5

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

With no annotations, the description carries the behavioral burden and does disclose genuinely useful traits: unknown-field detection with three ordered outcomes, transparent alias/bundle auto-resolution surfaced via _meta.field_resolved_from/_meta.field_used, and the guarantee that valid-field results are unchanged. That is substantial disclosure about error semantics and silent-rewrite prevention, even if the delivery is changelog-shaped.

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

Conciseness1/5

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

The description is dominated by session-by-session release notes (v1.7.1.3 through v1.7.1.12), internal class/file references (mcp_sql.get_context_range(), clients/mcp_sql.py, NOTES_v1.7.1.12.md) and duplicated logic explanations that add no value for an agent. Only the first two sentences are agent-facing; the remaining bulk is noise and is not front-loaded around caller needs.

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?

There are no annotations, no output schema and 0% schema coverage, so the description must carry everything. It does cover return shapes ({"date","value"} vs {"date","series"}) and field-resolution behavior well, but it omits date-format expectations, the 'resolution' parameter semantics, and any read-only/permission context. Partially complete but with clear gaps for a 4-parameter query tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate for all four parameters. It thoroughly covers 'field' (aliases, bundles, series suffix), but date_from/date_to formats are never specified and the 'resolution' parameter (default 'daily', and how it relates to the '_series' shape) is never tied back to the schema. Two of four parameters remain semantically undocumented.

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 opening sentence gives a clear verb+resource+scope: 'Query external context data (weather, pollen, air quality) for a field over a date range. Fans out across all sources that recognize the field.' That is enough to distinguish it from query_fit_activities or query_raw, though it never explicitly contrasts itself with sibling query_health beyond a passing mention of its domain. The purpose is buried under heavy version-history prose.

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

Usage Guidelines2/5

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

The description never states when an agent should choose query_context over query_health, query_raw, or list_available_fields. It explains internal resolution mechanics at length but offers no when-to-use / when-not-to-use context, leaving the routing decision entirely to the caller's inference.

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