Which integrations are available for this server?

Provides CI/CD workflows for automated testing, code quality checks, and publishing to PyPI with trusted publishing setup Enables automated package publishing to both PyPI and TestPyPI repositories using trusted publishing for secure deployment Supports unit testing framework for validating MCP server functionality Built as a Python package that can be installed and run as an MCP server module

How do I use Hong Kong Open Data MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Hong Kong Open Data MCP Server search for datasets about public transportation in Hong Kong" 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.

Hong Kong Open Data MCP Server

Official

by mcp-open-data-hk

Overview Schema Source Related Servers Discussions Admin

Python

Remote

mcp-open-data-hk

This is an MCP (Model Context Protocol) server that provides access to data from DATA.GOV.HK, the official open data portal of the Hong Kong government.

Installation

Installing via Smithery

To install mcp-open-data-hk for Claude Desktop automatically via Smithery:

npx -y @smithery/cli install @mcp-open-data-hk/mcp-open-data-hk --client claude

Using uv (recommended)

When using uv no specific installation is needed. We will use uvx to directly run mcp-server-fetch.

Using PIP

Alternatively you can install mcp-server-fetch via pip:

pip install mcp-open-data-hk

After installation, you can run it as a script using:

python -m mcp_open_data_hk

After installation, configure your MCP-compatible client (like Cursor, Claude Code, or Claude Desktop) by adding the following to your settings.json:

{
  "mcpServers": {
    "mcp-open-data-hk": {
      "command": "uvx",
      "args": ["mcp-open-data-hk"]
    }
  }
}

{
  "mcpServers": {
    "mcp-open-data-hk": {
      "command": "python",
      "args": ["-m", "mcp_open_data_hk"]
    }
  }
}

Features

The server provides the following tools to interact with the DATA.GOV.HK API:

list_datasets - Get a list of dataset IDs
get_dataset_details - Get detailed information about a specific dataset
list_categories - Get a list of data categories
get_category_details - Get detailed information about a specific category
search_datasets - Search for datasets by query term with advanced options
search_datasets_with_facets - Search datasets and return faceted results
get_datasets_by_format - Get datasets by file format
get_supported_formats - Get list of supported file formats

Tools

list_datasets

Get a list of dataset IDs from DATA.GOV.HK

Parameters:

limit (optional): Maximum number of datasets to return (default: 1000)
offset (optional): Offset of the first dataset to return
language (optional): Language code (en, tc, sc) - defaults to "en"

get_dataset_details

Get detailed information about a specific dataset

Parameters:

dataset_id: The ID or name of the dataset to retrieve
language (optional): Language code (en, tc, sc) - defaults to "en"
include_tracking (optional): Add tracking information to dataset and resources - defaults to False

Get a list of data categories (groups)

Parameters:

order_by (optional): Field to sort by ('name' or 'packages') - deprecated, use sort instead
sort (optional): Sorting of results ('name asc', 'package_count desc', etc.) - defaults to "title asc"
limit (optional): Maximum number of categories to return
offset (optional): Offset for pagination
all_fields (optional): Return full group dictionaries instead of just names - defaults to False
language (optional): Language code (en, tc, sc) - defaults to "en"

get_category_details

Get detailed information about a specific category (group)

Parameters:

category_id: The ID or name of the category to retrieve
include_datasets (optional): Include a truncated list of the category's datasets - defaults to False
include_dataset_count (optional): Include the full package count - defaults to True
include_extras (optional): Include the category's extra fields - defaults to True
include_users (optional): Include the category's users - defaults to True
include_groups (optional): Include the category's sub groups - defaults to True
include_tags (optional): Include the category's tags - defaults to True
include_followers (optional): Include the category's number of followers - defaults to True
language (optional): Language code (en, tc, sc) - defaults to "en"

search_datasets

Search for datasets by query term using the package_search API.

This function searches across dataset titles, descriptions, and other metadata to find datasets matching the query term. It supports advanced Solr search parameters.

Parameters:

query (optional): The solr query string (e.g., "transport", "weather", ":" for all) - defaults to ":"
limit (optional): Maximum number of datasets to return (default: 10, max: 1000)
offset (optional): Offset for pagination - defaults to 0
language (optional): Language code (en, tc, sc) - defaults to "en"

