访问 https://nodejs.org
下载适用于你操作系统的 LTS（长期支持）版本。
运行安装程序，接受默认设置。
打开终端（Windows 上用 PowerShell，Mac/Linux 上用 Terminal）运行以下命令确认安装成功：
```
node -v
npm -v
```
两者都应打印出版本号（例如 v20.11.0）。如果看到错误，请重启终端/电脑后重试。

第 2 步 — 下载本项目

选项 A：使用 Git（如果你有 Git，推荐此方式）

git clone https://github.com/MSPFE2019/occ-gis-mcp.git
cd occ-gis-mcp

选项 B：不使用 Git

访问 https://github.com/MSPFE2019/occ-gis-mcp
点击绿色 Code 按钮 → Download ZIP
解压到你记得住的位置（例如你的"文档"文件夹）
打开终端，cd 进入解压后的文件夹，例如：
```
cd "C:\Users\YourName\Documents\occ-gis-mcp"
```

第 3 步 — 安装依赖

在项目文件夹内运行：

npm install

这会下载服务器所需的小型库。只需执行一次（之后每当代码更新时再执行一次）。

第 4 步 — 测试运行

有两种方式运行此服务器——根据你的使用场景选择：

index.js — 用于本地桌面工具（Claude Desktop、VS Code/Copilot Chat）。
http.js — 用于远程/云端工具，如 Copilot Studio（参见下面的专门章节）。

先试试本地版本：

node index.js

不会打印任何内容——这是正常的！MCP 服务器通过静默的输入/输出通道通信，只是等待客户端连接。按 Ctrl+C 停止。

如需更直观的测试，请使用官方 MCP Inspector，它会在浏览器中打开一个页面，你可以在其中点击按钮并查看实时结果：

npx @modelcontextprotocol/inspector node index.js

这会打开一个本地网页。点击 Connect，然后点击 List Tools，再尝试不带参数运行 list_datasets——你应该会看到以 JSON 形式返回的真实数据集列表。如果成功，说明服务器工作正常。

第 5 步 — 连接到你的 AI 助手

MCP 服务器需要在你的 AI 客户端设置中配置一次。选择与你使用的工具匹配的指南：

Claude Desktop

打开 Claude Desktop → 设置 → 开发者 → 编辑配置（这会在文本编辑器中打开 claude_desktop_config.json）。

添加如下条目（将路径替换为你的实际项目文件夹，Windows 上使用双反斜杠 \\）：

{
  "mcpServers": {
    "occ-gis": {
      "command": "node",
      "args": ["C:\\Users\\YourName\\Documents\\occ-gis-mcp\\index.js"]
    }
  }
}

保存文件并完全重启 Claude Desktop。
询问："OCC GIS 有哪些可用数据集？"

VS Code（GitHub Copilot Chat）或其他支持 MCP 的编辑器

在 MCP 设置中打开（或创建）mcp.json 文件（在 VS Code 中：命令面板 → "MCP: Open User Configuration"，或将其添加到工作区的 .vscode/mcp.json）。
添加上面所示的相同 mcpServers 配置块。
重新加载窗口，与 Copilot 聊天时新工具就会出现。

任何其他 MCP 客户端

任何支持 MCP 标准的客户端都接受相同格式的配置：一个 command（node）和 args（index.js 的完整路径）。请查阅你的客户端文档，了解配置文件的位置。

可用工具

连接后，你的助手可以调用以下工具：

工具	功能
`list_datasets`	搜索/列出数据中心的数据集（油井、储罐等）。可选自由文本 `query` 参数。
`get_dataset`	按标题获取单个数据集的完整详情，包括下载链接（CSV、GeoJSON、Shapefile、KML、文件地理数据库）及其实时 ArcGIS 服务 URL。
`get_layer_metadata`	获取指定 ArcGIS 图层的字段名、几何类型和范围。
`query_layer`	对图层执行属性（`where`）和/或空间查询，返回匹配的记录。

自定义为其他 ArcGIS Hub 站点

