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., "@uk-charities-mcp Get details for Oxfam (charity 202918)"
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.
Query UK charity data via MCP.
Related MCP server: DataNexus MCP
Prerequisites: Free API key from api-portal.charitycommission.gov.uk
Works with any MCP-compatible client (Claude Desktop, VS Code, Cursor, etc.). Example for Claude Desktop:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"uk-charities": {
"command": "uvx",
"args": ["uk-charities-mcp"],
"env": {
"CCEW_API_KEY": "your-api-key-here"
}
}
}
}git clone https://github.com/w4sspr/uk-charities-mcp.git
cd uk-charities-mcp
uv sync{
"mcpServers": {
"uk-charities": {
"command": "uv",
"args": ["run", "--directory", "/path/to/uk-charities-mcp", "uk-charities-mcp"],
"env": {
"CCEW_API_KEY": "your-api-key-here"
}
}
}
}Troubleshooting: If you get
spawn uvx ENOENTorspawn uv ENOENT, Claude Desktop can't find the executable. Use the full path instead (runwhich uvxorwhich uvto find it, e.g.,/Users/you/.local/bin/uvx).
Restart Claude Desktop, then try:
"Get details for Oxfam (charity 202918)"
"Get details for charity 202918" (Oxfam)
"Show me the financial history for the British Heart Foundation (225971)"
"Who are the trustees of Cancer Research UK (1089464)?"
"What are the charitable objects of the RSPCA (219099)?"
Note: This MCP requires charity registration numbers. Find them at register-of-charities.charitycommission.gov.uk
Example Charities | Registration # |
Oxfam | 202918 |
British Heart Foundation | 225971 |
Cancer Research UK | 1089464 |
RSPCA | 219099 |
Save the Children | 213890 |
get_charity_detailsFull charity info: name, status, contact, trustees, causes, beneficiaries, latest income/spending.
Parameter | Type | Description |
| int | Charity registration number |
get_charity_financialsUp to 5 years of detailed financial records.
Parameter | Type | Description |
| int | Charity registration number |
Returns breakdowns: donations & legacies, charitable activities, trading, investments, government grants, fundraising, governance.
get_charity_trusteesList of current trustees.
Parameter | Type | Description |
| int | Charity registration number |
get_governing_documentCharitable objects (mission), governing document description, area of benefit.
Parameter | Type | Description |
| int | Charity registration number |
No search by name — CCEW API has no search endpoint; you must provide the registration number
England & Wales only — Scotland uses OSCR, Northern Ireland uses CCNI
No aggregate statistics — can't query "largest charities" or sector-wide stats
Current trustees only — API doesn't provide historical trustee records
Prompts that won't work:
"Find mental health charities in London" (no search by cause/location)
"List the largest charities by income" (no ranking)
"How many charities are there in the UK?" (no aggregate stats)
Scotland charities via OSCR API
Northern Ireland charities via CCNI API
Caching layer to reduce API calls
Bulk lookup for comparing multiple charities
# Run tests
export CCEW_API_KEY=your-api-key
uv run pytest tests/ -v
# Test with MCP Inspector
CCEW_API_KEY=your-api-key uv run mcp dev src/uk_charities_mcp/server.pyWhy I built this: MCP integration with UK public sector data APIs. See also: food-hygiene-mcp for FSA food hygiene ratings.
Charity Commission API — free, requires API key.
MIT
Get full details for a UK charity by registration number.
Args: registration_number: The charity's registration number (e.g., 202918 for Oxfam). Find registration numbers at: https://register-of-charities.charitycommission.gov.uk/
Returns: Comprehensive charity information including contact details, trustees, and finances.
| Name | Required | Description | Default |
|---|---|---|---|
| registration_number | Yes |
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| causes | No | |
| income | No | |
| status | Yes | |
| contact | Yes | |
| spending | No | |
| trustees | No | |
| operations | No | |
| charity_type | No | |
| beneficiaries | No | |
| registration_date | No | |
| registration_number | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states the output scope (contact details, trustees, finances) and the read-only nature (via 'Get'), but does not disclose any potential limitations such as rate limits or data volume.
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 concise, front-loaded with the purpose, and uses clear Args and Returns sections without any fluff.
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?
For a simple one-parameter read tool, the description covers what it does, how to obtain the input, and what to expect in return, all in a few sentences. The presence of an output schema further completes the picture.
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?
Although the schema only defines an integer parameter, the description's Args section adds a concrete example (202918 for Oxfam) and a direct link for finding registration numbers, fully compensating for the 0% schema description coverage.
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 opens with a clear verb ('Get'), resource ('full details for a UK charity'), and required input (registration number), clearly distinguishing it from sibling tools that focus on specific aspects like financials or trustees.
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?
The description clearly indicates this is the comprehensive lookup tool ('full details'), implying when to use it over the more specific siblings, though it doesn't explicitly mention alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed financial history for a charity.
Args: registration_number: The charity's registration number.
Returns: Up to 5 years of financial data with detailed income and spending breakdowns.
| Name | Required | Description | Default |
|---|---|---|---|
| registration_number | Yes |
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| history | No | |
| registration_number | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It adds meaningful behavioral context by specifying 'Up to 5 years of financial data' and 'detailed income and spending breakdowns,' which goes beyond the bare operation name. However, it does not mention any error conditions or access requirements, though for a read-only lookup this is acceptable.
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 compact, uses a clear Args/Returns structure, and every sentence earns its place. It avoids redundant filler and is appropriately sized for the tool's simple single-parameter signature.
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 has an output schema (though not shown), so the description need not fully explain returns, but it does anyway, noting the 5-year limit and breakdowns. With one parameter, no annotations, and a simple purpose, the description covers the essential context adequately. It lacks edge-case guidance (e.g., invalid registration number) but is otherwise complete for this level of complexity.
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 schema has no per-parameter descriptions (0% coverage), so the description must compensate. It does provide a definition: 'registration_number: The charity's registration number.' This is essentially a restatement of the parameter name and adds little semantic value beyond confirming the obvious, but it is sufficient for a single well-named parameter.
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 states a specific verb+resource: 'Get detailed financial history for a charity.' This clearly distinguishes the tool from siblings like get_charity_details, get_charity_trustees, and get_governing_document, which serve different purposes.
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?
The intended usage is implied by the tool name and sibling context, but the description does not explicitly state when to use this tool versus alternatives. There is no mention of exclusions or alternative use cases, so guidance is merely inferred rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the list of trustees for a charity.
Args: registration_number: The charity's registration number.
Returns: The charity name and list of current trustees.
| Name | Required | Description | Default |
|---|---|---|---|
| registration_number | Yes |
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| trustees | No | |
| registration_number | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It does mention the return value (charity name and current trustees), which provides some context, but it omits behavior like error handling, ordering, or what happens if the charity is not found. This is minimal but not completely absent.
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 very concise, with a clear two-part structure of Args and Returns. Every sentence is useful and it is front-loaded with the main purpose.
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?
For a simple read tool with one parameter and an output schema, the description is adequately complete. It specifies the return content, and given low complexity, the lack of edge-case details is acceptable.
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 0%, so the description must compensate. It documents the registration_number parameter as 'The charity's registration number,' adding meaning beyond the bare integer type. However, it does not provide validation rules or format specifics.
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 it retrieves the list of trustees for a charity, using a specific verb and resource. It is distinct from sibling tools such as get_charity_details and get_charity_financials, which cover other aspects of charity data.
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?
The usage is implied: if you need trustee information, use this tool. However, it does not explicitly mention when to use it over alternatives or provide any exclusions such as requiring a valid registration number. There is no comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the charitable objects and governing document for a charity.
Args: registration_number: The charity's registration number.
Returns: The charity's charitable objects (mission statement), governing document type, and area of benefit.
| Name | Required | Description | Default |
|---|---|---|---|
| registration_number | Yes |
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| area_of_benefit | No | |
| charitable_objects | No | |
| governing_document | No | |
| registration_number | Yes |
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 only implies a read operation via 'Get' and lists return values, which are likely already covered by the output schema. It does not disclose error handling, prerequisites, or any other behavioral traits.
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 concise and well-structured, with clear sections for description, args, and returns. Every line serves a purpose, and there is no extraneous information.
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?
For a simple one-parameter get tool, the description covers the essential purpose and return values. However, with no annotations and no differentiation from sibling tools, there are gaps in usage guidance and behavioral transparency, making it just adequate.
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 description merely restates the parameter name and adds 'The charity's registration number,' which provides minimal additional meaning beyond the schema's type and title. It does not clarify format, source, or validation rules for the registration_number.
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 that the tool retrieves charitable objects and governing document for a charity, using a specific verb and resource. This distinguishes it from sibling tools like financials, trustees, and details, which cover different aspects of charity data.
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?
The description implies usage when governance-related information is needed, but it does not explicitly state when to choose this tool over siblings or provide exclusion criteria. No alternatives are mentioned, so guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0get_charity_detailsget_charity_financialsget_charity_trusteesget_governing_documentThe tools are mostly distinct (financials, trustees, governing document), but get_charity_details overlaps by including trustees and finances, which may cause an agent to pick the wrong tool. The descriptions help clarify depth, but the boundary is not fully crisp.
Most tools follow the get_charity_* pattern (get_charity_details, get_charity_financials, get_charity_trustees), but get_governing_document deviates by omitting the 'charity' prefix. Overall the naming is predictable and readable.
With 4 tools, the server is compact and focused on key charity information lookups. The count is reasonable for a specialized read-only API, though on the lower end, it fits the stated purpose.
The server lacks any search or discovery capability—all tools require a registration number, with no way to find charities by name or criteria. This is a significant gap that will cause agent failures when the registration number is unknown. The domain is also missing common operations like listing charities or getting contact details separately.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for nonprofit financials via ProPublica — IRS Form 990 data for 1.8M+ nonprofits.
Query UK Parliament, elections, crime stats, ONS census data, and national archives
Companies House MCP — UK statutory company registry (BYO key)
data.gov.uk MCP — UK national open-data portal (CKAN API).
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/w4sspr/uk-charities-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