Returns: A dictionary containing:

count: Total number of matching datasets
results: List of matching datasets (up to limit)
search_facets: Faceted information about the results
has_more: Boolean indicating if there are more results available

search_datasets_with_facets

Search for datasets and return faceted results for better data exploration.

This function is useful for exploring what types of data are available by showing counts of datasets grouped by tags, organizations, or other facets.

Parameters:

query (optional): The solr query string - defaults to ":"
language (optional): Language code (en, tc, sc) - defaults to "en"

Returns: A dictionary containing:

count: Total number of matching datasets
search_facets: Faceted information about the results
sample_results: First 3 matching datasets

get_datasets_by_format

Get datasets that have resources in a specific file format.

Parameters:

file_format: The file format to filter by (e.g., "CSV", "JSON", "GeoJSON")
limit (optional): Maximum number of datasets to return - defaults to 10
language (optional): Language code (en, tc, sc) - defaults to "en"

Returns: A dictionary containing:

count: Total number of matching datasets
results: List of matching datasets

get_supported_formats

Get a list of file formats supported by DATA.GOV.HK

Returns: A list of supported file formats

Local Testing

Run test scripts:

python tests/test_client.py
python tests/debug_search.py
python tests/comprehensive_test.py

Run server directly:

python -m src.mcp_open_data_hk

Run unit tests:

pytest tests/

Understanding Path Configuration

When installed as a package, the server can be referenced by its module name rather than file path. This is more convenient for users as they don't need to specify full file paths.

Installed Package:

{
  "mcpServers": {
    "mcp-open-data-hk": {
      "command": "python",
      "args": ["-m", "mcp_open_data_hk"]
    }
  }
}

Local Development (file path approach):

{
  "mcpServers": {
    "mcp-open-data-hk": {
      "command": "python",
      "args": ["-m", "src.mcp_open_data_hk"],
      "cwd": "/full/path/to/mcp-open-data-hk"
    }
  }
}

The package installation approach is recommended for end users, while the file path approach is useful for local development and testing.

Example Queries

Once installed, try these queries with your AI assistant:

"List some datasets from the Hong Kong government data portal via mcp-open-data-hk mcp."
"Find datasets related to transportation in Hong Kong. Use mcp-open-data-hk."
"What categories of data are available on DATA.GOV.HK? Use mcp-open-data-hk."
"Get details about the flight information dataset. Use mcp-open-data-hk."
"Search for datasets about weather in Hong Kong. Use mcp-open-data-hk."
"What file formats are supported by DATA.GOV.HK? Use mcp-open-data-hk."
"Find CSV datasets about population Use mcp-open-data-hk."
"Show me the most common tags in transport datasets Use mcp-open-data-hk."

The AI will automatically use the appropriate tools from your MCP server to fetch the requested information.

Troubleshooting

Common Issues

Module not found errors: Make sure you've installed the dependencies with pip install -e . for local development, or pip install mcp-open-data-hk for the published package.
Path issues: Ensure the cwd in your IDE configuration is the correct absolute path to the project root.
Permission errors: On Unix systems, make sure the scripts have execute permissions:
```
chmod +x src/mcp_open_data_hk/__main__.py
```
FastMCP not found: Install it with:
```
pip install fastmcp
```

Testing the Connection

If you're having issues, you can test the connection manually:

Run the server in one terminal:
```
python -m src.mcp_open_data_hk
```
In another terminal, run the test client:
```
python tests/test_client.py
```

If this works, the issue is likely in the IDE configuration.

Extending the Server

You can extend the server by adding more tools in src/mcp_open_data_hk/server.py. Follow the existing patterns:

Add a new function decorated with @mcp.tool
Provide a clear docstring explaining the function and parameters
Implement the functionality
Test with the client

The server automatically exposes all functions decorated with @mcp.tool to MCP clients.

GitHub Workflows

This project includes GitHub Actions workflows for CI/CD:

CI Workflow: Runs tests across multiple Python versions (3.10-3.12) on every push/PR to main branch
Publish Workflow: Automatically builds and publishes to TestPyPI on every push to main, and to PyPI on version tags (v*.*.*)
Code Quality Workflow: Checks code formatting and linting on every push/PR
Release Workflow: Automatically creates GitHub releases when tags are pushed