本服务器不限于 OCC 的数据——它适用于任何提供 DCAT-US 目录源的 ArcGIS Hub 站点（大多数公共 ArcGIS Hub 站点都提供）。要指向其他站点，请打开 server.js，修改靠近顶部的那一行：

const HUB_BASE = "https://gisdata-occokc.opendata.arcgis.com";

改为目标站点的基本 URL，然后重新运行服务器。其他一切（工具名称、查询逻辑）都照常工作。

连接到 Microsoft Copilot Studio

Copilot Studio 不会为你运行此服务器——它需要通过互联网以 HTTPS URL 的方式访问。这就是 http.js 的用途（与 index.js 不同，后者仅用于 Claude Desktop 等本地工具）。分为两部分：(A) 将服务器部署到互联网上可访问的位置，然后 (B) 在 Copilot Studio 中注册。

A. 将 HTTP 服务器部署到公共位置

选择对你来说最方便的方式——它们都运行相同的命令：npm install，然后 npm run start:http。

初学者最易上手——Azure App Service（或 Azure Container Apps）

将此仓库推送到你自己的 GitHub 账户（如果你正在从自己的 fork/副本阅读本文，则已完成）。
在 Azure 门户中，创建 Web App → 运行时堆栈：Node 20 LTS → 从你的 GitHub 仓库部署（Azure 会为你设置 CI/CD）。
在 配置 → 启动命令 中，设置：
```
node http.js
```
部署完成后，Azure 会给你一个类似 https://occ-gis-mcp.azurewebsites.net 的 URL。你的 MCP 端点就是该 URL 加上 /mcp，例如 https://occ-gis-mcp.azurewebsites.net/mcp。

同样简单——Render、Railway 或 Fly.io 这些平台都可以在几次点击内从 GitHub 部署 Node.js 仓库：

构建命令：npm install
启动命令：npm run start:http
它们会给你一个公共的 https://... URL——同样，在后面加上 /mcp。

仅限本地测试（不用于生产环境）

npm install
npm run start:http

这会在 http://localhost:3000/mcp 启动服务器。要测试 Copilot Studio（云服务）能否访问你自己机器上的服务器，你需要 ngrok 之类的隧道工具（ngrok http 3000），它会给你一个临时的公共 HTTPS URL。这适合快速演示，不适合真实/长期使用。

B. 在 Copilot Studio 中注册

在 Copilot Studio 中打开你的代理 → 转到工具（或操作）→ 添加工具 → 新建工具 → 模型上下文协议。
给它起个名字（例如 "OCC GIS Data"），然后粘贴你的服务器 HTTPS URL，包括 /mcp，例如 https://occ-gis-mcp.azurewebsites.net/mcp。
选择 无身份验证（此服务器是只读的，不需要凭据），除非你已在前面添加了自己的认证层。
保存。Copilot Studio 会调用服务器并自动发现这四个工具（list_datasets、get_dataset、get_layer_metadata、query_layer）及其描述——无需手动输入模式。
在 Copilot Studio 的测试聊天面板中测试：询问"OCC GIS 有哪些可用数据集？"或"查找俄克拉荷马县的活跃油井。"

可用工具

连接后，你的助手可以调用以下工具：

工具	功能
`list_datasets`	搜索/列出数据中心的数据集（油井、储罐等）。可选自由文本 `query` 参数。
`get_dataset`	按标题获取单个数据集的完整详情，包括下载链接（CSV、GeoJSON、Shapefile、KML、文件地理数据库）及其实时 ArcGIS 服务 URL。
`get_layer_metadata`	获取指定 ArcGIS 图层的字段名、几何类型和范围。
`query_layer`	对图层执行属性（`where`）和/或空间查询，返回匹配的记录。

故障排除

node: command not found — Node.js 未安装，或安装后终端需要重启。重新执行第 1 步。
Inspector/工具调用报错提到网络/fetch — 检查你的网络连接；服务器每次请求都会调用实时 ArcGIS Hub API。
助手看不到新工具 — 仔细检查文件路径（本地）或 URL（Copilot Studio）是否正确，以及你是否完全重启/重新连接了客户端。
Copilot Studio 提示无法连接 — 确保你注册的 URL 以 /mcp 结尾（而不仅仅是裸域名），部署确实在运行中，并且可以通过普通 HTTPS 访问（没有被 VPN/防火墙拦截）。

