Skip to main content
Glama

Search meeting transcripts

search_meetings
Read-onlyIdempotent

What was actually said out loud at a city council meeting, planning-commission hearing, or any other public city-government meeting — about zoning, housing, the city budget, taxes, permits, ordinances, roads, parks, police, or public comment. Keyword search across transcript segments; each hit includes speaker, snippet, timestamp, and — when the speaker matches an elected official — an official_id UUID.

WHEN: 'What did people say about X?', 'When was Y last discussed?', or any query where the value is what was spoken in a meeting. WHEN NOT: For one person's complete speaking history, use search_by_official (better signal, no false positives from name collisions). For ordinance text, packets, or attached PDFs, use search_documents.

For 'recent' or 'this year' questions pass since — the corpus runs back years, and without a window old material competes with new. For 'what did OFFICIALS say' pass officials_only — it keeps segments whose speaker matched the city roster (elected, appointed or senior staff), because everyone else is unnamed by design and their quotes cannot be cited to a person.

EXAMPLES: { "q": "short-term rentals", "cities": ["lehi-ut"] } { "q": "housing affordability", "cities": ["lehi-ut"], "since": "2026-01-01", "officials_only": true } { "q": "downtown parking", "cities": ["lehi-ut"], "meeting_types": ["city_council"] } { "q": "developer Main Street" } — last meetings across allowed cities, newest first

hits: [] means no transcript segments matched — simplify the query and retry; never report it as missing access to a city.

Input Schema

NameRequiredDescriptionDefault
qYesFree-text query matched against transcript text and agenda items. Speaker names are not matched (except on plans that show every speaker's name) — to find what a named official said, use search_by_official.
limitNoMax hits returned. Default 25, up to 150. Results are spread across cities and meetings so one verbose meeting cannot fill the response. For statewide or multi-city questions pass a high limit and filter the results yourself — that is cheaper and more complete than many narrow queries.
sinceNoOnly search meetings on or after this date (YYYY-MM-DD). Use for 'recent' / 'this year' questions — without it the corpus goes back years and old material outranks new.
untilNoOnly search meetings on or before this date (YYYY-MM-DD).
citiesNoCity-slug allow-list (e.g. ['lehi-ut']). Strongly recommended — searches every accessible city otherwise.
meeting_typesNoFilter by meeting_type values (e.g. ['city_council', 'planning_commission']).
officials_onlyNoReturn only segments whose speaker was matched to the city's official roster — elected members, appointed board members, AND senior staff (city administrator, attorney, recorder). NOT elected-only: filtering is on whether the speaker is identified at all. Use for 'what did OFFICIALS say about X'; without it, most hits are applicants and residents at the comment mic, whose names are withheld by design, so the quotes come back unattributed and cannot be cited to a person. To keep only elected speakers, cross-reference the returned official_id against list_officials.

Output Schema

NameRequiredDescriptionDefault
hitsYesTranscript segments matching the query, newest first.
totalYesNOT a count of segments containing your full query, and never safe to report to a user as 'N mentions' — count `hits`, or say the record contains 'many'. With hybrid ranking on it is the number of hits returned; otherwise it is a rough upper bound on candidates, and because matching relaxes trailing words to keep recall up, a two-word query can report tens of thousands while only dozens contain both words.
citiesQueriedYesNumber of cities actually searched.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / q / description
      Previous value: -"Free-text query matched against transcript text + speaker names + agenda items."New value: +"Free-text query matched against transcript text and agenda items. Speaker names are not matched (except on plans that show every speaker's name) — to find what a named official said, use search_by_official."
  2. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Beyond annotations, the description discloses important behavioral details: hits are transcript segments, most non-official speakers are unnamed by design and cannot be cited to a person, and empty `hits` means no transcript segments matched rather than missing access. These are meaningful operational constraints not captured by the read-only/open-world 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?

The definition is front-loaded and well-structured with WHEN, WHEN NOT, and EXAMPLES sections. Although it is somewhat long, the length is justified by the complexity and the need to route among several sibling search tools.

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?

Given the rich annotations, full input-schema descriptions, and presence of an output schema, the description is complete enough for an agent to select and invoke the tool correctly. It covers purpose, alternatives, parameter guidance, and the most important edge case for empty results.

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 description coverage is already 100%, so the schema carries most parameter meaning. The description still adds useful contextual guidance for `since`, `officials_only`, and the need to cross-reference `official_id` with list_officials for elected-only filtering, though it does not add much beyond the schema for every parameter.

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 names a specific verb and resource: keyword search across public city-government meeting transcript segments, with hits containing speaker, snippet, timestamp, and official_id where matched. It also explicitly distinguishes itself from sibling tools such as search_by_official and search_documents.

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?

It provides explicit WHEN and WHEN NOT guidance, names alternatives for one person's speaking history and for ordinance text/packets/PDFs, and explains when to use `since` and `officials_only`. The examples further illustrate correct invocation contexts.

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