Skip to main content
Glama
Sign In

OpenCityRecord

by org.opencityrecord
OverviewDiscussionsAdmin

Development application timeline

application_timeline
Read-onlyIdempotent

How a development project moved through the city — a rezone, subdivision, site plan, conditional-use permit, or apartment/commercial build. Returns the application's lifecycle across meetings (pending → under-review → hearing → approved/denied), oldest first, with the status recorded at each step.

WHEN: 'What's the status of the Silo Park development?', 'How did rezone X move through the council?'. WHEN NOT: For issues/policy (not a specific project) use issue_timeline; for quotes use search_meetings.

Pass city whenever you pass q. A project or retailer name often matches applications in several cities, and without a city you will get application: null plus a candidates list to choose from rather than an answer about the wrong city. Check candidates even on a resolved application: one name can cover more than one project in the same city.

EXAMPLES: { "q": "Silo Park", "city": "lehi-ut" } — ALWAYS pass city with q { "application_id": "" }

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "application_timeline"
  }
}

Input Schema

NameRequiredDescriptionDefault
qNoResolve by a project-name / address / slug substring when you don't have the id (e.g. 'Silo Park'). Ignored if application_id is set.
cityNoCity slug to scope resolution (e.g. 'lehi-ut'). Pass it with q: without it, a name that matches projects in more than one city returns `candidates` instead of a timeline.
limitNoMax timeline entries. Default 100.
application_idNoUUID of the development application. Preferred when known.

Output Schema

NameRequiredDescriptionDefault
timelineYesEvery meeting where the application came up, oldest first — read status_at_mention down the list to see the lifecycle.
candidatesYesOther applications matching `q`, most important first. Populated (with application null) when the match was ambiguous ACROSS cities — pick one rather than assuming. Also lists same-city alternates alongside a resolved application ('Costco' can be both a warehouse subdivision and a fuel-center expansion).
applicationYesThe resolved application. Null when nothing matched, OR when `q` matched applications in more than one city and no `city` was given — check `candidates` in that case and re-call with a city or an application_id.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / city / description
      Previous value: -"City slug to scope resolution (e.g. 'lehi-ut'). Required with q when you have access to more than one city."New value: +"City slug to scope resolution (e.g. 'lehi-ut'). Pass it with q: without it, a name that matches projects in more than one city returns `candidates` instead of a timeline."
    • changedOutput schema / properties / application / description
      Previous value: -"The resolved application, or null when nothing matched the query/scope."New value: +"The resolved application. Null when nothing matched, OR when `q` matched applications in more than one city and no `city` was given — check `candidates` in that case and re-call with a city or an application_id."
    • addedOutput schema / properties / candidates
      Added value: +{
+  "default": [],
+  "description": "Other applications matching `q`, most important first. Populated (with application null) when the match was ambiguous ACROSS cities — pick one rather than assuming. Also lists same-city alternates alongside a resolved application ('Costco' can be both a warehouse subdivision and a fuel-center expansion).",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "address": {
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "application_id": {
+        "type": "string"
+      },
+      "city_slug": {
+        "type": "string"
+      },
+      "first_discussed_date": {
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "last_discussed_date": {
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "project_name": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "application_id",
+      "city_slug",
+      "project_name",
+      "address",
+      "first_discussed_date",
+      "last_discussed_date"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}
    • changedOutput schema / required
      Previous value: -[
-  "application",
-  "timeline"
-]New value: +[
+  "application",
+  "candidates",
+  "timeline"
+]
  2. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already establish read-only, idempotent, non-destructive behavior, but the description adds important resolution behavior: without a city, a name may return application: null plus candidates, and candidates should be checked even when an application resolves. It also discloses return ordering and status progression, which goes beyond the 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 description is front-loaded, organized into purpose, WHEN, WHEN NOT, and examples, and every section contributes useful selection or invocation guidance. Minor repetition of the city-with-q rule is justified because it prevents a common resolution failure.

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 four optional parameters, full schema description coverage, an output schema, and rich annotations, the description covers purpose, alternatives, resolution behavior, and invocation guidance. Nothing important for selecting or calling the tool appears to be 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 parameter meanings are already mostly documented. The description still adds operational meaning by emphasizing that city should always accompany q and by explaining candidate-list behavior, though it does not add much about limit or application_id beyond what the schema already says.

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 states a specific resource and action: it returns a development application's lifecycle across meetings, with concrete examples like rezone, subdivision, site plan, and conditional-use permit. It also explicitly distinguishes this from issue_timeline and search_meetings, so an agent can identify when this tool is the right choice.

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?

The description provides explicit WHEN and WHEN NOT guidance, names alternative tools for issues/policy and quotes, and gives concrete example queries. It also instructs the agent to pass city with q and to check candidates, which are practical usage rules not 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 toolsInspect
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