Skip to main content
Glama

Search recorded motions, votes and amounts

search_decisions
Read-onlyIdempotent

What a body actually DECIDED, from the approved minutes — the motion as recorded, who moved it, the roll-call tally, and any dollar figure attached. This is the structured record, not people talking: use it whenever the question is what was approved, denied, tabled, or how much something cost.

WHEN: 'Which cities approved Flock Safety cameras?', 'Show me every contract over $100k in Texas this year', 'Where did accessory-dwelling ordinances stall?', 'What did Lehi vote on last month?'. WHEN NOT: For what someone SAID, use search_meetings. For one official's record across items, use track_position. For a project's lifecycle, use application_timeline.

TWO THINGS THAT WILL MISLEAD YOU IF IGNORED: • Report outcome, not result. A passed motion TO TABLE means the item did NOT advance; 161 published motions are exactly that. outcome already combines motion_kind with result. • amount_deferred: true means the money was named inside a motion to delay or table. Never describe it as spending. • EMPTY IS NOT "NOTHING WAS DECIDED". Motions come only from minutes we have extracted, which lag the meeting and are missing for many cities. Read coverage / coverage_note before answering, and fall back to search_documents for the minutes or agenda. • unofficial_decisions are decisions heard in the RECORDING of a meeting where no official motion covers that item — usually because its minutes are not published yet. They are NOT the official record: say "according to the meeting recording" and repeat the row's record_note (it says whether the minutes are unpublished or simply have no matching motion), never present their vote_count as an official roll call, and never count them into total. Verify a specific one with get_transcript_window at its timestamp_seconds.

q matches whole words, so 'Flock' will not return a person named Flocke. Every row carries a citation_url pointing at that exact motion.

EXAMPLES: { "q": "Flock Safety" } { "q": "accessory dwelling", "outcome": "tabled" } { "min_amount_usd": 100000, "basis": ["award"], "since": "2026-01-01" }

Input Schema

NameRequiredDescriptionDefault
qNoTerm matched as a WHOLE WORD or phrase against the motion text — a vendor ('Flock Safety'), an instrument ('Ordinance 26-08'), a subject ('accessory dwelling'). Whole-word matching means 'Flock' will not match a person named Flocke. Omit to browse by city, date or amount alone.
basisNoRestrict to how the money is being used. 'award' is a contract/grant/purchase; 'appropriation' is budget/bond/levy; 'fee' is a fee, fine or waiver. Rates and third-party figures are never returned.
limitNoMax motions returned, newest first. Default 40.
matchNoHow `q` is matched. 'phrase' (default): the whole of `q` as one whole-word phrase — for an instrument or vendor ('Ordinance 26-08', 'Flock Safety'). 'any': each word of `q` as a whole word, in any order, a plural matching its singular; a motion matching more of the words ranks first. Use 'any' for a subject described in a resident's words ('sycamore trees', 'budget adopted').phrase
sinceNoMeetings on or after this date (YYYY-MM-DD).
untilNoMeetings on or before this date (YYYY-MM-DD).
citiesNoCity-slug allow-list (e.g. ['lehi-ut']). Omit to search every city the plan allows.
outcomeNoFilter by what happened to the ITEM, not to the motion. 'tabled' means a motion to table passed, so the item did not advance. Use 'denied' or 'tabled' to find where something stalled — for policy-diffusion questions that is the more informative half.any
min_amount_usdNoOnly motions carrying a parsed dollar figure at or above this many whole dollars. Use 0 for every motion that carries any dollar figure. Excludes tax rates, third-party figures and deferred amounts automatically.

Output Schema

NameRequiredDescriptionDefault
totalYesNumber of OFFICIAL motions returned, from published minutes (not an estimate — this is the row count). Does not include unofficial_decisions; see `returned`.
blockedYesTabled, denied, continued or withdrawn — the item did not advance.
summaryYesOne sentence saying what came back, official and recording-reported separately. Read this first: `total` counts OFFICIAL motions only, so a response can carry decisions while total is 0.
approvedYes
coverageYesMinutes coverage for each queried city that returned NO decisions, so an empty result can be told apart from a gap in our record. Omitted cities had hits. Empty when every city had hits, or when more than 8 cities came back empty (see coverage_note).
returnedYesEverything returned: `total` (official motions) + `unofficial_total` (recording-reported decisions).
decisionsYes
citiesQueriedYes
coverage_noteYesPlain-language caveat to relay when results are thin because minutes have not been extracted. Null when every queried city returned decisions.
citiesWithHitsYesHow many distinct cities appear in the results. The useful denominator for 'how many cities have done this'.
totalAmountUsdYesSum of the returned motions' amounts, in whole dollars, excluding rates, third-party figures and deferred amounts. NULL when none carried a figure. Treat as a floor, not a budget: budgets, financings, awards and amendments legitimately overlap, so this can double-count the same dollars across instruments.
unofficial_totalYesNumber of unofficial_decisions returned. NOT included in `total`, `approved` or `blocked`, which count official motions only.
unofficial_decisionsYesDecisions heard in the RECORDING of a meeting where no official motion covers that item: usually the approved minutes have not been published or extracted yet, and sometimes the published minutes have no motion for the item. NOT the official record: report them as 'according to the meeting recording' and repeat each row's record_note, which says which of the two cases applies. Never merge them into official results or present vote_count as an official roll call. A row is dropped when a published motion covers the same agenda item, so these do not restate `decisions`. Omitted when a dollar filter is set (transcript decisions carry no parsed amounts).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive, open world), so the bar is lower — yet the description adds substantial non-obvious behavior: outcome vs. result semantics, amount_deferred meaning, that empty results reflect extraction lag rather than absence of decisions, that unofficial_decisions must not be counted in total or presented as official roll calls, and that every row carries a citation_url. This is exactly the kind of context annotations cannot carry.

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?

Well front-loaded, with WHAT, WHEN, WHEN NOT and pitfalls in scannable blocks despite the length — justified by a 9-parameter tool with subtle semantics. Minor duplication: the 'Flock'/'Flocke' whole-word illustration restates the q schema description verbatim and could be dropped.

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?

An output schema exists, so return values need not be explained; the description instead covers the interpretive layer the schema cannot — coverage/coverage_note caveats, how to handle unofficial_decisions, and where to verify a specific one (get_transcript_window). Complete for the tool's complexity.

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 and the schema documents every parameter thoroughly. The description adds value through worked example invocations that demonstrate non-obvious combinations (outcome:'tabled' with a free-text subject; min_amount_usd with basis:['award'] and since), plus the outcome-not-result guidance. It repeats the whole-word matching rule already in the schema, so it is not a clean 5.

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 ('search recorded motions, votes and amounts') and immediately scopes it: the structured record of what a body decided, drawn from approved minutes. It also names the sibling it is not ('not people talking... use search_meetings'), so an agent can route without opening a schema.

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?

Explicit WHEN section with natural-language queries, an explicit WHEN NOT section naming three alternatives (search_meetings, track_position, application_timeline) with the condition selecting each, and a documented fallback (search_documents) when coverage is empty. Nothing 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.

Resources