Setup for Publishing (Trusted Publishing)

This project uses PyPI's Trusted Publishing which is more secure than using API tokens. To set it up:

Go to https://pypi.org/manage/account/publishing/ and add a new pending publisher with:
- Project name: mcp-open-data-hk
- Owner: Your GitHub username or organization
- Repository name: mcp-open-data-hk
- Workflow name: publish.yml
- Environment name: pypi
Go to https://test.pypi.org/manage/account/publishing/ and add a new pending publisher with the same information but use testpypi as the environment name.
In your GitHub repository, go to "Settings" > "Environments" and create two environments:
- pypi - Set "Required reviewers" to your username for security
- testpypi - No additional configuration needed

With Trusted Publishing, no API tokens need to be created or stored as secrets.

GitHub Environments

For the Trusted Publishing to work correctly, you need to create two environments in your GitHub repository settings:

pypi - This environment requires manual approval for security when publishing to PyPI
testpypi - This environment doesn't require manual approval and will automatically publish to TestPyPI

To create these environments:

Go to your repository's "Settings" tab
Click on "Environments" in the left sidebar
Click "New environment"
Create the pypi environment and enable "Required reviewers" with your username
Create the testpypi environment with no additional settings

Releasing New Versions

To release a new version:

Update the version number in pyproject.toml
Commit the changes

Create and push a new tag:

git tag -a v1.0.0 -m "Release version 1.0.0"
git push origin v1.0.0

Or use the provided release script:

./release.sh 1.0.0

This will automatically trigger the publish workflow to build and publish the package to TestPyPI and PyPI (for tagged releases), and create a GitHub release.

Contributing

Contributions are welcome! Please read our Contributing Guide and Code of Conduct for details on how to contribute to this project.

Project Structure

mcp-open-data-hk/
├── src/
│   └── mcp_open_data_hk/  # Main Python package
│       ├── __init__.py    # Package initialization
│       ├── __main__.py    # Package entry point
│       └── server.py      # Main MCP server implementation
├── tests/
│   ├── test_client.py     # Client test script
│   ├── debug_search.py    # Search functionality test
│   ├── comprehensive_test.py # Comprehensive functionality test
│   └── test_data_gov_hk.py # Unit tests
├── requirements.txt       # Python dependencies
├── pyproject.toml         # Project configuration
├── README.md             # This file
├── run_examples.sh       # Example commands script
├── install.sh            # Installation helper script
├── release.sh            # Release helper script
└── .gitignore            # Git ignore file

License

This project is licensed under the MIT License.

Available Tools

8 tools

get_category_detailsC

Get detailed information about a specific category (group)

ParametersJSON Schema

Name	Required	Description	Default
`category_id`	Yes	The ID or name of the category to retrieve
`include_datasets`	No	Include a truncated list of the category's datasets
`include_dataset_count`	No	Include the full package count
`include_extras`	No	Include the category's extra fields
`include_users`	No	Include the category's users
`include_groups`	No	Include the category's sub groups
`include_tags`	No	Include the category's tags
`include_followers`	No	Include the category's number of followers
`language`	No	Language code (en, tc, sc)	en

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description should disclose behavioral traits. It only states the tool 'gets' information, which is read-only, but does not mention side effects, authentication requirements, or response characteristics beyond what the output schema covers.

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 a single, concise sentence that front-loads the core purpose. It is efficient but could benefit from additional context without sacrificing brevity.

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

Completeness2/5

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

Given the tool has 9 parameters and an output schema, the description is too sparse. It does not explain what 'detailed information' includes or how the boolean flags affect the result, leaving the agent to infer from the schema alone.

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 the baseline is 3. The description adds no additional meaning to the parameters; it simply restates the tool's purpose.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves detailed information about a specific category, with the parenthetical '(group)' clarifying the resource. However, it does not explicitly distinguish itself from sibling tools like 'list_categories' which might also return category details but in a different manner.

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 is provided on when to use this tool versus alternatives like 'get_dataset_details' or 'list_categories'. The description lacks context on prerequisites or use cases.

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

get_dataset_detailsB

Get detailed information about a specific dataset

ParametersJSON Schema

