Skip to main content
Glama

openstates-mcp-server

by io.github.cyanheads

Search Events

openstates_search_events
Read-onlyIdempotent

Search hearings, floor sessions, and committee meetings. jurisdiction is required — the Open States events endpoint has no all-states search, so scope every call to a single state; use openstates_list_jurisdictions to pick one. Experimental — most states do not publish event data to Open States. Use after and before to scope to a date range. Set require_bills=true to filter to events with bills on the agenda, which is the most useful filter for tracking legislation through committee. Use include=agenda,participants for full meeting context. Empty results often indicate the state lacks event data rather than no events occurring.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoPage number (1-indexed).
afterNoISO 8601 datetime — events starting after this time. Use to find upcoming hearings.
beforeNoISO 8601 datetime — events starting before this time.
includeNoRelated data to inline. "agenda" includes the meeting agenda with bill references. "participants" includes the committee or chamber hosting the event. "links" and "media" add related URLs and recordings, "documents" the attached files, and "sources" the provenance URLs behind the record.
per_pageNoResults per page. Maximum 20.
jurisdictionYesState name, abbreviation, or OCD-ID. Required — the Open States events endpoint has no all-states search, so every call must be scoped to a single jurisdiction.
require_billsNoWhen true, only return events with at least one bill on the agenda. Most useful for tracking legislation through committee.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoCurrent page returned.
errorNoPresent when the call failed. Absent on success.
noticeNoRecovery hint when results are empty. Absent when results are returned.
maxPageNoTotal pages available.
resultsNoEvents matching the search criteria.
paginationNoPagination metadata.
totalCountNoTotal events matching the query across all pages.
coverageNoteNoEvent data is experimental — most states do not publish event data to Open States. Empty results may indicate the state lacks data, not that no events occurred.
appliedFiltersNoFilters applied to this query as the server received them, for agent self-verification of zero or unexpected results.

TDQS

A4.8/5.0
Behavior5/5

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

Annotations declare readOnlyHint, openWorldHint, and idempotentHint, which cover safety and repeatability. The description adds meaningful behavioral context beyond that: the experimental nature, the fact that most states lack event data, and the interpretation of empty results. No contradictions with annotations.

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?

The description is about four sentences and front-loads the core purpose and the mandatory jurisdiction constraint. It is reasonably tight, though some advice (like require_bills and include) is also present in the schema and could be considered slightly redundant, keeping it from a 5.

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?

With an output schema present, the description need not explain return values. It covers the sole required parameter, the experimental caveat, common filters, and empty-result interpretation—everything an agent needs to correctly scope and call the tool. It is fully complete for the tool's complexity.

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 each parameter already has solid descriptions. The description adds extra value by explaining the rationale behind jurisdiction (no all-states search), suggesting after for upcoming hearings, and highlighting require_bills for tracking legislation. This goes just beyond the schema, warranting a 4.

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 clearly states the tool searches hearings, floor sessions, and committee meetings, which is a specific verb and resource. It distinguishes from sibling get_event by focusing on search, and the opening sentence leaves no ambiguity about what the tool does.

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 gives explicit, actionable guidance: jurisdiction is required and why, use openstates_list_jurisdictions to choose one, use after/before for date scoping, require_bills for filtering, and include for context. It also warns about experimental status and how to interpret empty results, which directly informs usage decisions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All openstates-mcp-server toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.6/5.0
Disambiguation5/5

Each tool serves a distinct purpose: get_* fetches a single entity by ID, search_* finds multiple entities via criteria, and list_jurisdictions enumerates all jurisdictions. The location-based people lookup is unique and clearly differentiated from name-based search_people. No two tools have overlapping functionality.

Naming Consistency5/5

All tools follow a consistent pattern: openstates_<action>_<entity>, where actions are either get (singular fetch), search (query-based), or list (enumerate all). The entity names are consistent (bill, committee, event, jurisdiction, people) and the special 'legislators_by_location' still fits the verb_noun structure. No mixed conventions or vague verbs.

Tool Count5/5

10 tools is well within the optimal 3-15 range. The server covers the primary legislative data entities—bills, committees, events, jurisdictions, and people—without redundancy. Each tool earns its place for a comprehensive public policy data API.

Completeness5/5

The surface provides full read capability for the domain: search and detail retrieval for all core entities, jurisdiction metadata listing, and a special location-based people lookup. Given the read-only nature of the data source, there are no obvious gaps—every plausible query scenario is addressed.

Resources