备注

数据集列表是从数据中心的 DCAT-US 目录源实时拉取的，并缓存 15 分钟以保持速度。
数据是公开的，但受来源机构使用条款的约束（显示在 get_dataset 输出的许可证字段中）。
http.js 以无状态模式运行（每个请求一个全新服务器），这简化了托管，并且与 Copilot Studio 调用 MCP 工具的方式完全兼容。

Available Tools

4 tools

get_datasetGet OCC GIS dataset detailsA

Get full details for one dataset on the OCC GIS hub by exact or partial title match, including every distribution (ArcGIS REST service URL, CSV/GeoJSON/Shapefile/KML/FileGDB download links), spatial extent, and license text.

ParametersJSON Schema

Name	Required	Description	Default
`title`	Yes	Dataset title or a distinctive substring of it, e.g. 'RBDMS WELLS' or 'PST Tanks'

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description carries the burden. It does disclose the returned content and the exact/partial matching behavior, which is useful. However, it does not mention how ambiguous partial matches are handled (e.g., multiple matches, error vs. arbitrary selection), nor any potential side effects or permissions, leaving some behavioral gaps.

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 a single, front-loaded sentence that states the action, scope, and key return details without redundancy or filler. Every clause contributes useful information, and it is easily scannable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity (one parameter, no output schema), the description is reasonably complete: it covers purpose, matching behavior, and enumerates the returned information. The only notable omission is clarifying behavior when a partial title matches multiple datasets, but this does not severely undermine usability.

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?

The input schema already fully describes the 'title' parameter with examples and the note about distinctive substrings. The tool description adds 'exact or partial title match', but this largely restates the schema's own description. Schema coverage is 100%, so the baseline of 3 is appropriate.

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 uses a specific verb+resource structure ('Get full details for one dataset on the OCC GIS hub') and clearly enumerates the return contents (distributions, spatial extent, license text). It distinguishes this from sibling tools by focusing on a single dataset found by title, contrasting with list_datasets.

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?

The description provides clear context for when to use the tool: when you need full details of one dataset found by exact or partial title match. It does not explicitly name alternatives or state when not to use it, but the context is unambiguous and implies a targeted lookup rather than listing or querying.

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

get_layer_metadataGet ArcGIS layer metadataA

Fetch metadata (fields, geometry type, extent, name, description) for an ArcGIS FeatureServer/MapServer layer URL, such as one returned by list_datasets or get_dataset as 'featureServiceUrl'.

ParametersJSON Schema

Name	Required	Description	Default
`layerUrl`	Yes	ArcGIS REST layer URL, e.g. https://gis.occ.ok.gov/server/rest/services/Hosted/RBDMS_WELLS/FeatureServer/220

TDQS

A4/5.0

Behavior3/5

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

With no annotations, the description must convey behavioral traits. The verb 'Fetch' implies a read-only operation, and the description lists the returned metadata fields, which is useful. However, it does not disclose error handling, authentication requirements, or any side effects (though likely none). It is adequate but lacks rich behavioral context that might be expected.

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 a single sentence that front-loads the action and resource, then lists the metadata fields. It is concise with no fluff, and every word adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple (one parameter, no output schema), and the description covers its purpose, input source, and the fields it returns. It goes beyond the minimum by specifying the expected URL type and provenance. Minor gaps include not describing the response format, but the listed fields effectively convey what is returned.

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?

The input schema already fully describes the single parameter 'layerUrl' with a description and example, giving 100% schema coverage. The description adds a small hint about the URL's provenance (from list_datasets/get_dataset) and that it should be a layer endpoint, but this is marginal. Baseline 3 is appropriate.

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's purpose with a specific verb ('Fetch') and resource ('ArcGIS FeatureServer/MapServer layer URL'), enumerating the exact metadata fields returned (fields, geometry type, extent, name, description). It also differentiates from siblings by referencing list_datasets/get_dataset and focusing on metadata, not querying.

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?