Name	Required	Description	Default
`dataset_id`	Yes	The ID or name of the dataset to retrieve
`language`	No	Language code (en, tc, sc)	en
`include_tracking`	No	Add tracking information to dataset and resources

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are present, so the description must carry the full burden. It implies a read-only operation via 'get', but lacks details on side effects, permissions, error behavior, or idempotency. This is insufficient for a tool with no annotation support.

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, direct sentence that efficiently conveys the tool's purpose without any unnecessary words or details. Perfectly concise.

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

Completeness3/5

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

Given the tool's simplicity (3 parameters) and the presence of an output schema, the description is minimally adequate. However, it lacks context about what 'detailed information' includes and when to prefer this over similar tools, leaving some ambiguity.

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 describes all parameters. The description adds no extra meaning beyond what the input schema provides. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves detailed information about a specific dataset, using the verb 'get' and the resource 'dataset'. It distinguishes from siblings like 'list_datasets' and 'search_datasets', but could be more specific about what 'detailed information' includes.

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 is provided on when to use this tool versus alternatives (e.g., list_datasets, search_datasets). The description does not specify that it is for a single dataset or mention any prerequisites or context.

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

get_datasets_by_formatA

Get datasets that have resources in a specific file format.

ParametersJSON Schema

Name	Required	Description	Default
`file_format`	Yes	The file format to filter by (e.g., "CSV", "JSON", "GeoJSON")
`limit`	No	Maximum number of datasets to return
`language`	No	Language code (en, tc, sc)	en

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.5/5.0

Behavior3/5

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

Without annotations, the description should disclose behavioral traits beyond the basic operation. It only states the core function (filtering by format) but omits details like pagination (implied by limit parameter), result ordering, or handling of missing data. Minimal transparency.

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, concise sentence with no extraneous words. It is front-loaded with the action and result, making it easy to parse. Every word is necessary.

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

Completeness3/5

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

Given that an output schema exists and parameter schema coverage is full, the description could be considered minimal but still lacks key context like pagination behavior, error responses, and differentiation from similar tools. It is adequate for a simple filter but not robust.

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 provides descriptions for all parameters (100% coverage), so the baseline is 3. The description adds no extra meaning beyond the schema, such as explaining valid file format values or case sensitivity. It does not leverage the opportunity to clarify parameter usage.

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 retrieves datasets filtered by file format, distinguishing it from sibling tools like list_datasets (all datasets) or search_datasets (query-based). The verb 'Get' and resource 'datasets' with the condition 'in a specific file format' provide specific purpose.

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 explicit guidance on when to use this tool versus alternatives such as search_datasets_with_facets or list_datasets. The description does not mention limitations, prerequisites, or scenarios where this tool is preferable, leaving the agent without decision support.

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

get_supported_formatsA

Get a list of file formats supported by data.gov.hk

Returns: A list of supported file formats

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.5/5.0

Behavior2/5

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

With no annotations, the description carries full burden but only states it returns a list. It does not disclose if the tool is read-only, has rate limits, or other behavioral traits, leaving the agent uninformed.

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?

Extremely concise with no waste. The action and resource are front-loaded in the first line, and the return is briefly noted.

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

Completeness3/5

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

The tool is simple with no parameters and an output schema present, so the description need not be exhaustive. However, it vaguely mentions 'a list of supported file formats' without specifying format types, leaving some ambiguity.

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?

No parameters exist, so baseline 4 applies. The description adds no param info but is not required; schema coverage is 100% with zero parameters.

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 action ('Get a list of file formats') and the resource ('supported by data.gov.hk'), making it distinct from sibling tools that deal with datasets and categories.

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 is provided on when to use this tool versus alternatives, though its simplicity may imply standalone use. Explicit context would improve decision-making.

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

list_categoriesC

Get a list of data categories (groups)

ParametersJSON Schema

Name	Required	Description	Default
`order_by`	No	Field to sort by ('name' or 'packages') - deprecated, use sort instead	name
`sort`	No	Sorting of results ('name asc', 'package_count desc', etc.)	title asc
`limit`	No	Maximum number of categories to return
`offset`	No	Offset for pagination
`all_fields`	No	Return full group dictionaries instead of just names
`language`	No	Language code (en, tc, sc)	en

TDQS

C2.9/5.0

Behavior2/5

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

