Skip to main content
Glama

What happened at a meeting

get_meeting
Read-onlyIdempotent

One meeting as structured data: headline and summary, agenda items (with video jump links), every decision with its outcome and roll call, public comment (count and unnamed summaries), and the meeting's documents. No transcript.

WHEN: 'What happened at Tuesday's council meeting?', 'What did they decide on item 5.3?', or after any tool returns a meeting_id you want to explain. Also accepts an OpenCity meeting URL the user pasted. WHEN NOT: For the exact words spoken, use get_transcript_window. For decisions across many meetings, use whats_changed.

Decisions follow whats_changed's rules: outcome is at the item's stage ('Recommended approval' is not final), tally counts positions on the ITEM, and is withheld when votes_complete is false. Public commenters are never named.

EXAMPLES: { "meeting": "ad1f24aa-ee04-4ce3-bd71-ab6410429d6d" } { "meeting": "https://lehi.openutah.org/meetings/2026-10-13-city-council-ad1f24aa-ee04-4ce3-bd71-ab6410429d6d" }

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": {
      "meeting": "<meeting>"
    },
    "name": "get_meeting"
  }
}

Input Schema

NameRequiredDescriptionDefault
meetingYesA meeting_id (UUID) from another tool, or an OpenCity meeting URL (https://lehi.openutah.org/meetings/…).

Output Schema

NameRequiredDescriptionDefault
meetingYes
redactedYesTrue when member votes were withheld because the plan does not identify officials. Tallies and outcomes are complete either way.
decisionsYes
documentsYes
agenda_itemsYes
public_commentYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / properties / decisions / items / properties / votes_complete / description
      Previous value: -"False when the named votes do not account for the stated count, or a member was called but not heard: then `votes` lists only those named, and the tally is withheld."New value: +"False when the named votes do not account for the stated count, a member was called but not heard, or no count was stated and fewer than 3 votes are named: then `votes` lists only those named, and the tally is withheld."
  2. Added

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the readOnly/idempotent annotations, the description discloses substantive semantic caveats an agent could not guess: outcome is reported at the item's stage rather than final, tally counts positions on the item and is withheld when votes_complete is false, and public commenters are never named. It also states the transcript is intentionally excluded, preventing a wrong-tool expectation.

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: content inventory first, then WHEN/WHEN NOT routing, then interpretive rules, then examples. The decisions-rules paragraph is longer than strictly necessary but each clause affects how an agent reads the output, so it earns most of its space.

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-shape explanation is not required, and annotations cover the safety profile. Given a single required parameter, the description supplies everything else an agent needs: routing, value formats, and the interpretive caveats that determine whether the returned decisions are final.

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 already 100%, so the baseline is 3; the description adds value by showing concrete accepted value shapes in the EXAMPLES block (bare UUID vs. a full OpenCity meeting URL) and by stating where a meeting_id originates. It stops short of describing validation limits such as the minLength/maxLength bounds, but the shape guidance is 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?

Names a specific verb+resource (retrieve one meeting as structured data) and enumerates exactly what the payload contains: headline/summary, agenda items with jump links, decisions with outcome and roll call, public comment, documents. It also draws the boundary explicitly with 'No transcript', which separates it from get_transcript_window.

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 WHEN block gives concrete trigger phrasings and a chaining rule ('after any tool returns a meeting_id'), and the WHEN NOT block names both alternatives by name with the condition that selects each (get_transcript_window for verbatim speech, whats_changed for cross-meeting decisions). 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