The description provides context on when to use the tool: for a layer URL such as one returned by list_datasets or get_dataset as 'featureServiceUrl'. This implies it is the follow-up to those tools. It does not explicitly exclude alternatives like query_layer, but the context is clear enough for an agent to choose it for metadata retrieval.

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

list_datasetsList OCC GIS datasetsA

List/search datasets published on the OCC GIS open data hub (gisdata-occokc.opendata.arcgis.com). Optionally filter with a free-text query matched against title, description, and keywords. Returns each dataset's title, description, landing page, keywords, and (when available) its ArcGIS FeatureServer/MapServer REST URL plus downloadable formats (CSV, GeoJSON, Shapefile, KML, File Geodatabase).

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Max number of results to return (default 25)
`query`	No	Optional free-text search, e.g. 'wells', 'tanks', 'pipeline'

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden. It discloses the data source URL, search matching behavior (title, description, keywords), and return fields, plus the caveat 'when available' for REST URL and formats, offering honest behavioral insight without promising more than the tool likely delivers.

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 two sentences and front-loads the core purpose. It is somewhat dense with comma-separated return field details, but every element serves a functional purpose and no filler exists.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema is present, so the description adequately enumerates return fields and optional filters. It could mention pagination or default limits, but the limit parameter in the schema already covers that, making this sufficiently complete for a list/search tool.

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?

Input schema already has 100% coverage for the two parameters. The description adds meaning beyond the schema by specifying that the query is 'matched against title, description, and keywords', which enriches the schema's generic 'Optional free-text search'.

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 opens with 'List/search datasets published on the OCC GIS open data hub', using a specific verb and resource. It clearly distinguishes from siblings like get_dataset (single dataset) and query_layer (feature query) by focusing on dataset listing/searching.

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

Usage Guidelines3/5

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

The description explains what the tool does and the optional query filter, but it does not explicitly state when to use this tool over siblings or when to avoid it. Usage is implied by the 'List/search' purpose, but no alternatives or exclusions are mentioned.

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

query_layerQuery an ArcGIS layer's featuresA

Run an attribute and/or spatial query against an ArcGIS FeatureServer/MapServer layer (e.g. OCC well points, tank sites) and return matching feature attributes (and optionally geometry) as JSON. Use get_layer_metadata first to see available fields.

ParametersJSON Schema

Name	Required	Description
`where`	No	SQL-style attribute filter, e.g. "COUNTY = 'OKLAHOMA'" or "STATUS = 'AC'". Defaults to 1=1 (all rows).
`geometry`	No	Optional spatial filter geometry, e.g. 'xmin,ymin,xmax,ymax' envelope in WGS84 lon/lat.
`layerUrl`	Yes	ArcGIS REST layer URL, e.g. https://gis.occ.ok.gov/server/rest/services/Hosted/RBDMS_WELLS/FeatureServer/220
`outFields`	No	Comma-separated field names to return, or '*' for all (default).
`spatialRel`	No	Spatial relationship, e.g. esriSpatialRelIntersects (default).
`geometryType`	No	Geometry type for the 'geometry' param, e.g. esriGeometryEnvelope (default) or esriGeometryPoint.
`orderByFields`	No	Comma-separated field(s) to sort by, e.g. 'API_NUMBER ASC'.
`returnGeometry`	No	Whether to include geometry (lat/lon) in results (default false).
`resultRecordCount`	No	Max number of records to return (default 50).

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It discloses the return format (JSON), optional geometry inclusion, and the nature of querying (read-only is implied). It could mention error handling or response size limits, but the 'Use get_layer_metadata first' hint and example layer URLs add useful context beyond minimal.

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 two sentences long, front-loaded with the action, and every word contributes. It avoids redundancy while including examples and a usage hint, making it both concise and structured for quick scanning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 9 parameters and no output schema, the description covers the essential context: purpose, return type, and a prerequisite action. It does not mention output structure or error handling, but given the interactive schema and sibling context, it is reasonably complete.

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%, so the schema already documents all parameters. The description adds a helpful pointer to get_layer_metadata for field discovery, but does not elaborate on parameter relationships or edge cases. This meets the baseline for high schema coverage without adding substantial extra meaning.

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 runs an attribute and/or spatial query against an ArcGIS FeatureServer/MapServer layer and returns matching features as JSON. It uses a specific verb 'Run' and identifies the resource (layer), examples (OCC well points, tank sites), and distinguishes from siblings by explicitly mentioning get_layer_metadata.

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?

