Skip to main content
Glama
deenesjakoruzh
srobbin

opengov-mcp-server

by srobbin
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

OpenGov MCP 서버

Claude Desktop과 같은 MCP 클라이언트가 Socrata Open Data API에 접근할 수 있도록 하는 MCP(Model Context Protocol) 서버입니다. 이 통합을 통해 Claude Desktop은 정부 데이터 포털에서 공개 데이터 세트를 검색, 조회 및 분석할 수 있습니다.

개요

이 MCP 서버는 다음과 같은 도시, 주, 연방 기관을 포함한 모든 Socrata 기반 데이터 포털의 오픈 데이터에 대한 액세스를 제공합니다.

서버가 공개 데이터에 접근하므로 기본 사용에는 API 키가 필요하지 않습니다.

Related MCP server: json-mcp-server

특징

이 MCP 서버를 사용하면 클라이언트는 다음을 수행할 수 있습니다.

  • 키워드, 카테고리 또는 태그로 데이터 세트를 검색하고 발견하세요

  • 데이터 세트 메타데이터 및 열 정보 보기

  • SQL과 유사한 쿼리를 실행하여 데이터를 검색하고 분석합니다.

  • 포털 사용 통계 가져오기

Claude Desktop 설치

npx를 사용한 빠른 설정(권장)

이 MCP 서버를 사용하는 가장 쉬운 방법은 npx를 사용하는 것입니다. npx는 설치가 필요하지 않습니다.

  1. Claude Desktop 구성을 생성하거나 편집하세요 .

    홈 디렉토리에서 claude_desktop_config.json 만들거나 편집하세요.

    지엑스피1

    DATA_PORTAL_URL을 Socrata 기반 데이터 포털로 바꿀 수 있습니다.

  2. Claude Desktop을 다시 시작합니다 (이미 실행 중이었다면)

  3. MCP 서버 사용 시작 :

    Claude Desktop에서는 이제 다음과 같은 질문을 할 수 있습니다.

    How many cars were towed in Chicago this month?

    그리고 더 자세한 내용을 묻는 질문을 할 수 있습니다.

    Which make and color were towed the most?
Also, were there any interesting vanity plates?

    처음으로 쿼리를 실행하면 npx가 자동으로 서버의 최신 버전을 다운로드하여 실행합니다.

소스에서 수동 설치

개발이나 사용자 정의를 위해 소스에서 실행하려는 경우:

  1. 이 저장소를 복제합니다 .

    git clone https://github.com/srobbin/opengov-mcp-server.git
cd opengov-mcp-server

  2. 종속성을 설치하고 빌드합니다 .

    npm install
npm run build

  3. Claude Desktop 구성 만들기 :

    홈 디렉토리에서 claude_desktop_config.json 만들거나 편집하세요.

    {
  "mcpServers": { 
    "opengov": {
      "command": "node",
      "args": [
        "/path/to/your/opengov-mcp-server/dist/index.js"
      ],
      "env": {
        "DATA_PORTAL_URL": "https://data.cityofchicago.org"
      }
    }
  }
}

    /path/to/your/opengov-mcp-server 저장소를 복제한 실제 경로로 바꾸세요.

  4. Claude Desktop을 다시 시작합니다 (이미 실행 중이었다면)

사용 가능한 도구: get_data

이 MCP 서버는 Claude Desktop이 Socrata 데이터에 액세스하는 데 사용하는 통합된 get_data 도구를 제공합니다.

매개변수

  • type (문자열, 필수): 작업 유형

    • catalog : 데이터세트 검색 및 나열

    • categories : 데이터 세트 카테고리 목록

    • tags : 데이터 세트 태그 목록

    • dataset-metadata : 데이터셋 세부 정보 가져오기

    • column-info : 데이터 세트 열 정보 가져오기

    • data-access : 레코드 쿼리 및 검색

    • site-metrics : 포털 통계 가져오기

  • domain (문자열, 선택 사항): 데이터 포털 호스트 이름(프로토콜 없음)

  • query (문자열, 선택 사항): 데이터 세트에 대한 검색 쿼리

  • datasetId (문자열): 특정 작업에 대한 데이터 세트 식별자

  • soqlQuery (문자열, 선택 사항): 데이터 필터링을 위한 SoQL 쿼리

  • limit (숫자, 선택 사항): 반환할 최대 결과 수(기본값: 10)

  • offset (숫자, 선택 사항): 페이지 매김을 위해 건너뛸 결과(기본값: 0)

예제 쿼리

다음은 Claude Desktop이 MCP 서버에 대한 쿼리를 포맷하는 방법의 예입니다.

// 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
}

구성 옵션

서버에는 하나의 환경 변수가 필요합니다.

  • DATA_PORTAL_URL : Socrata 데이터 포털 URL(예: https://data.cityofchicago.org )

다음과 같이 설정할 수 있습니다.

  • Claude Desktop 구성(권장)

  • 환경 변수에서

  • 명령줄을 통해: DATA_PORTAL_URL=https://data.cityofchicago.org opengov-mcp-server

Available Tools

1 tool
get_dataC

[City of Chicago | Data Portal] Access data and metadata to learn more about the city and its underlying information.

ParametersJSON Schema
NameRequiredDescriptionDefault
typeYesThe 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
domainNoOptional domain (hostname only, without protocol). Used with all operation types.
queryNoSearch 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
datasetIdNoDataset 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)
soqlQueryNoFor 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.
selectNoFor type=data-access only. Specifies which columns to return in the result set.
whereNoFor type=data-access only. Filters the rows to be returned (e.g., "magnitude > 3.0").
orderNoFor type=data-access only. Orders the results based on specified columns (e.g., "date DESC").
groupNoFor type=data-access only. Groups results for aggregate functions.
havingNoFor type=data-access only. Filters for grouped results, similar to where but for grouped data.
qNoFor type=data-access only. Full text search parameter for free-text searching across the dataset.
limitNoMaximum number of results to return: - For type=catalog: Limits dataset results - For type=data-access: Limits data records returned
offsetNoNumber of results to skip for pagination: - For type=catalog: Skips dataset results - For type=data-access: Skips data records for pagination

TDQS

C2.1/5.0
Behavior2/5

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.

Conciseness2/5

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.

Completeness1/5

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.

Parameters3/5

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.

Purpose2/5

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.

Usage Guidelines2/5

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.

  1. 1 tool updatev1.0.0
    • First observedget_data
Deploy Server
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

TDQS

C2.4/5.0

Scored across 1 tool

Disambiguation5/5

With only one tool, there is no possibility of confusion between tools, so disambiguation is perfect.

Naming Consistency5/5

The single tool name 'get_data' follows a clear verb_noun pattern, and consistency is trivially maintained.

Tool Count1/5

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.

Completeness1/5

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

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches