opengov-mcp-server
The OpenGov MCP Server enables access to Socrata-powered government data portals, allowing users to search, retrieve, and analyze public datasets.
Search and Discover Datasets: Search datasets by keyword, category, or tags using the
catalog,categories, andtagsoperations.Access Dataset Metadata: Retrieve detailed metadata and column information for specific datasets.
Query and Analyze Data: Run SQL-like queries to filter, sort, and retrieve data records using parameters like
soqlQuery,select,where, andorder.Pagination and Limits: Control the number of results with
limitandoffset.Aggregate Functions: Group and filter data with
groupandhavingfor aggregate queries.Portal Statistics: Get portal-wide usage statistics with
site-metrics.Custom Domain Support: Specify a data portal domain for flexibility across different Socrata portals.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@opengov-mcp-servershow me recent building permits in Chicago"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
OpenGov MCP Server
An MCP (Model Context Protocol) server that enables MCP clients like Claude Desktop to access Socrata Open Data APIs. This integration allows Claude Desktop to search for, retrieve, and analyze public datasets from government data portals.
Overview
This MCP server provides access to open data from any Socrata-powered data portal, including those from cities, states, and federal agencies such as:
No API key is required for basic usage, as the server accesses public data.
Related MCP server: json-mcp-server
Features
With this MCP server, clients can:
Search and discover datasets by keyword, category, or tags
View dataset metadata and column information
Run SQL-like queries to retrieve and analyze data
Get portal usage statistics
Installation for Claude Desktop
Quick Setup with npx (Recommended)
The easiest way to use this MCP server is with npx, which doesn't require any installation:
Create or edit your Claude Desktop configuration:
Create or edit
claude_desktop_config.jsonin your home directory:{ "mcpServers": { "opengov": { "command": "npx", "args": ["-y", "opengov-mcp-server@latest"], "env": { "DATA_PORTAL_URL": "https://data.cityofchicago.org" } } } }You can replace the DATA_PORTAL_URL with any Socrata-powered data portal.
Restart Claude Desktop (if it was already running)
Start using the MCP server:
In Claude Desktop, you can now ask questions like:
How many cars were towed in Chicago this month?and you can follow up with questions that drill further into detail:
Which make and color were towed the most? Also, were there any interesting vanity plates?The first time you run a query, npx will automatically download and run the latest version of the server.
Manual Installation from Source
If you prefer to run from source (for development or customization):
Clone this repository:
git clone https://github.com/srobbin/opengov-mcp-server.git cd opengov-mcp-serverInstall dependencies and build:
npm install npm run buildCreate Claude Desktop configuration:
Create or edit
claude_desktop_config.jsonin your home directory:{ "mcpServers": { "opengov": { "command": "node", "args": [ "/path/to/your/opengov-mcp-server/dist/index.js" ], "env": { "DATA_PORTAL_URL": "https://data.cityofchicago.org" } } } }Replace
/path/to/your/opengov-mcp-serverwith the actual path where you cloned the repository.Restart Claude Desktop (if it was already running)
Available Tool: get_data
This MCP server provides a unified get_data tool that Claude Desktop uses to access Socrata data.
Parameters
type(string, required): Operation typecatalog: Search and list datasetscategories: List dataset categoriestags: List dataset tagsdataset-metadata: Get dataset detailscolumn-info: Get dataset column informationdata-access: Query and retrieve recordssite-metrics: Get portal statistics
domain(string, optional): Data portal hostname (without protocol)query(string, optional): Search query for datasetsdatasetId(string): Dataset identifier for specific operationssoqlQuery(string, optional): SoQL query for filtering datalimit(number, optional): Maximum results to return (default: 10)offset(number, optional): Results to skip for pagination (default: 0)
Example Queries
These are examples of how Claude Desktop will format queries to the MCP server:
// Find datasets about budgets
{
"type": "catalog",
"query": "budget",
"limit": 5
}
// Get information about a dataset
{
"type": "dataset-metadata",
"datasetId": "6zsd-86xi"
}
// Query dataset records with SQL-like syntax
{
"type": "data-access",
"datasetId": "6zsd-86xi",
"soqlQuery": "SELECT * WHERE amount > 1000 ORDER BY date DESC",
"limit": 10
}Configuration Options
The server requires one environment variable:
DATA_PORTAL_URL: The Socrata data portal URL (e.g.,https://data.cityofchicago.org)
This can be set:
In the Claude Desktop configuration (recommended)
In your environment variables
Via command line:
DATA_PORTAL_URL=https://data.cityofchicago.org opengov-mcp-server
Available Tools
1 toolget_dataC
[City of Chicago | Data Portal] Access data and metadata to learn more about the city and its underlying information.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | The type of operation to perform: - catalog: List datasets with optional search - categories: List all dataset categories - tags: List all dataset tags - dataset-metadata: Get detailed metadata for a specific dataset - column-info: Get column details for a specific dataset - data-access: Access records from a dataset (with query support) - site-metrics: Get portal-wide statistics | |
| domain | No | Optional domain (hostname only, without protocol). Used with all operation types. | |
| query | No | Search or query string with different uses depending on operation type: - For type=catalog: Search query to filter datasets - For type=data-access: SoQL query string for complex data filtering | |
| datasetId | No | Dataset identifier required for the following operations: - For type=dataset-metadata: Get dataset details - For type=column-info: Get column information - For type=data-access: Specify which dataset to query (e.g., 6zsd-86xi) | |
| soqlQuery | No | For type=data-access only. Optional SoQL query string for filtering data. This is an alias for the query parameter and takes precedence if both are provided. | |
| select | No | For type=data-access only. Specifies which columns to return in the result set. | |
| where | No | For type=data-access only. Filters the rows to be returned (e.g., "magnitude > 3.0"). | |
| order | No | For type=data-access only. Orders the results based on specified columns (e.g., "date DESC"). | |
| group | No | For type=data-access only. Groups results for aggregate functions. | |
| having | No | For type=data-access only. Filters for grouped results, similar to where but for grouped data. | |
| q | No | For type=data-access only. Full text search parameter for free-text searching across the dataset. | |
| limit | No | Maximum number of results to return: - For type=catalog: Limits dataset results - For type=data-access: Limits data records returned | |
| offset | No | Number of results to skip for pagination: - For type=catalog: Skips dataset results - For type=data-access: Skips data records for pagination |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description should disclose behavioral traits. It fails to mention that the tool supports multiple operation types, is read-only (implied but not stated), or any other behavioral aspects beyond a generic 'access data and metadata'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single vague sentence. While it is concise, it is under-specified and does not effectively convey the tool's capabilities.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (13 parameters, multiple operation types, no output schema), the description is extremely incomplete. It does not explain the different operations, query syntax, or return values, leaving the agent with almost no useful context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds no parameter context beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description is vague: 'Access data and metadata to learn more about the city and its underlying information.' It does not specify the specific actions or resources available, despite the schema supporting many operations like 'catalog', 'data-access', etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, nor any context on when not to use it. The description provides no usage context despite the diverse operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
1 tool update
v1.0.0- First observed
get_data
TDQS
With only one tool, there is no possibility of confusion between tools, so disambiguation is perfect.
The single tool name 'get_data' follows a clear verb_noun pattern, and consistency is trivially maintained.
Only one tool is far below the typical 3-15 range for a well-scoped server, and the broad purpose of accessing open government data likely requires multiple tools.
The single generic 'get_data' tool cannot cover the expected operations for a government data portal, such as searching datasets, filtering, or accessing specific data types.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
MCP server for prozorro_tender_monitor_mcp
MCP server for medicare-coverage
MCP server for public_holidays_mcp
Related MCP Servers
- Apache 2.0
- MIT
- Apache 2.0
- MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/srobbin/opengov-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server