Click on "Deploy 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., "@anonym-community-mcp What are the common PII pain points in healthcare?"
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.
Read-only Model Context Protocol server for the anonym.community privacy research corpus — 1,478 documented PII/privacy pain points, 98 structural root causes, a 240-jurisdiction privacy-law directory, 134 evidence-backed FAQ answers, and 1,600+ cited academic papers, queryable directly from Claude Desktop, Claude Code, Cursor, or any MCP client.
All of this is already public as HTML and JSON at anonym.community, but an agent trying to answer "which EU jurisdictions have a data protection authority and what law applies" has to crawl and re-derive that from prose every time. This server exposes the same corpus as typed, queryable tools, so an agent can ask precisely and cite exactly — pain point IDs, jurisdiction records, FAQ entries and paper DOIs, not paraphrased HTML.
Related MCP server: Cairn
Tool | Data | Use it for |
| 1,478 documented PII/privacy problems | "what goes wrong with X" |
| 98 irreducible root causes | "why does this keep happening" |
| 240 jurisdictions, DPAs, legislation | "is there a privacy law in X" |
| 134 evidence-backed Q&As | direct practitioner questions |
| 1,600+ academic papers with DOIs | "cite a primary source" |
| counts, valid filter values, data freshness | call first to discover valid |
Every result carries its identifiers and source links, so an answer can be cited back to a specific pain point, driver, jurisdiction, FAQ entry or DOI.
Add to your MCP config (claude_desktop_config.json, or .mcp.json in a project):
{
"mcpServers": {
"anonym-community": {
"command": "npx",
"args": ["-y", "github:georgecurta/anonym-community-mcp"]
}
}
}No install step, no clone, no local path. npx fetches and runs it on demand.
If you'd rather run a pinned local copy:
git clone https://github.com/georgecurta/anonym-community-mcp.git{
"mcpServers": {
"anonym-community": {
"command": "node",
"args": ["/absolute/path/to/anonym-community-mcp/index.js"]
}
}
}Same shape — the server speaks stdio JSON-RPC, the MCP default. No port, no credentials, nothing to host.
node index.js --selftestRuns 7 assertions against the live corpus (not fixtures) and exits non-zero on
failure. Expected output ends with 7 passed, 0 failed.
Manual protocol check:
printf '%s\n%s\n' \
'{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"probe","version":"1"}}}' \
'{"jsonrpc":"2.0","id":2,"method":"tools/list"}' | node index.js{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{
"name":"search_pain_points",
"arguments":{"query":"data broker opt-out","limit":2}
}}returns matched pain points with title, evidence, severity, structural driver track, category and source citations — ready to quote, not to re-summarize.
Live, not bundled. The server fetches https://anonym.community/data/*.json — the
same files the website itself is built from — at startup, caches in memory, and
refreshes on a TTL (stale-while-revalidate: a request just after the TTL expires gets
the cached answer immediately while a background fetch updates the cache for the next
one). The corpus this server answers from is never more than ANONYM_MCP_TTL_MS
(default 30 minutes) old, with no sync step to remember and no risk of a stale local
snapshot drifting from the live site.
Env var | Default | Purpose |
|
| Point at a staging mirror instead |
|
| How long a cached fetch is served before refreshing |
Read-only by construction. There are no write tools, no filesystem writes and no
network calls other than the GET requests above. Data is fetched, held in memory, and
never mutated — locally or remotely. The server has no code path that could alter the
site, so it cannot be talked into doing so.
stdio, not HTTP. A hosted HTTP/SSE endpoint would make the corpus reachable by
remote agents, but it also means another public service to patch and rate-limit. stdio
gives the same query capability with no attack surface and no operational burden.
handle(name, args) is exported and transport-agnostic if a hosted endpoint is ever
wanted — wrap it, don't rewrite it.
No SDK. The MCP subset actually needed here — initialize, tools/list,
tools/call — is implemented directly against the JSON-RPC 2.0 spec, so the repo has
zero runtime dependencies beyond Node's own fetch.
The code in this repository is MIT-licensed (see LICENSE). The corpus it queries — anonym.community's pain points, structural drivers, jurisdictions, FAQ and paper citations — is published separately under CC-BY-4.0 by curta.solutions. Attribute the source when citing results.
anonym.community — the research site this server queries
anonym.community/faq.html — the FAQ corpus, browsable
anonym.community/dpa-directory.html — the jurisdiction directory, browsable
anonym.community/chatbot/manifest.json — index into the same data pre-packaged as static JSON for offline/bulk use (the bare /chatbot/ directory itself isn't served — start from the manifest, or /chatbot/combined/full-corpus.json for everything in one file)
anonym.community/llms.txt — a machine-readable site index for AI crawlers
curta.solutions — the PII-anonymization ecosystem this research supports: anonymize.solutions, cloak.business, anonym.legal, anonym.plus
The product most directly related to this repo. anonym.legal is a cloud/desktop PII anonymization platform (267+ entity types, 48 languages, Zero-Knowledge architecture) built on the same research this corpus documents — and it ships its own MCP server (7 tools for Claude Desktop and Cursor) for actually anonymizing data, as distinct from this repo, which only lets an agent read the research about why anonymization matters. If a query against this corpus surfaces a pain point your own data has, anonym.legal is the tool built to act on it.
Found a data problem, a broken query, or a gap in what's exposed? Open an issue — corrections to the underlying corpus itself go through anonym.community/contact.html instead, since this repo only serves what that site publishes.
MIT © George Curta / curta.solutions
Return counts, available filter values (tracks, regions), and data freshness for this corpus. Call this first to discover valid track and region values for the other tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the tool's read-only nature (returning counts and values) and adds useful context like 'data freshness.' It could explicitly state 'read-only' or mention absence of side effects, but the implied safe discovery purpose is fairly transparent for a zero-parameter stats tool.
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 two sentences, tightly focused, and front-loaded with the core action. The second sentence adds essential usage guidance without redundancy. Every word earns its place.
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, parameterless tool with no output schema, the description is quite complete: it lists the main output categories (counts, filter values, data freshness) and explains its role relative to other tools. It could elaborate on data structure or format, but given the minimal complexity, this is sufficient.
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 tool has zero parameters, and schema coverage is trivially 100%. Per the baseline for 0 params, the description adds no parameter-specific detail but also doesn't need to. It correctly focuses on the tool's output, which serves the discovery purpose.
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 returns counts, available filter values (tracks, regions), and data freshness for the corpus. This specific verb+resource phrasing ("Return counts...") distinguishes it from sibling search tools, making its purpose unambiguous.
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 explicitly instructs to call this tool 'first' to discover valid track and region values for other tools, providing clear when-to-use guidance. It implicitly excludes use for direct search/lookup since its role is discovery, which differentiates it from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List or search the 98 structural drivers — the irreducible root causes that generate the pain points. Breaking one driver weakens many pain points at once, so these are the right unit for "why does this keep happening" and "what should we actually fix" questions.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results, 1-50 (default 20). | |
| query | No | Optional free-text filter over driver name and definition. | |
| track | No | Optional research track filter. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It adds useful context about the domain (98 drivers, root causes, breaking one weakens many pain points) but does not disclose operational behaviors such as read-only nature, return format, pagination, or any side effects. The 'list or search' wording implies a safe read operation, but it is not explicit.
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 two sentences, front-loaded with the primary action and resource, followed by a concise usage rationale. Every word earns its place—no fluff, redundancy, or irrelevant detail. It is an ideal length for quick agent parsing.
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?
Given the simple list/search tool with no output schema, the description provides strong conceptual context and usage guidance. It explains what the tool does, why it matters, and when to use it. However, it does not describe the return format or result structure, which would be helpful given the absence of an output schema. Still, the overall coverage is solid for the tool's moderate 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?
Schema description coverage is 100%, so the schema already documents all three parameters (limit, query, track) with clear descriptions. The tool description does not add additional meaning about parameter semantics; it focuses on the overall purpose. Baseline of 3 is appropriate because the schema handles parameter explanation.
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 'List or search the 98 structural drivers', which is a specific verb+resource statement. It further explains that drivers are the root causes generating pain points, clearly distinguishing this tool from siblings like search_pain_points or search_faq. The purpose is unambiguous and well-scoped.
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 explicitly states when this tool is appropriate: 'the right unit for 'why does this keep happening' and 'what should we actually fix' questions.' This gives clear context for usage. However, it does not explicitly name alternative tools or when not to use it, so it misses the 'exclusions/alternatives' element.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up privacy-law status for a country or region across 240 jurisdictions: whether it has a data protection authority, what legislation applies, and links. Use for "is there a privacy law in X" and cross-border transfer questions.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results, 1-50 (default 10). | |
| region | No | Optional region filter, e.g. "Europe", "Asia". | |
| country | No | Country name or fragment, e.g. "Brazil", "united". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It clearly indicates a read-only lookup and specifies the returned content (DPA, legislation, links). However, it does not disclose behavioral nuances such as what happens when no jurisdiction matches, whether matching is case-sensitive, or any limitations on the region filter. This is adequate but not rich.
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?
Two sentences, with the first front-loading the core action and scope ('Look up privacy-law status...') and the second giving concrete use cases. No redundant or filler content; every sentence earns its place.
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 lookup tool with optional parameters and no output schema, the description covers the essential aspects: scope (240 jurisdictions), output content (authority, legislation, links), and typical use cases. It lacks details on response format or error handling, but overall it is sufficiently complete for an agent to select and invoke the tool.
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 100% with descriptive parameter explanations (e.g., 'country name or fragment'). The description adds the '240 jurisdictions' context and use cases but does not materially enhance parameter-level meaning beyond what the schema already provides. Baseline 3 applies.
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 uses the specific verb 'look up' and clearly identifies the resource: 'privacy-law status for a country or region across 240 jurisdictions'. It enumerates the output components (data protection authority, legislation, links), which distinguishes it from sibling tools focused on FAQs, pain points, research papers, etc.
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 provides explicit use cases: 'Use for "is there a privacy law in X" and cross-border transfer questions.' This gives clear context for when to choose this tool over siblings, though it does not mention specific alternatives 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 134 evidence-backed privacy questions and answers, each with root cause, real-world example and supporting data points. Use for direct practitioner questions.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results, 1-50 (default 5). | |
| query | Yes | Free-text search over question and answer. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It adds useful context about the content (134 items, evidence-backed, each with root cause/example/data points), but it does not state whether the operation is read-only, how results are ordered, or any limitations. This is adequate for a simple search tool but not rich.
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?
Two concise sentences: the first states the primary action and content scope, the second gives usage guidance. There is no filler or redundancy, and the most important information is front-loaded.
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 tool with 2 parameters, full schema coverage, and no output schema, the description sufficiently explains the content scope (134 items, evidence-backed) and expected item composition (root cause, example, data points). It falls short of 5 only because it doesn't explicitly describe the return format or edge-case behavior like empty results, but this is minor for a search tool.
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 describes both parameters ('query' and 'limit') with clear descriptions, achieving 100% coverage. The tool description does not add any parameter-specific semantics, so the baseline score of 3 applies.
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 specific verb ('Search') and identifies the exact resource ('134 evidence-backed privacy questions and answers'). It also outlines the content structure (root cause, real-world example, supporting data points), which distinguishes it from siblings like search_research_papers and search_pain_points.
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 final sentence, 'Use for direct practitioner questions,' gives a clear when-to-use context. However, it does not explicitly mention alternative tools or when not to use this tool, so it falls short of the explicit 'when/when-not/alternatives' level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search 1,478 documented PII/privacy pain points. Each is a concrete, evidenced problem (e.g. re-identification via quasi-identifiers, opt-out futility with data brokers), tagged with research track, category and severity. Use for "what goes wrong with X" questions.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results, 1-50 (default 10). | |
| query | Yes | Free-text search over title, description and evidence. | |
| track | No | Optional research track filter, e.g. "AI Anonymization", "Data Brokers". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that results are concrete, evidenced problems tagged with research track, category, and severity, providing useful context beyond a generic search tool. It stops short of describing return format or potential limitations, but it is informative.
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 exactly two sentences, front-loaded with the purpose, and includes examples and usage guidance without any filler. Every sentence contributes value.
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 3-parameter search tool with no output schema, the description provides sufficient context: what is searched, how results are structured, and when to use it. Minor gaps like pagination or sorting are non-essential.
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 covers all 3 parameters with descriptions (100% coverage), so the baseline is 3. The description adds general context about the corpus but does not add specific parameter-level semantics beyond what the schema already provides.
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 uses a specific verb ('Search') and identifies a concrete resource ('1,478 documented PII/privacy pain points'), with examples that clearly distinguish it from sibling tools like search_faq or search_research_papers.
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 explicitly states when to use the tool: 'Use for "what goes wrong with X" questions.' This is clear context, but it does not mention alternatives or exclusions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search 1,600+ real academic papers underpinning the research (title, authors, abstract, DOI). Use when a claim needs a citable primary source.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results, 1-50 (default 8). | |
| query | Yes | Free-text search over title and abstract. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It adds context that the papers are 'real' and 'underpinning the research,' and lists searchable fields. However, it doesn't disclose behaviors like result ordering, handling of empty results, or read-only nature beyond what a search implies. Adequate but not rich.
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?
Two concise sentences with no fluff. The first sentence states the action and scope; the second gives usage direction. Information is front-loaded and easy to scan.
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?
Given the tool's simplicity (2 params, 1 required) and full schema coverage, the description provides robust context. It lacks an explicit return structure since no output schema exists, but the mentioned fields make results inferable. Nearly complete for a search tool.
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 covers both parameters (100%). The description adds value by specifying searchable fields 'title, authors, abstract, DOI,' which extends beyond the schema's claim of 'title and abstract.' This clarifies query scope and enriches parameter understanding.
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 'Search 1,600+ real academic papers' with specific fields (title, authors, abstract, DOI), making the action and resource explicit. This distinguishes it from sibling tools like search_faq and search_pain_points, which target different content types.
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?
Provides explicit usage context: 'Use when a claim needs a citable primary source.' This clearly indicates when to select this tool. It does not explicitly mention alternatives or when not to use it, but the context is strong enough to guide selection.
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.
v2.0.0get_corpus_statslist_structural_driverslookup_jurisdictionsearch_faqsearch_pain_pointssearch_research_papersScored across 6 tools
Each tool targets a distinct content type: FAQ entries, pain points, structural drivers, jurisdiction statuses, research papers, and corpus metadata. The search tools are differentiated by their object type, and the descriptions explicitly state when to use each, so there is no overlap.
All tool names follow a consistent verb_noun pattern (e.g., search_faq, search_pain_points, list_structural_drivers, lookup_jurisdiction, search_research_papers, get_corpus_stats). Verbs are action-appropriate and nouns clearly indicate the resource.
With 6 tools, the server is well-scoped for its purpose of accessing a privacy research corpus. Each tool covers a distinct content type or metadata function, and none are redundant.
The server covers discovery and search across all major corpus components (FAQ, pain points, structural drivers, jurisdictions, research papers) plus a stats/metadata tool for valid filters. There are no obvious dead ends, as every tool returns the information needed for its use case.
Agent-native MCP server over the public saagarpatel.dev corpus. Read-only, stateless.
Read-only hosted MCP over CanonicAI's cited Answers corpus on canonicai.com.
Agent-native MCP server over 49M+ US public and government records, privacy-first, always current.
Read-only MCP server exposing a user ORANO library to their own AI agent.