The description provides explicit context for when to use this tool (attribute/spatial query) and instructs to use get_layer_metadata first to see available fields, which implies a prerequisite step. It does not explicitly mention when not to use it or compare with list_datasets/get_dataset, but the guidance is clear enough for typical use.

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.

4 tool updatesv1.0.0Aug 21, 2026
- First observedget_dataset
- First observedget_layer_metadata
- First observedlist_datasets
- First observedquery_layer

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

A4.4/5.0

Scored 2026-08-21 01:10 across 4 tools

Disambiguation5/5

Each tool has a clearly distinct role: listing/searching datasets, fetching full dataset details, inspecting layer metadata, and querying layer features. There is no overlap that would confuse an agent selecting among them.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (list_datasets, get_dataset, get_layer_metadata, query_layer), using snake_case throughout and verbs that clearly indicate the action.

Tool Count5/5

Four tools is an appropriate scope for a read-only GIS data discovery and query server. Each tool fills a necessary step in the workflow without redundancy or bloat.

Completeness5/5

The tool surface fully covers the core workflow: discovering datasets, retrieving full metadata, inspecting layer schemas, and querying features. No obvious dead ends exist; even direct data downloads are covered via distribution URLs returned by the get_dataset tool.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

CountyLayer
io.github.Esoteric918
MCP server for querying Tulsa County, Oklahoma property and parcel data for AI agents.
Real Estate Government Data
1
UnifAPIOAuth
com.unifapi
Hosted MCP server for live public-data APIs and Skills for AI agents.
Open Data Search AI & Machine Learning
2
OneSchema MCP Server
co.oneschema
MCP server that lets AI assistants use all OneSchema features exposed via the public API.
Data Platforms App Automation
1
openfolio
io.github.dodenbach
Agent-native MCP server over 49M+ US public and government records, privacy-first, always current.
Government Data Open Data Search
1

Related MCP Servers

Google Earth Engine MCP Server
Location Services Research & Data
cameronking4
A
license
Not graded
quality
D
maintenance
MCP server for interacting with Google Earth Engine, enabling geospatial analysis such as dataset visualization, statistics computation, and search via AI assistants.
Updated a year ago (2025-05-11 12:08 UTC)
15
MIT
mcp-arcgis-houston
Location Services Open Data Government Data
pipeworx-io
A
license
Not graded
quality
B
maintenance
This MCP server provides access to City of Houston GIS open geospatial data, enabling search, query, and schema retrieval of datasets like parcels and zoning through ArcGIS feature services.
Updated 18 days ago (2026-09-25 21:31 UTC)
21 npm
MIT
mcp-arcgis-tulsa
Location Services Open Data Government Data
pipeworx-io
A
license
Not graded
quality
B
maintenance
Enables searching and querying City of Tulsa GIS open geospatial datasets (parcels, zoning, public works) via ArcGIS Feature Services through natural language or direct MCP tool calls.
Updated 18 days ago (2026-09-25 21:59 UTC)
19 npm
MIT
socrata-mcp
Government Data Open Data
jcscocca
A
license
A
quality
D
maintenance
An MCP server that gives LLM agents typed, cached access to civic open-data portals via Socrata (SODA 2.1 + Discovery API), enabling search, query, profiling, sampling, and CSV export of datasets.
Updated 3 months ago (2026-07-11 03:35 UTC)
6
MIT