OpenCityRecord

Search meeting documents

search_documents

Read-onlyIdempotent

What the city put in writing — agendas, minutes, staff reports, meeting packets, attachments, ordinances, and resolutions. Keyword search across extracted document text. Use this when the value is in the written record, not the spoken transcript.

WHEN: Looking for ordinance language, budget tables, agenda text, staff reports, attached PDFs. WHEN NOT: For what was said in the meeting, use search_meetings. For metadata-only queries ('what meetings happened last week?'), search_meetings with q on a placeholder works better.

EXAMPLES: { "q": "ADU ordinance", "cities": ["lehi-ut"] } { "q": "FY2027 budget", "cities": ["lehi-ut"] } { "q": "developer presentation Main Street" }

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

Input Schema

TableJSON Schema

Name	Required	Description
`q`	Yes	Free-text query matched against extracted text from agendas, minutes, packets, and attachments.
`limit`	No	Max 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.
`cities`	No	City-slug allow-list. Strongly recommended — searches every accessible city otherwise.
`doc_types`	No	Filter by doc_type values, e.g. ['agenda', 'minutes', 'packet', 'attachment'].

Output Schema

TableJSON Schema

Name	Required	Description
`hits`	Yes	Document matches, newest first.
`total`	Yes	Rough upper bound on candidate documents, NOT a count containing your full query — matching relaxes trailing words to keep recall up. Never report this as 'N mentions'; count `hits` instead.
`citiesQueried`	Yes	Number of cities actually searched.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 14, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already cover readOnly/idempotent/openWorld, but the description adds real behavioral context: the meaning of an empty `hits: []` (no text match, not missing access), the retry guidance, and the note that `limit` results are spread across cities and meetings. It stops short of documenting result shape or any auth/rate constraints.

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?

Front-loaded and scannable with labeled WHEN / WHEN NOT / EXAMPLES sections, and every block earns its place. The opening clause is stylistic rather than the operational verb, which pushes the actual function into the second sentence.

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?

Output schema exists so return values need not be spelled out, yet the description still explains the empty-result case that an agent would otherwise misreport. With 4 well-documented parameters and full sibling routing, nothing needed to call it correctly is missing.

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 goes beyond it with three worked examples that demonstrate realistic `q` + `cities` combinations and the newline `q` placeholder pattern for the sibling tool. It does not add format or enum detail the schema lacks, but the examples are genuinely additive.

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+resource (keyword search across extracted document text) and enumerates the covered artifact types (agendas, minutes, staff reports, packets, attachments, ordinances, resolutions). It explicitly distinguishes itself from the sibling search_meetings by contrasting the written record with the spoken transcript.

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?

Provides explicit WHEN and WHEN NOT blocks naming the alternative tool (search_meetings) and the conditions that select it, including the metadata-only case with the `q` placeholder trick. Nothing about tool selection 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.

All OpenCityRecord tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?