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., "@ComplianceIQ MCP Server generate a privacy policy for my e-commerce store"
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.
Generate professional compliance documents (privacy policies, terms of service, HIPAA policies, employee handbooks, and more) directly from Claude, Cursor, or any MCP-compatible AI tool.
Add to your claude_desktop_config.json:
{
"mcpServers": {
"complianceiq": {
"command": "npx",
"args": ["complianceiq-mcp"],
"env": {
"COMPLIANCEIQ_API_KEY": "your_api_key_here"
}
}
}
}Variable | Required | Description |
| No (2 free docs/day) | API key from complianceiq.site |
| No | Custom API URL (default: |
Related MCP server: mcp-shiplegal
generate_documentGenerate a compliance document tailored to your industry.
export_documentExport to PDF or DOCX.
list_document_typesList all 12 document types with descriptions.
Website: complianceiq.site
Pricing: complianceiq.site/pricing
Export a compliance document to PDF or DOCX format. Provide the document content (Markdown) from generate_document.
| Name | Required | Description | Default |
|---|---|---|---|
| format | Yes | Export format: pdf or docx. | |
| content | Yes | Document content in Markdown (from generate_document output). | |
| docType | Yes | Document type identifier (e.g. privacy, terms, handbook). | |
| companyName | Yes | Company name for the document header. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It only states the export action and input source, but does not disclose what the tool returns (e.g., file download, base64, URL), any side effects, permissions, or failure modes. This is a significant gap for a tool with no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core purpose and then provides one crucial instruction. No filler words or redundant information; 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?
Given the tool's simplicity (4 required parameters, no output schema, no annotations), the description covers the core functionality and input source but omits details about the response/return value and post-export behavior. This leaves the agent uncertain about what to do after invoking 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%, providing clear parameter descriptions. The description adds value by specifying that 'content' should be the Markdown output from generate_document, which clarifies the expected composition and origin beyond the schema's generic 'Document content in Markdown'.
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 ('Export a compliance document') and the resource ('compliance document') with specific output formats ('PDF or DOCX format'). It distinguishes from siblings: generate_document creates documents, list_document_types lists them, while export_document exports them.
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 provides clear usage context by specifying that the content must come from generate_document, which implies a workflow ordering. However, it does not explicitly state when not to use the tool or name alternative tools, leaving some inference needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a professional compliance document (privacy policy, terms of service, employee handbook, HIPAA policy, etc.) tailored to your industry and company. Returns complete, ready-to-use Markdown.
| Name | Required | Description | Default |
|---|---|---|---|
| docType | Yes | Document type: privacy, terms, handbook, data-handling, aup, security, cookie, incident, hipaa, osha, whistleblower, remote-work | |
| industry | Yes | Your industry for regulatory tailoring. | |
| companyDesc | No | Brief company description for more specific language. | |
| companyName | Yes | Your company or organization name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the return format ('complete, ready-to-use Markdown') and the tailoring behavior ('tailored to your industry and company'). This goes beyond the schema and gives the agent a clear expectation of the output. However, it does not mention potential limitations or the need for legal review, which would be useful but not strictly required.
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 and resource, and contains zero waste. Every phrase earns its place: what it generates, examples, tailoring, and output format.
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 a straightforward generator with a well-structured schema and no output schema required. The description explains the return format and purpose, making the tool complete for invocation. It does not explicitly state that there are 12 doc types or mention sibling tools, but this is not essential given the name and schema.
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 fully documents parameters. The description adds minimal parameter context ('tailored to your industry and company' implicitly references industry and companyName), but it does not explain docType options or companyDesc beyond what the schema enumerations and descriptions already provide.
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 ('Generate') tied to a clear resource ('professional compliance document') and lists concrete examples (privacy policy, terms of service, employee handbook, HIPAA policy). It clearly differentiates from siblings: 'export_document' exports existing documents and 'list_document_types' lists types, while this tool creates a new document.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly conveys when to use this tool (when you need a new compliance document tailored to your industry and company), but it does not explicitly mention alternative tools or exclusions. The context is clear enough that an agent can infer this is for generating, not exporting or listing, but it stops short of naming siblings for contrast.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available compliance document types with descriptions, organized by category.
| 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 full burden. It discloses that the tool lists types and organizes by category, but does not explicitly state read-only behavior, permissions, or whether results are filtered by user access. Since it's a listing operation, some safety is implied, but additional clarity would improve the score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that immediately states the action, resource, and organization. Every word adds value, with no redundancy or filler.
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 (no parameters, no output schema), the description sufficiently covers its purpose, the fact that descriptions are included, and the categorical organization. It could mention whether the list is paginated or if there are access restrictions, but for a basic listing tool this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty (0 parameters), so there are no parameter semantics to describe. The baseline for 0 params is 4, and the description adds no param-related meaning, which is appropriate for this simple tool.
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 ('List') and resource ('compliance document types'), with clear scope ('all available') and organization ('by category'). It distinguishes from siblings 'generate_document' and 'export_document' by being a read-only listing operation.
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 (list document types when needed) but does not explicitly state when to use this tool over alternatives, nor does it mention any exclusions or prerequisites. Sibling tools are not referenced, so differentiation is indirect.
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.
v0.1.0export_documentgenerate_documentlist_document_typesScored across 3 tools
Each tool serves a distinct role: listing document types, generating content, and exporting to file formats. No overlap in functionality, making tool selection unambiguous.
All tool names follow the verb_noun pattern consistently: generate_document, export_document, and list_document_types. This creates a predictable and coherent naming scheme.
With only 3 tools, the set is well-scoped for a focused compliance document generator. Each tool earns its place, covering the essential workflow without unnecessary bloat.
The tool set covers the full lifecycle: discover available document types, generate a document, and export it to a desired format. No obvious gaps exist for the intended purpose.
Compliant legal documents from your AI assistant: 1,100+ templates, 15 countries, free preview.
One-step legal compliance for vibe-coded apps: privacy, terms, cookie banner and EU AI Act check.
AI legal compliance: contract review, risk scoring, EU/CN AI act, watermark check. 8 MCP tools.
Create real Word .docx files from your AI chat: proposals, quotes, contracts, statements of work.
