This is an MCP server that provides access to government community and social welfare data through a FastMCP interface.
Retrieve data on the number of applicants and average waiting time for subsidized community care services for the elderly in Hong Kong url
Related MCP server: hk-housing-mcp-server
Elderly community care services data from Social Welfare Department
Retrieve latest waiting time data subsidized community care services for elderly community care services in Hong Kong
Clone this repository
Install Python dependencies:
pip install -r requirements.txtRun the server:
python server.pyDefault stdio mode: python server.py
SSE mode (port 8000): python server.py --sse
To connect this MCP server to Cline using stdio:
Add this configuration to your Cline MCP settings (cline_mcp_settings.json):
{
"hk-community": {
"disabled": false,
"timeout": 3,
"type": "stdio",
"command": "uvx",
"args": [
"hkopenai.hk-community-mcp-server"
]
}
}Tests are available in the tests/ directory. Run with:
pytestRetrieve data on the number of applicants and average waiting time for subsidised community care services for the elderly in Hong Kong.
| Name | Required | Description | Default |
|---|---|---|---|
| end_year | Yes | End year for data range | |
| start_year | Yes | Start year for data range |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It communicates a read-only action ('Retrieve') and implies no side effects, but it does not disclose potential limitations such as year range constraints, data aggregation, or response size.
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, focused sentence that front-loads the core action and resource. No words are wasted.
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?
The tool is simple, with two well-documented parameters and an output schema. The description provides sufficient context about the data source and metrics, though it could note that years refer to reporting periods.
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?
The input schema fully documents both parameters (start_year and end_year) with descriptive text, achieving 100% coverage. The description adds no extra parameter semantics such as valid ranges or format expectations, so it meets the baseline.
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 clearly states the tool retrieves data on applicants and average waiting time for elderly community care services in Hong Kong. This specific verb-resource combination leaves no ambiguity about what the tool returns.
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 sibling tools are listed and no alternative options are mentioned. The description implies usage whenever this specific data is needed, but it does not explicitly say when to use versus not use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
There is only one tool, so there is no possibility of confusing it with another tool. Its purpose is clearly defined in the name and description.
The tool name follows a clear verb_noun pattern ('get_elderly_community_care_services'), which is consistent and descriptive. Even though it is a single tool, the naming convention is sound.
A server named 'Hong Kong community and social welfare' would be expected to cover many areas, but it has only one tool focused on elderly community care. This is too few for the apparent scope.
The tool only covers one specific service (elderly community care), leaving out many other social welfare domains such as youth, family, disability, and housing support. This is a severe gap for the stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Hong Kong Census and Statistics Department (C&SD) open-data MCP.
Query UK Parliament, elections, crime stats, ONS census data, and national archives
Access CQC care ratings, NHS health services, and food hygiene data across the UK
Query US Census Bureau data: demographics, economics, and housing statistics.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/hkopenai/hk-community-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
