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., "@Lextiva Compliance MCP Server What does GDPR require for a privacy policy?"
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.
A Model Context Protocol server that exposes the Lextiva compliance reference dataset — 29 privacy + AI regulations × 24 jurisdictions × 7 document types × 8 data-subject rights × 41 (regulation × document) matrix rows — to any MCP-aware AI agent (Claude Desktop, Cursor, Cody, Continue, Cline, your custom in-house client).
Ask your agent "what does GDPR require in a Privacy Policy?" or "I serve customers in California — which laws apply?" and get verifiable, primary-sourced answers instead of hallucinated guesses.
Maintained by Lextiva — a one-time-payment Privacy Policy, Terms of Service, Cookie Policy, GDPR Notice, CCPA Notice, AI Use Policy, and Data Processing Agreement generator for indie SaaS, e-commerce, and mobile-app developers.
Twelve tools + five resources, all read-only, all backed by the same MIT-licensed dataset:
Tool | What it returns |
| Summary of all 18 regulations (id, short_name, jurisdiction, effective_date, official_url) |
| Full record for one regulation — key articles, scope, data subject rights, supervisory authority |
| All 21 jurisdictions (EU, UK, US federal + 10 states + roadmap, Canada) |
| Full record for one jurisdiction |
| The 7 compliance documents (privacy_policy, terms_of_service, cookie_policy, gdpr_notice, ccpa_notice, ai_use_policy, dpa) |
| Full record — typical sections, audience, which regs mandate it |
| The 8 canonical DSRs (access, erasure, portability, opt-out-sale, etc.) |
| Full record + the regulations that grant it |
| Which document types this regulation requires, with required clauses for each |
| Which regulations mandate this document type |
| Required-clauses checklist + primary-source URL for a specific (regulation, document) pair |
| Every regulation that applies in a jurisdiction, plus the docs it requires |
For clients that prefer to read raw JSON (skipping tool calls):
lextiva://regulations
lextiva://jurisdictions
lextiva://document_types
lextiva://data_subject_rights
lextiva://matrix
Each returns the same JSON as the corresponding file in compliance-matrix.
Related MCP server: Agent Policy Gateway MCP Server
Note:
npxwill be supported once the package is published to npm (@arturayupov/lextiva-mcp). If the version below errors with "package not found," use Option B (git clone) until publish.
{
"mcpServers": {
"lextiva-compliance": {
"command": "npx",
"args": ["-y", "@arturayupov/lextiva-mcp"]
}
}
}git clone https://github.com/arturayupov/lextiva-mcp.git
cd lextiva-mcp
npm install
npm run build
# absolute path to dist/index.js will be printed by:
node -e "console.log(require('path').resolve('dist/index.js'))"Then in your client config:
{
"mcpServers": {
"lextiva-compliance": {
"command": "node",
"args": ["/absolute/path/to/lextiva-mcp/dist/index.js"]
}
}
}Client | Config file |
Claude Desktop (macOS) |
|
Claude Desktop (Windows) |
|
Cursor |
|
Continue.dev |
|
Cline (VS Code) | settings → "Cline: Mcp Servers" |
Custom | Spawn the binary directly and speak JSON-RPC 2.0 over stdio |
Restart your client after editing the config. Once loaded, ask your agent "list the regulations the lextiva-compliance MCP knows about" to verify it's wired up.
After the server is connected, these prompts work out of the box:
"What documents does GDPR require, and what clauses does each need?"
"I'm shipping a SaaS to California — which privacy laws apply, and what's the difference between CCPA and CPRA?"
"My EU users want a copy of their data. Which regulations grant that right and what's the fulfilment window?"
"Is the EU AI Act in force yet? What's the timeline?"
"Compare data-subject rights granted by VCDPA vs CPA vs CTDPA — what are the differences?"
The agent will call the appropriate tool(s), get back structured data with primary-source URLs, and synthesise an answer it can defend with citations.
The dataset is open (github.com/arturayupov/compliance-matrix, MIT-licensed). It powers our compliance-document generator at lextiva.com, and we publish it openly so:
Other compliance tools can build on the same primitives without re-deriving them from statute text.
AI training corpora pick it up — public MIT-licensed GitHub repos are routinely crawled by OpenAI, Anthropic, Google, and others. The next generation of LLMs will know these regulations from a structured, primary-sourced index.
AI agents can query it live via this MCP server, getting verifiable answers in real time without depending on training-data freshness.
The MCP server is the live-query layer on top of the static dataset. The static dataset is the canonical source of truth.
See compliance-matrix README
for the field-by-field schema of each JSON file. Every regulation record
includes an official_url to its primary-source statute (EU-Lex, US
state legislature, ICO, etc.). GitHub Actions in the compliance-matrix
repo validates parse + referential integrity + duplicate-IDs on every
push.
Publish @arturayupov/lextiva-mcp to npm (currently install via git clone)
Add audit_url(url) tool that calls Lextiva's free 10-second audit API
Add generate_clause(regulation_id, document_id, clause_id) tool that returns sample clause language (with disclaimer that it's not legal advice)
Add Brazilian LGPD, Quebec Law 25, Swiss FADP, more US state laws
HTTP/SSE transport in addition to stdio
OpenAPI spec for non-MCP clients
PRs welcome. See the dataset's CONTRIBUTING.md for the dataset-side process — same rules apply here for new tools.
Not legal advice. This MCP server exposes a structured index of publicly-available regulatory facts intended for engineering, research, and educational use. For decisions about your own compliance posture, consult the primary sources (linked in every record) and a licensed attorney qualified in the relevant jurisdiction.
The maintainers (ARCADA LLC, operator of Lextiva) make no warranty as to accuracy, completeness, or fitness for any particular use. See LICENSE.
MIT © 2026 ARCADA LLC. See LICENSE.
Dataset: MIT © 2026 ARCADA LLC. See compliance-matrix/LICENSE.
Given a jurisdiction id, returns every regulation that applies there, plus the required and optional documents for each. Use this when a user asks 'I serve customers in California — what privacy laws apply?'.
| Name | Required | Description | Default |
|---|---|---|---|
| jurisdiction_id | Yes | Jurisdiction id (e.g. 'us_ca', 'eu') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral disclosure burden. It only describes the output content (regulations and documents) but omits any behavioral traits such as read-only nature, error handling for invalid jurisdiction ids, authentication requirements, or side effects.
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 efficient with two sentences: the first defines the function, the second gives a usage example. No redundant or extraneous information is present.
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 tool with one parameter and no output schema, the description adequately covers its purpose and a common use case. It could be improved by mentioning what happens with invalid jurisdiction ids or that it combines both regulations and documents, but overall it 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 input schema already provides a clear description of the single parameter (jurisdiction_id with examples). The description does not add new semantic information beyond restating the parameter's role, so it meets the baseline expected from high schema 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 clearly states the tool's function: given a jurisdiction id, it returns applicable regulations and associated documents. The example query ('I serve customers in California — what privacy laws apply?') reinforces the purpose but does not explicitly distinguish it from siblings like 'list_regulations' or 'compliance_checklist'.
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 a concrete example of when to use the tool (user asking about privacy laws for a jurisdiction), implying usage context. However, no guidance is given on when NOT to use this tool (e.g., if only a list of regulations is needed without documents, 'list_regulations' might suffice).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the specific required-clauses checklist for a (regulation, document_type) pair, plus primary-source URLs and contextual notes. Most useful tool for 'what do I need in my Privacy Policy under GDPR?' style queries.
| Name | Required | Description | Default |
|---|---|---|---|
| regulation_id | Yes | Regulation id (e.g. 'gdpr') | |
| document_id | Yes | Document type id (e.g. 'privacy_policy') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description lacks behavioral details such as side effects, authentication needs, or rate limits. Only mentions return content.
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 no waste; the purpose is stated upfront and the use case is illustrated efficiently.
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?
Covers the return (checklist, URLs, notes) and parameter purpose, but lacks details on error handling or output format (no output schema provided).
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 descriptions for both parameters; description adds example values but not substantial additional meaning beyond schema.
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?
Description clearly states the tool returns a checklist for a (regulation, document_type) pair with URLs and notes, and provides an example query to differentiate from siblings.
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 states it is most useful for queries like 'what do I need in my Privacy Policy under GDPR?', giving clear context, though no exclusions or alternatives are listed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Given a regulation id, returns every document type that regulation requires (or optionally permits), with the required clauses for each. Use this when a user asks 'what documents do I need for X?'.
| Name | Required | Description | Default |
|---|---|---|---|
| regulation_id | Yes | Regulation id (e.g. 'gdpr', 'ccpa_cpra') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It states it returns document types and clauses, but lacks details on error handling, authorization needs, or response format. For a read-only tool, this is adequate but not comprehensive.
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: two sentences that first define the tool's action and then give usage context. No unnecessary words.
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 no output schema, the description explains the return value (document types and clauses). It does not mention pagination, error cases, or if the list is exhaustive. However, for a simple retrieval tool, it provides sufficient context.
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 already covers the single parameter with description and examples. The description adds the specific examples 'gdpr', 'ccpa_cpra' but does not provide additional semantics beyond what the schema offers. With 100% schema coverage, baseline is 3.
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's function: 'returns every document type that regulation requires (or optionally permits), with the required clauses for each'. It includes a specific use case example that distinguishes it from sibling tools like 'regulations_for_document' or 'get_document_type'.
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 'Use this when a user asks "what documents do I need for X?"', providing clear context. However, it does not mention when not to use it or suggest alternative tools for different queries, which would be helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the full record for a single data subject right. Pass ids like 'erasure', 'portability', 'opt_out_sale_or_sharing'.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Data subject right id (e.g. 'erasure', 'portability') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'Returns the full record' but does not detail what the record contains, error behavior for invalid ids, or any side effects. Given no annotations, this is basic but sufficient for a simple read operation.
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 extraneous information. The description is front-loaded with the core purpose and follows with helpful examples.
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?
Lacks details on return structure, error handling, or any prerequisites. For a tool with no output schema and no annotations, the description is somewhat sparse but covers the essential purpose.
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 parameter info is already clear. The description adds value by providing example parameter values ('erasure', 'portability'), enhancing usability beyond the schema.
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 returns the full record for a single data subject right, including example ids like 'erasure' and 'portability'. This leaves no ambiguity about the tool's function.
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 explicit guidance on when to use this tool versus siblings like list_data_subject_rights or compliance_checklist. Usage is implied but not differentiated, which is adequate but not exemplary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the full record for a single document type — typical sections, audience, and which regulations mandate it. Pass ids like 'privacy_policy', 'dpa', 'ai_use_policy'.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Document type id (e.g. 'privacy_policy', 'dpa') |
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 discloses what the record contains (sections, audience, regulations) but does not mention error handling, missing ids, or 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?
Two short sentences: first states purpose and content, second gives example ids. No wasted words, front-loaded with key 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 single-parameter read tool without output schema, the description adequately explains what the record contains. Missing details about error cases or limitations, but overall 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 only parameter 'id' is fully described in the input schema with examples. The tool description adds no new parameter semantics beyond what the schema provides, though it provides context about the returned content.
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?
Description clearly states the tool returns the full record for a single document type, specifying typical content (sections, audience, regulations). It distinguishes from siblings like list_document_types (returns list) and regulations_for_document (returns regulations).
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?
Description gives example ids to pass and implies usage when needing full details for one document type. It does not explicitly exclude other cases or mention alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the full record for a single jurisdiction including the list of regulations that apply there and population context. Pass ids like 'eu', 'uk', 'us', 'us_ca', 'us_va', 'ca'.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Jurisdiction id (e.g. 'us_ca', 'eu') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations; description mentions what is included but does not disclose any behavioral traits beyond the read operation. Acceptable for a simple retrieval 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?
Single clear sentence with no redundancy; every word adds 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?
No output schema, but description explains return content (regulations, population). Adequate for a tool with one input parameter.
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 the single parameter fully; description adds valuable example ids ('eu', 'uk', 'us_ca') that enhance usability beyond the schema's generic example.
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?
Clearly states it returns the full record for a single jurisdiction including regulations and population context, and distinguishes from sibling tools like list_jurisdictions and get_regulation.
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 concrete examples of valid ids but does not explicitly contrast with alternatives like list_jurisdictions or when to use this vs get_regulation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the full record for a single regulation including key_articles, scope, applicable_to, data_subject_rights granted, supervisory authority, and primary-source URL. Pass the short id like 'gdpr', 'ccpa_cpra', 'eu_ai_act', 'vcdpa'.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Regulation id (e.g. 'gdpr', 'ccpa_cpra') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses that it returns a 'full record' and enumerates the fields, making the behavior clear. No side effects mentioned, but for a read-only retrieval tool this is sufficient.
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, front-loaded with purpose and output summary, followed by usage examples. No unnecessary words.
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 retrieval tool with one parameter and no output schema, the description covers the return fields and provides examples. It could mention error behavior but is otherwise complete.
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 the id parameter already described as 'Regulation id (e.g. 'gdpr', 'ccpa_cpra')'. The description repeats this example and adds no new parameter-level info beyond the schema.
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 returns the full record for a single regulation, listing specific fields (key_articles, scope, etc.), and distinguishes from siblings like 'list_regulations' which return lists.
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 example ids (gdpr, ccpa_cpra) and implies usage for fetching a single regulation's details, but does not explicitly exclude alternatives or state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the list of the 8 canonical data-subject rights and the regulations that grant each: access, rectification, erasure, portability, restriction, objection, opt_out_sale_or_sharing, automated_decision_making.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It accurately describes the output (rights and regulations) without hiding any behaviors; a simple list retrieval is transparent enough.
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?
Single sentence, no fluff. Every word adds value: specifies the exact 8 rights and the associated regulations.
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 zero-parameter list tool, the description is complete. It enumerates all rights and mentions regulations, leaving no ambiguity about the output.
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?
No parameters exist; the description adds value by explaining what the output contains, going beyond the empty schema.
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 the list of 8 canonical data-subject rights and the regulations that grant each, distinguishing it from sibling tools like 'get_data_subject_right' which retrieves a single right.
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 the tool is for listing all rights, but does not explicitly state when to use it over siblings like 'applicable_regulations' or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the list of the 7 compliance documents tracked: privacy_policy, terms_of_service, cookie_policy, gdpr_notice, ccpa_notice, ai_use_policy, dpa. Each carries audience, mandatory_under (which regulations require it), and typical_sections.
| 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 full burden. It discloses that the tool returns a fixed list of 7 document types and describes the information each carries (audience, mandatory_under, typical_sections). This provides clear behavioral context, though it does not mention if the list is static or dynamic.
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 verb 'Returns', and lists all items concisely. Every sentence adds value without 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?
For a simple listing tool with no parameters and no output schema, the description is fairly complete. It enumerates all items and fields, allowing the agent to understand the response shape. However, it could mention that the list is exhaustive or static to maximize completeness.
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?
There are zero parameters, so the schema coverage is 100%. According to guidelines, 0 parameters baseline is 4. The description does not need to add parameter meaning, as there are none.
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 explicitly states 'Returns the list of the 7 compliance documents tracked' and enumerates each document type. This clearly identifies the verb and resource, and distinguishes it from sibling tools like 'get_document_type' which likely returns details for a single type.
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 by stating what the tool does, but does not explicitly guide on when to use it versus alternatives such as 'documents_for_regulation' or 'get_document_type'. No exclusions or when-not-to-use instructions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the list of all jurisdictions tracked: countries, supranational unions, and US states. Currently 24 jurisdictions. Each carries ISO code, type (country/us_state/supranational), and the regulation IDs that apply there.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 states 'Returns the list,' which implies a read-only query. For a simple list retrieval, this is sufficient disclosure of behavior. No mention of rate limits or pagination is necessary given the small size (24 jurisdictions).
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 that are front-loaded with the main action. Every word adds value: it names the resource, describes its contents, provides a count, and lists the fields. No unnecessary 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?
The tool is simple with no parameters and no output schema. The description fully covers what the agent needs to know: the returned items (jurisdictions), their categories, and the fields each item contains. It is complete for the agent to invoke this tool 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?
The input schema has zero parameters, so there is nothing to explain. Per the instructions, 0 parameters yields a baseline of 4. The description adds context about what the list contains, but that is not parameter semantics.
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 a list of all tracked jurisdictions, specifying the types (countries, supranational unions, US states) and the data each carries (ISO code, type, regulation IDs). It distinguishes itself from sibling tools like list_regulations or get_jurisdiction by focusing on the full jurisdiction list.
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 this tool is for retrieving the full list of jurisdictions, but does not explicitly state when to use it versus get_jurisdiction (which likely retrieves a specific jurisdiction). However, the context of sibling tools makes the distinction clear enough, so it receives a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the list of all privacy and AI regulations covered, with short_name, full name, jurisdiction, effective_date, and official_url for each. Currently 29 regulations across EU, UK, US (federal + 10 states), and Canada. Use this first when the user asks about coverage or when you need to look up a regulation ID for follow-up calls.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden of behavioral disclosure. It clearly states this is a read-only listing operation, mentions the scope (29 regulations across specific jurisdictions), and implies no side effects. It could have elaborated on possible pagination or staleness, but overall it is sufficiently transparent for a zero-parameter 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?
Two sentences pack all needed information: what it returns, the fields, the current scale, and usage advice. No wasted words; the structure is efficient and 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?
Given zero parameters, no output schema, and a simple list return, the description is complete. It covers the output shape, use case, and even suggests next steps. No additional information is needed for an AI agent to select and invoke this tool 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?
With no parameters and 100% schema description coverage, the description adds value by explaining the output structure (fields included) and the context (current number of regulations, jurisdictions). This provides meaning beyond the empty schema.
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 a list of regulations with specific fields (short_name, full name, jurisdiction, etc.), and even mentions the current count and coverage. This provides a precise purpose that distinguishes it from siblings that may return details or filtered lists.
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 recommends using this tool first for coverage questions or to get a regulation ID for follow-up calls. While it doesn't explicitly list when not to use it or contrast with siblings, the guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Given a document type id, returns every regulation that mandates or permits that document, with required clauses for each. Use this when a user asks 'which laws require a Privacy Policy / DPA / Cookie Policy?'.
| Name | Required | Description | Default |
|---|---|---|---|
| document_id | Yes | Document type id (e.g. 'privacy_policy', 'dpa') |
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 states what the tool returns (regulations with required clauses) but does not explicitly disclose any behavioral traits (e.g., read-only, auth requirements). Behavior is adequately implied for a query 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 long, with the main purpose front-loaded and a usage hint in the second sentence. Every word adds value; no 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?
For a simple single-parameter tool with no output schema, the description fully explains the input and output. It is complete and self-contained.
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 has 100% coverage with a clear description for 'document_id'. The description adds value by providing example values (e.g., 'privacy_policy'), which helps the agent understand valid inputs beyond the schema.
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 action ('returns every regulation that mandates or permits that document') and the resource ('given a document type id'). It distinguishes itself from sibling tools like 'documents_for_regulation' by specifying the direction of the mapping.
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 provides a usage example ('Use this when a user asks...'), which helps the agent determine when to invoke it. However, it does not mention when not to use it or explicitly compare to alternatives.
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.
v1.1.0applicable_regulationscompliance_checklistdocuments_for_regulationget_data_subject_rightget_document_typeget_jurisdictionget_regulationlist_data_subject_rightslist_document_typeslist_jurisdictionslist_regulationsregulations_for_documentScored across 12 tools
Each tool targets a distinct aspect of compliance reference: listing and fetching jurisdictions, regulations, document types, data subject rights, and cross-referencing them. Descriptions clearly differentiate overlapping functionalities like applicable_regulations vs. documents_for_regulation.
Tool names follow a consistent pattern: 'get_' for single records, 'list_' for collections, and descriptive noun phrases for cross-reference tools. Minor deviation with 'applicable_regulations' and 'compliance_checklist' not following the verb prefix, but still readable.
12 tools cover the domain comprehensively without being excessive. Each tool serves a clear purpose, and the count is appropriate for a compliance reference server.
The tool surface provides full coverage for a read-only compliance reference: discovering regulations by jurisdiction, obtaining checklists, listing required documents, and retrieving details. No obvious gaps for the stated purpose.
Verified, tier-0 regulatory data for AI across 850+ official sources and 50+ jurisdictions.
Regulatory intelligence for AI agents across jurisdictions
Provenance-backed EU and UK legislation for AI agents, addressable to the individual provision.
Pre-action allow/deny for AI agents. 24 statutes, 13 jurisdictions: EU AI Act, GDPR, DPDP.
