Free hosted MCP server for Canadian privacy law: Quebec Law 25 readiness, enforcement actions, and a 263-term privacy glossary.
Scored across 5 tools
Every tool has a clearly distinct purpose: searching enforcement actions, retrieving a specific case, listing glossary terms, looking up a glossary term, and getting Law 25 requirements. There is no overlap or ambiguity between actions.
Most tools follow the privacy_verb_noun pattern (get, list, lookup, search), but privacy_law25_requirements breaks the pattern by using a noun phrase without a verb. This is a minor deviation from an otherwise consistent convention.
With 5 tools, the server is well-scoped for its Canadian privacy domain. Each tool serves a distinct, necessary function, and the count is within the ideal range for a specialized API.
The tool set covers the core workflows: searching enforcement actions, retrieving case details, browsing glossary terms, looking up definitions, and getting Law 25 compliance requirements. A minor gap is that there is no direct tool for listing all cases by company or filtering by specific regulator, but the search tool predominantly handles these needs.
Get the full record of one privacy enforcement action by its ID, including the plain-language summary, outcome, penalty amount, and the official regulator source link. Use this after privacy_search_enforcement_actions when you need complete details on a specific case, or when a case ID (like 'cai-2026-05-06-openai') is already known.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The case ID from a search result. |
| Name | Required | Description |
|---|---|---|
| case | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only, idempotent, non-destructive nature, so the description adds value by disclosing what the returned record includes (summary, outcome, penalty, source link) and that it returns an 'official regulator source link'. This goes beyond the annotations without contradicting them.
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, zero filler. The first sentence front-loads the purpose and contents; the second provides usage guidance. Every word earns its place, and the structure is immediately scannable.
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 single-parameter, read-only tool with an output schema, the description is fully sufficient. It states what the tool returns, when to use it, and how to obtain the ID. No critical information is missing for an agent to invoke it correctly.
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% and the schema already documents the 'id' parameter with a description ('The case ID from a search result') and an example. The description reinforces the ID source and provides an inline example, but it does not add meaning beyond what the schema already provides, so the baseline 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 states a specific verb ('Get'), a precise resource ('full record of one privacy enforcement action'), and lists the key returned fields (summary, outcome, penalty, source link). It also differentiates from the sibling search tool by clarifying it operates on a known ID, so an agent can distinguish it without opening the schema.
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 second sentence explicitly instructs when to use this tool: 'after privacy_search_enforcement_actions when you need complete details on a specific case, or when a case ID is already known.' This names the alternative and the selection condition, leaving no ambiguity about when to pick this over the search sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the Quebec Law 25 compliance checklist: the concrete requirements organizations must meet, covering the privacy officer, purposes, consent, individual rights, retention, cross-border transfers, breach notification, minors' data, automated decisions, and complaint paths. Use this when someone asks what Law 25 requires, how to comply with Law 25, or for a gap-assessment checklist. Optionally filter to one category like 'Consent' or 'Incident response'.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Only requirements in this category. Omit for the full checklist. |
| Name | Required | Description |
|---|---|---|
| categories | Yes | All available categories for the 'category' filter. |
| total_count | Yes | Number of requirements returned. |
| requirements | Yes | Law 25 requirements. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the bar is lower. The description adds behavioral context about the checklist's scope and optional category filtering. It does not contradict any annotation, and the output schema covers the return shape.
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 front-loaded with the core purpose, then provides content scope, usage context, and filtering behavior in a compact set of sentences. Every sentence earns its place without fluff or redundancy.
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 a single optional parameter, complete schema documentation, an output schema, and rich annotations, the description covers everything an agent needs: what the tool returns, when to use it, and how to narrow results. Nothing important is missing.
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%, and the parameter description already states 'Only requirements in this category. Omit for the full checklist.' The tool description repeats this optionality and gives examples from the enum, but it does not add meaning 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 states a specific verb ('Get') and resource ('Quebec Law 25 compliance checklist') and enumerates the concrete content areas. It clearly distinguishes this from sibling tools like privacy_get_enforcement_case, privacy_lookup_glossary_term, and privacy_search_enforcement_actions.
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 says when to use the tool: when someone asks what Law 25 requires, how to comply, or for a gap-assessment checklist. It does not explicitly name alternatives or exclusions, so it stops 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.
Browse the 260+ term Canadian privacy glossary with optional text search or first-letter filtering. Use this to explore which terms exist, find the right slug for privacy_lookup_glossary_term, or gather definitions on a topic. Results are paginated: follow next_offset while has_more is true.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum terms to return in this call. | |
| query | No | Search term names and definitions. | |
| offset | No | Number of matching terms to skip. Use next_offset to page forward. | |
| starts_with | No | Only terms whose slug starts with this letter. |
| Name | Required | Description |
|---|---|---|
| terms | Yes | Matching glossary terms. |
| has_more | Yes | True when more results exist beyond this page. |
| truncated | Yes | True when results were shortened to fit the 50 KB output cap. Use the paginated REST API for the full set. |
| next_offset | Yes | Pass as 'offset' in the next call to continue paging. Null when has_more is false. |
| total_count | Yes | Total number of matches across all pages. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnlyHint, idempotentHint, destructiveHint), so the description's burden is lower. It adds substantive pagination behavior: 'follow next_offset while has_more is true,' which is a useful operational instruction beyond what annotations provide. It does not contradict annotations.
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?
Three sentences with zero repetition or filler. The first sentence states purpose and scope, the second gives use cases, and the third delivers the key pagination rule. Information is front-loaded and each 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 read-only browse tool with an output schema present and thorough annotations, this description is complete. It covers what the tool does, when to use it, and the critical pagination protocol. The presence of an output schema means return-value details are already structured, and no missing context prevents an agent from invoking it correctly.
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 baseline is 3. The description only summarizes the schema's existing search/filter behavior ('optional text search or first-letter filtering') without adding new parameter-level semantics. It gives no extra guidance on limits, offsets, or patterns beyond what the schema already describes.
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 and resource: 'Browse the 260+ term Canadian privacy glossary' and immediately distinguishes it from siblings by stating it is for exploring terms and finding slugs for privacy_lookup_glossary_term. It also mentions optional search/filter scoping, making the tool's role 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?
Explicitly tells agents when to use this tool: 'explore which terms exist, find the right slug for privacy_lookup_glossary_term, or gather definitions on a topic.' It names the sibling it feeds and implies the alternative (direct slug lookup), giving clear usage context with no guesswork.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up the plain-language definition of a privacy or data-protection term, from 'Law 25' and 'PIPEDA' to 'privacy officer', 'data breach', and AI governance concepts. Use this whenever someone asks what a term means, or when you need a precise definition before answering a Canadian privacy question. Terms are identified by slug (for example 'law-25'); use privacy_list_glossary_terms to discover slugs.
| Name | Required | Description | Default |
|---|---|---|---|
| term | Yes | The glossary slug. |
| Name | Required | Description |
|---|---|---|
| term | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds no extra behavioral detail such as error behavior or data source limitations, which is acceptable for a simple read-only lookup but does not add value beyond the annotations.
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?
Three sentences with no wasted words: purpose, usage context, and parameter guidance are each front-loaded in their own sentence. Every sentence earns its place and the structure is 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?
For a single-parameter read-only lookup with an output schema and strong annotations, the description fully covers what the tool does, when to use it, and how to supply the parameter. Nothing necessary for correct invocation is missing.
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%, so the schema already documents the 'term' parameter with a description and examples. The description adds helpful context by explaining that terms are identified by slug and pointing to privacy_list_glossary_terms as the discovery path, which helps the agent supply a valid value.
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 and resource: 'Look up the plain-language definition of a privacy or data-protection term.' It gives concrete examples of term kinds and distinguishes itself from sibling tools by framing its scope as glossary definitions rather than enforcement cases or law requirements.
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?
It explicitly states when to use the tool: 'whenever someone asks what a term means, or when you need a precise definition before answering a Canadian privacy question.' It also routes the agent to a sibling, privacy_list_glossary_terms, for discovering slugs, though it does not explicitly state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search verified Canadian privacy enforcement actions: CAI orders and decisions under Quebec Law 25 and OPC findings under PIPEDA. Use this when someone asks about privacy fines, enforcement cases against a company, what regulators decided, or investigations (for example 'Has the CAI fined anyone for facial recognition?' or 'TikTok privacy investigation Canada'). Returns matching cases with dates, plain-language summaries, penalties, and links to the official regulator source. Start here to find a case ID, then call privacy_get_enforcement_case for full details.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | Filter by decision year. | |
| limit | No | Maximum cases to return in this call. | |
| query | No | Free-text search over case titles and summaries. | |
| offset | No | Number of matching cases to skip. Use next_offset from the previous response to page forward. | |
| regulator | No | Limit to one regulator: 'cai' (Quebec Commission d'acces a l'information, Law 25) or 'opc' (federal Office of the Privacy Commissioner, PIPEDA). |
| Name | Required | Description |
|---|---|---|
| results | Yes | Matching enforcement actions. |
| has_more | Yes | True when more results exist beyond this page. |
| truncated | Yes | True when results were shortened to fit the 50 KB output cap. Use the paginated REST API for the full set. |
| next_offset | Yes | Pass as 'offset' in the next call to continue paging. Null when has_more is false. |
| total_count | Yes | Total number of matches across all pages. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare safe, idempotent, read-only behavior. The description adds value by describing the output contents ('dates, plain-language summaries, penalties, and links to the official regulator source') and notes cases are 'verified', giving the agent confidence in result trustworthiness. It does not contradict annotations.
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?
Four sentences, each earning its place: purpose, when-to-use, output summary, and next-step routing. The most important information is front-loaded and there is zero filler or redundancy.
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 output schema exists, the description covers everything an agent needs: what the tool does, when to use it, what it returns, and how to proceed for full details. No gaps in context or decision-making.
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% and every parameter has a clear description with examples, so the baseline is 3. The description adds domain context (Law 25 vs PIPEDA, regulators) that helps interpret the query/regulator params, but it doesn't add syntax or format details 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 states a specific verb ('Search'), a resource ('verified Canadian privacy enforcement actions'), and scope ('CAI orders and decisions under Quebec Law 25 and OPC findings under PIPEDA'). It clearly distinguishes from the sibling tool by naming privacy_get_enforcement_case and explaining the division of labor ('Start here to find a case ID, then call...').
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?
It gives explicit when-to-use guidance: 'Use this when someone asks about privacy fines, enforcement cases against a company, what regulators decided, or investigations' with concrete example queries. It also tells the agent the next step (get full details via sibling), so routing is unambiguous.
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.
privacy_get_enforcement_caseprivacy_law25_requirementsprivacy_list_glossary_termsprivacy_lookup_glossary_termprivacy_search_enforcement_actions
Add one secure layer between your agents and this server.