OpenCityRecord

What changed since a date

whats_changed

Read-onlyIdempotent

What the city council actually decided recently — the changeset of council activity in a city since a date: decisions taken (with tallies where a roll call was recorded), issues discussed, development-application status changes, and — on paid plans — per-member votes and stance reversals. Free plans get the aggregated changeset without member attribution (redacted: true). Most decisions are unanimous voice votes with roll_call: false and no tally — they are still decisions; report them.

WHEN: 'What did the council do in the last two weeks?', 'Any movement on development since June?'. WHEN NOT: For one person or one issue over time, use track_position / issue_timeline.

EXAMPLES: { "city": "lehi-ut", "since": "2026-06-21" }

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "city": "<city>",
      "since": "<since>"
    },
    "name": "whats_changed"
  }
}

Input Schema

Name	Required	Description
`city`	Yes	City slug (e.g. 'lehi-ut').
`limit`	No	Max decisions/issues/applications each. Default 50.
`since`	Yes	ISO date (YYYY-MM-DD). Only activity on/after this date is returned.

Output Schema

Name	Required	Description
`period`	Yes
`redacted`	Yes	True when member-level attribution (vote-by-member, named stance flips) was withheld because the plan does not identify officials. Tallies and decision titles are complete either way.
`decisions`	Yes	Decisions taken in the window — approved, denied, tabled or continued — whether or not a roll call was recorded (see `roll_call`). Items only discussed are not decisions and appear under issues_active instead.
`truncated`	Yes	True when the window held more activity than one call reads, so the OLDEST part of it is missing. Narrow `since` and call again rather than reporting the result as complete.
`stance_flips`	Yes	Members who reversed position within the window. Empty when nobody flipped, or when `redacted` is true.
`issues_active`	Yes	Issues discussed in the window.
`meeting_count`	Yes
`applications_active`	Yes	Development applications that came up, with the statuses seen in the window.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 26, 2026

changedOutput schema / properties / decisions / items / properties / votes_complete / description

Previous value: -"For a roll call with a stated count: true when the named votes add up to it, false when they do not. Minutes often name only the dissenters, so a '10-1' vote can arrive with one named member; then `tally` is null and `votes` lists only the members the record named. Null when there is no roll call or no stated count to check against."New value: +"For a roll call with a stated count: true when the named votes add up to it, false when they do not. Minutes often name only the dissenters, so a '10-1' vote can arrive with one named member; then `tally` is null and `votes` lists only the members the record named. Also false, with no stated count, when the record names fewer than 3 votes — no body is that small, so that is a partial list. Null when there is no roll call, or no stated count and at least 3 named votes."

Changed5 schema fields changedOct 26, 2026

changedOutput schema / properties / decisions / items / properties / tally / description

Previous value: -"yes = voted to APPROVE/support the item, no = voted to DENY/oppose it. Not the procedural aye/nay: councils routinely say 'aye' to a motion to deny, and that is counted here as a `no` on the item. Null when `roll_call` is false — see `vote_count`."New value: +"yes = voted to APPROVE/support the item, no = voted to DENY/oppose it. Not the procedural aye/nay: councils routinely say 'aye' to a motion to deny, and that is counted here as a `no` on the item. Null when `roll_call` is false, and null when `votes_complete` is false because the named votes do not account for the stated count — then use `vote_count`, and never read the named votes as the whole vote."

changedOutput schema / properties / decisions / items / properties / vote_count / description

Previous value: -"The count as the record stated it (e.g. '5-0'), for a decision with no roll call. It is the MOTION's aye-nay, not per-item direction, so a '5-0' motion to deny is five votes against the item. Null when not stated, and always null when `roll_call` is true (use `tally`)."New value: +"The count as the record stated it (e.g. '5-0'). It is the MOTION's aye-nay, not per-item direction, so a '5-0' motion to deny is five votes against the item. Null when not stated. When `tally` is present too, they agree."

changedOutput schema / properties / decisions / items / properties / votes / description

Previous value: -"Per-member votes, name and direction. Null when `redacted` is true, or when the source meeting recorded no individual votes."New value: +"Per-member votes, name and direction. Null when `redacted` is true, or when the source meeting recorded no individual votes. Only the members the record named when `votes_complete` is false."

addedOutput schema / properties / decisions / items / properties / votes_complete

Added value: +{
+  "description": "For a roll call with a stated count: true when the named votes add up to it, false when they do not. Minutes often name only the dissenters, so a '10-1' vote can arrive with one named member; then `tally` is null and `votes` lists only the members the record named. Null when there is no roll call or no stated count to check against.",
+  "type": [
+    "boolean",
+    "null"
+  ]
+}

changedOutput schema / properties / decisions / items / required

Previous value: -[
-  "meeting_id",
-  "meeting_date",
-  "decision_title",
-  "outcome",
-  "roll_call",
-  "tally",
-  "vote_count",
-  "votes",
-  "summary",
-  "meeting_type",
-  "meeting_url"
-]New value: +[
+  "meeting_id",
+  "meeting_date",
+  "decision_title",
+  "outcome",
+  "roll_call",
+  "tally",
+  "vote_count",
+  "votes_complete",
+  "votes",
+  "summary",
+  "meeting_type",
+  "meeting_url"
+]

First observedOct 14, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the readOnly/idempotent/non-destructive annotations, it discloses plan-tier gating (paid plans get per-member votes and stance reversals, free plans return `redacted: true`), and warns that unanimous voice votes with `roll_call: false` and no tally are still decisions that should be reported — a real output-interpretation gotcha.

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 and sectioned with WHEN / WHEN NOT / EXAMPLES, and every block earns its place. The opening sentence is long and em-dash-dense, which costs a bit of parseability.

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?

For a three-parameter read tool with an output schema (so return shape needn't be described), the description covers scope, plan-tier behavior, interpretation caveats, and routing. Nothing an agent needs before calling is missing.

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

Parameters3/5

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

Schema description coverage is 100%, so city, since, and limit are all documented in the schema already. The description's example reinforces the slug and ISO date format but adds no syntax or semantics the schema lacks, so it sits at the baseline.

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 precise aggregate resource — 'the changeset of council activity in a city since a date' — and enumerates its contents (decisions with tallies, issues discussed, development-application status changes, per-member votes). It explicitly distinguishes itself from the sibling tools track_position and issue_timeline.

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 examples ('What did the council do in the last two weeks?') and an explicit WHEN NOT that names both alternatives (track_position, issue_timeline) with the condition that selects them. 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.

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?