No annotations exist, and the description does not disclose behavioral traits such as whether the tool is read-only, pagination defaults, or what happens when no categories exist. It only states 'get a list,' leaving many behavioral details implicit.

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 a single concise sentence with no redundancy, but it is minimal. It achieves its purpose without extra words, though it could include more context without becoming verbose.

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

Completeness3/5

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

Given the high schema coverage and no output schema, the description is somewhat complete for listing categories. However, it omits information about the return format (when all_fields is used) and how this fits into the overall API.

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 descriptions cover all 6 parameters with details like defaults and deprecation, so the description adds no additional semantic value. With 100% schema coverage, a baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns a list of data categories, using the verb 'get' and specifying the resource. However, it does not distinguish itself from sibling tools like list_datasets or explain what 'groups' means.

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 is provided on when to use this tool versus alternatives (e.g., get_category_details for a single category, list_datasets for datasets). The description lacks context for appropriate usage.

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

list_datasetsB

Get a list of dataset IDs from data.gov.hk

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Maximum number of datasets to return (default: 1000)
`offset`	No	Offset of the first dataset to return
`language`	No	Language code (en, tc, sc)	en

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.1/5.0

Behavior2/5

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

The description does not disclose behavioral traits such as pagination behavior, default ordering, or the effect of the language parameter. Since no annotations are present, the description carries full burden and is insufficient.

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 concise with a single sentence that front-loads the purpose. However, it could include slightly more context without becoming verbose.

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

Completeness2/5

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

Given the tool has three optional parameters and an output schema, the description lacks information about pagination, default ordering, or how language affects the result. This is insufficient for a list operation.

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 a baseline of 3 is appropriate. The tool description does not add any meaning beyond what the schema already provides (e.g., limit max, offset behavior).

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 verb 'Get', the resource 'list of dataset IDs', and the source 'data.gov.hk'. It sufficiently distinguishes from siblings like get_dataset_details or search_datasets, which have different purposes.

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 is provided on when to use this tool versus alternatives such as search_datasets or list_categories. An agent would lack context for appropriate invocation.

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

search_datasetsC

Search for datasets by query term using the package_search API.

This function searches across dataset titles, descriptions, and other metadata to find datasets matching the query term.

ParametersJSON Schema

Name	Required	Description	Default
`query`	No	The solr query string (e.g., "transport", "weather", ":" for all)	:
`limit`	No	Maximum number of datasets to return (default: 10, max: 1000)
`offset`	No	Offset for pagination
`language`	No	Language code (en, tc, sc)	en

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It reveals that the tool uses the package_search API and searches across metadata fields, but it does not disclose behavioral traits like pagination behavior, rate limits, or what happens with excess parameters. The output is not described despite an output schema existing.

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 exceptionally concise: two sentences that effectively state the purpose and the scope of search. No redundant information.

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

Completeness2/5

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

Despite having an output schema and 100% schema coverage, the description omits important contextual details such as pagination (limit/offset), language filtering, and the fact that all parameters are optional. It does not prepare the agent for how to handle large result sets or filter by language.

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 has 100% description coverage, providing clear parameter definitions. The tool description adds some context (e.g., 'searches across dataset titles, descriptions, and other metadata') but does not significantly enhance parameter understanding beyond the schema. Baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool searches for datasets by query term using the package_search API. It specifies the scope (titles, descriptions, metadata). However, it does not explicitly differentiate from sibling tools like search_datasets_with_facets, which may perform similar but richer searches.

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?

The description provides no guidance on when to use this tool versus alternatives, such as search_datasets_with_facets or list_datasets. It does not mention ideal scenarios, prerequisites, or when not to use it.

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

search_datasets_with_facetsB

Search for datasets and return faceted results for better data exploration.

ParametersJSON Schema

Name	Required	Description	Default
`query`	No	The solr query string	:
`language`	No	Language code (en, tc, sc)	en

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations, the description carries the full burden. It only states it returns faceted results but provides no details on the facets themselves, limitations, or safety (read-only). The output schema exists but is not referenced.

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 a single sentence, concise and front-loaded. However, at only 13 words for a complex faceted search tool, it may be too brief to be fully informative.

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

Completeness2/5

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

