---
summary: "Verify extraFilters honor on every find_* tool and relabel the rendered filters block as `Filters sent to server` so the trace stops implying the upstream applied them."
breaking: false
---

# 0.5.1 — 2026-05-05

Two field-test wrong-results regressions on `find_*` tools. Both classes shared a root cause: the trace claimed filter values were honored when the upstream had silently dropped them.

## Fixed

- **`find_*` tools now post-hoc-verify `extraFilters` keys against the returned rows.** New `buildExtraFilterChecks` helper in `src/mcp-server/tools/shared/find-helpers.ts` infers the row column for each `extraFilters` key (exact match, then trailing-`s` strip — `locationDbIds → locationDbId`, `locationNames → locationName`) and feeds a `FilterMatchCheck` into `checkFilterMatchRates`. When the upstream silently ignored a filter (e.g. `locationName` on `/studies` — not a valid spec key), every returned row carries an unrequested value and the validator emits a warning instead of letting the empty trace falsely confirm the filter was applied. Keys that don't resolve to a column produce a single grouped warning so the agent knows the trace can't speak to whether they were honored. Wired across `find_studies`, `find_germplasm`, `find_observations`, `find_variables`, `find_variants`, `find_images`, and `find_locations`. `find_variants` had no post-hoc validator at all before this change — it now runs `checkFilterMatchRates` for the first time.
- **`find_*` tools render the wire-shape filters block as `Filters sent to server` instead of `Applied filters`.** "Applied" suggested the upstream honored every key; "sent to server" is true regardless of honor and pairs cleanly with the new verification warnings. Updated label and JSDoc in `renderAppliedFilters` (function name kept for diff minimality — only the rendered string changes).