Skip to main content
Glama

openstates-mcp-server

by io.github.cyanheads

Get Jurisdiction

openstates_get_jurisdiction
Read-onlyIdempotent

Fetch full metadata for a specific jurisdiction including all legislative sessions, their identifiers, and coverage dates. Use when you need to know the exact session identifier for a state before filtering bill searches — session formats vary widely (e.g., "2025", "2025rs", "2025s1"). Jurisdiction IDs follow OCD format: ocd-jurisdiction/country:us/state:{abbr}/government (e.g., ocd-jurisdiction/country:us/state:wa/government). State names (e.g., "Washington") and two-letter abbreviations (e.g., "wa") are also accepted.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
includeNoRelated data to inline. "legislative_sessions" returns all historical and current sessions with identifiers and date ranges. "organizations" lists the jurisdiction's legislative chambers and executive bodies. "latest_runs" shows last scraper run metadata.
jurisdiction_idYesOCD jurisdiction ID, state name (e.g., "Washington"), or two-letter abbreviation (e.g., "wa").

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoOCD jurisdiction ID.
urlNoOfficial legislature URL.
nameNoJurisdiction name.
errorNoPresent when the call failed. Absent on success.
latest_runsNoRecent scraper runs when include=latest_runs is requested.
organizationsNoLegislative chambers and executive bodies when include=organizations is requested.
classificationNoJurisdiction type.
latest_bill_updateNoISO 8601 timestamp of most recent bill data update.
latest_people_updateNoISO 8601 timestamp of most recent people data update.
legislative_sessionsNoAll legislative sessions when include=legislative_sessions is requested.

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds value by describing the returned metadata (sessions, identifiers, coverage dates) and accepted ID formats, which goes beyond the annotations. There is no contradiction with the read-only and idempotent hints.

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 three sentences with no filler. It is front-loaded with the action and purpose, then gives the use case and ID formats. Every sentence contributes essential information, making it concise and well-structured.

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 the presence of an output schema and annotations that cover safety, the description provides everything an agent needs: the purpose, the trigger condition, the parameter formats, and what data to expect. No critical information is missing for correct invocation.

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% and both parameters are well documented in the schema. The description reinforces the jurisdiction_id formats but adds little beyond that. It implies sessions are always included, whereas the 'include' parameter makes them optional, which is slightly ambiguous. Thus the description provides only marginal added value over the schema.

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 action ('fetch full metadata'), a clear resource ('a specific jurisdiction'), and the key content returned (legislative sessions, identifiers, coverage dates). It also gives a concrete use case (getting session identifiers for bill searches) and names the exact OCD format, which distinguishes it from sibling tools like list_jurisdictions or search_bills.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It clearly instructs when to use this tool: 'Use when you need to know the exact session identifier for a state before filtering bill searches.' This is a strong contextual trigger. However, it does not explicitly mention alternatives or when not to use it, so it falls short of the full 'when-not/alternatives' criterion.

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