The tool has an output schema, so return values are covered. However, the description lacks context on how to interpret facets or the range of possible queries. Given the sibling tools like list_categories, some cross-reference could help.

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?

Both parameters have descriptions in the schema covering 100% coverage. The description adds no extra semantic meaning beyond 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 clearly states the tool 'Search for datasets' and specifies the unique feature 'return faceted results for better data exploration.' This distinguishes it from the sibling 'search_datasets' which likely returns non-faceted results.

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 implies usage for data exploration with faceted results, but does not explicitly state when to use this tool over 'search_datasets' or any other sibling. No mention of prerequisites or scenarios.

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.

8 tool updatesv0.2.3May 4, 2026
- Changedget_category_details10 fields changed
  - addedInput schema / additionalProperties
```
Added value: +false
```
  - addedInput schema / properties / category_id / description
```
Added value: +"The ID or name of the category to retrieve"
```
  - addedInput schema / properties / include_dataset_count / description
```
Added value: +"Include the full package count"
```
  - addedInput schema / properties / include_datasets / description
```
Added value: +"Include a truncated list of the category's datasets"
```
  - addedInput schema / properties / include_extras / description
```
Added value: +"Include the category's extra fields"
```
  - addedInput schema / properties / include_followers / description
```
Added value: +"Include the category's number of followers"
```
  - addedInput schema / properties / include_groups / description
```
Added value: +"Include the category's sub groups"
```
  - addedInput schema / properties / include_tags / description
```
Added value: +"Include the category's tags"
```
  - addedInput schema / properties / include_users / description
```
Added value: +"Include the category's users"
```
  - addedInput schema / properties / language / description
```
Added value: +"Language code (en, tc, sc)"
```
- Changedget_dataset_details4 fields changed
  - addedInput schema / additionalProperties
```
Added value: +false
```
  - addedInput schema / properties / dataset_id / description
```
Added value: +"The ID or name of the dataset to retrieve"
```
  - addedInput schema / properties / include_tracking / description
```
Added value: +"Add tracking information to dataset and resources"
```
  - addedInput schema / properties / language / description
```
Added value: +"Language code (en, tc, sc)"
```
- Changedget_datasets_by_format4 fields changed
  - addedInput schema / additionalProperties
```
Added value: +false
```
  - addedInput schema / properties / file_format / description
```
Added value: +"The file format to filter by (e.g., \"CSV\", \"JSON\", \"GeoJSON\")"
```
  - addedInput schema / properties / language / description
```
Added value: +"Language code (en, tc, sc)"
```
  - addedInput schema / properties / limit / description
```
Added value: +"Maximum number of datasets to return"
```
- Changedget_supported_formats1 field changed
  - addedInput schema / additionalProperties
```
Added value: +false
```
- Changedlist_categories7 fields changed
  - addedInput schema / additionalProperties
```
Added value: +false
```
  - addedInput schema / properties / all_fields / description
```
Added value: +"Return full group dictionaries instead of just names"
```
  - addedInput schema / properties / language / description
```
Added value: +"Language code (en, tc, sc)"
```
  - addedInput schema / properties / limit / description
```
Added value: +"Maximum number of categories to return"
```
  - addedInput schema / properties / offset / description
```
Added value: +"Offset for pagination"
```
  - addedInput schema / properties / order_by / description
```
Added value: +"Field to sort by ('name' or 'packages') - deprecated, use sort instead"
```
  - addedInput schema / properties / sort / description
```
Added value: +"Sorting of results ('name asc', 'package_count desc', etc.)"
```
- Changedlist_datasets4 fields changed
  - addedInput schema / additionalProperties
```
Added value: +false
```
  - addedInput schema / properties / language / description
```
Added value: +"Language code (en, tc, sc)"
```
  - addedInput schema / properties / limit / description
```
Added value: +"Maximum number of datasets to return (default: 1000)"
```
  - addedInput schema / properties / offset / description
```
Added value: +"Offset of the first dataset to return"
```
- Changedsearch_datasets5 fields changed
  - addedInput schema / additionalProperties
```
Added value: +false
```
  - addedInput schema / properties / language / description
```
Added value: +"Language code (en, tc, sc)"
```
  - addedInput schema / properties / limit / description
```
Added value: +"Maximum number of datasets to return (default: 10, max: 1000)"
```
  - addedInput schema / properties / offset / description
```
Added value: +"Offset for pagination"
```
  - addedInput schema / properties / query / description
```
Added value: +"The solr query string (e.g., \"transport\", \"weather\", \"*:*\" for all)"
```
- Changedsearch_datasets_with_facets3 fields changed
  - addedInput schema / additionalProperties
```
Added value: +false
```
  - addedInput schema / properties / language / description
```
Added value: +"Language code (en, tc, sc)"
```
  - addedInput schema / properties / query / description
```
Added value: +"The solr query string"
```
8 tool updatesOct 1, 2025
- First observedget_category_details
- First observedget_dataset_details
- First observedget_datasets_by_format
- First observedget_supported_formats
- First observedlist_categories
- First observedlist_datasets
- First observedsearch_datasets
- First observedsearch_datasets_with_facets

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

A3.6/5.0

Scored 2026-05-04 20:25 across 8 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: categories, datasets, formats, and search are separate concerns. Overlap between get_datasets_by_format and search_datasets is minimized by specific parameters and descriptions.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern (get, list, search) with descriptive nouns, all using snake_case. No mixing of conventions or ambiguous verbs.

Tool Count5/5

8 tools is well-scoped for an open data portal, covering essential operations: browsing categories, listing/searching datasets, getting details, and checking formats. Each tool serves a clear purpose without redundancy.

Completeness4/5

The set covers core CRUD-like operations for dataset discovery. Minor gap: no tool for retrieving resource download URLs or filtering datasets beyond format, but the search and details tools likely include that data.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Reddit Discussion

Related Servers

Related MCP Connectors

Censtatd Hk A
io.github.pipeworx-io
Hong Kong Census and Statistics Department (C&SD) open-data MCP.
Government Data Open Data
2
Hk Companies A
io.github.pipeworx-io
Hong Kong Companies Registry open data — company/BR-number search, new registrations & name changes
Government Data Open Data Search
1
hithereiamaliff-mcp-datagovmy BOAuth
ai.smithery
This MCP server provides seamless access to Malaysia's government open data, including datasets, w…
Government Data Open Data
3123
Hkma Hk A
io.github.pipeworx-io
Hong Kong Monetary Authority (HKMA) public open API MCP. Keyless.
Government Data Open Data Finance
2

Related MCP Servers

mcp-hko
Weather Services Government Data
louiscklaw
A
license
B
quality
D
maintenance
Provides access to Hong Kong Observatory weather data APIs, enabling retrieval of forecasts, earthquake info, tide data, and more via natural language.
Updated a year ago (2025-08-14 09:13 UTC)
20
2
MIT
Hong Kong community and social
Government Data Open Data
hkopenai
A
license
A
quality
C
maintenance
Enables querying of Hong Kong government data on elderly community care services, such as waiting times and applicant counts.
Updated a month ago (2026-08-10 05:43 UTC)
1
1
MIT
Thai Open Data MCP
Government Data Open Data
sarapab-th
A
license
Not graded
quality
B
maintenance
Enables AI assistants to search and read Thailand's official open-government data from data.go.th, providing tools to search datasets, retrieve full records, and browse categories without API keys.
Updated 2 months ago (2026-07-10 13:55 UTC)
MIT
mcp-hongkong-procurement
Government Data Open Data
pipeworx-io
A
license
Not graded
quality
B
maintenance
Enables querying Hong Kong Government procurement contracts awarded data through natural language, with no API key required.
Updated 5 days ago (2026-09-18 22:21 UTC)
4 npm
MIT

mcp-open-data-hk

Installation

Installing via Smithery

Using uv (recommended)

Using PIP

Features

Tools

list_datasets

get_dataset_details

list_categories

get_category_details

search_datasets

search_datasets_with_facets

get_datasets_by_format

get_supported_formats

Local Testing

Run test scripts:

Run server directly:

Run unit tests:

Understanding Path Configuration

Installed Package:

Local Development (file path approach):

Example Queries

Troubleshooting

Common Issues

Testing the Connection

Extending the Server

GitHub Workflows

Setup for Publishing (Trusted Publishing)

GitHub Environments

Releasing New Versions

Contributing

Project Structure

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches