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., "@lgpd-mcp Validar base legal para processamento de dados de marketing."
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.
Servidor MCP (Model Context Protocol) para auxiliar organizações e desenvolvedores na conformidade com a Lei Geral de Proteção de Dados Pessoais (LGPD - Lei 13.709/2018).
9 ferramentas para validação de bases legais, consentimento, modelos de documentos, PIA, checklist, políticas, direitos do titular, mapeamento de dados sensíveis e avaliação de risco
5 recursos de referência: fundamentos, artigos, bases legais, glossário e ANPD
4 prompts para revisão de política, resposta ao titular, avaliação de cenário e documentação
Related MCP server: ComplianceIQ MCP Server
Node.js 18+
pnpm, npm ou yarn
npx @lordmendes/lgpd-mcpOu instale globalmente:
npm install -g @lordmendes/lgpd-mcp
lgpd-mcpgit clone https://github.com/LordMendes/lgpd-mcp.git
cd lgpd-mcp
# Instale as dependências
pnpm install
# ou: npm install
# ou: yarn install
# Compile o projeto (obrigatório para produção)
pnpm buildO servidor é executado via stdio e espera conexões de clientes MCP (Cursor, Claude Desktop, etc.):
# Se instalado via npm
npx @lordmendes/lgpd-mcp
# Desenvolvimento local
npx tsx src/index.tsPara execução como servidor HTTP (uso remoto):
pnpm start:http
# ou: npx tsx src/http.tsO servidor HTTP escuta na porta definida por MCP_PORT (padrão: 3000). Endpoint: POST /mcp. Consulte docs/HTTP.md para detalhes de integração.
pnpm test:mcp
# ou: npx @modelcontextprotocol/inspector npx tsx src/index.tsVeja docs/CURSOR.md para instruções detalhadas de configuração no Cursor.
Veja docs/CLAUDE_DESKTOP.md para instruções de configuração no Claude Desktop.
Variável | Descrição | Padrão |
| Porta do servidor HTTP (modo remoto) | 3000 |
Consulte .env.example para referência.
Publicação (Publishing) — como publicar no npm e MCP Registry
Ferramentas (Tools) — descrição de cada tool
Recursos (Resources) — descrição de cada resource
Prompts — descrição de cada prompt
Configuração Cursor — instruções para Cursor
Configuração Claude Desktop — instruções para Claude Desktop
Transporte HTTP — uso remoto via HTTP
Aviso Legal — não substitui assessoria jurídica
Segurança — práticas de segurança do projeto
Script | Descrição |
| Executa o servidor em modo desenvolvimento |
| Executa o servidor compilado |
| Compila TypeScript |
| Executa testes unitários |
| Verifica código com ESLint |
| Formata código com Prettier |
Todas as ferramentas são auxiliares e não substituem assessoria jurídica especializada. Consulte sempre um advogado ou consultor em proteção de dados para decisões jurídicas. Para orientações oficiais, acesse a ANPD.
MIT
Indica se o tratamento exige Relatório de Impacto (PIA/RIPD) conforme Art. 38 da LGPD
| Name | Required | Description | Default |
|---|---|---|---|
| criterios | Yes | ||
| descricao_processamento | No | Breve descrição do processamento para contexto |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior, but it only says 'indicates if' without explaining the evaluation logic, output format, or whether this is a definitive determination. The agent is left unaware of how the criteria are combined or what kind of result to expect.
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, front-loaded sentence with no redundant words. Every part contributes meaning: the action ('indica se'), the subject ('tratamento'), the specific report (PIA/RIPD), and the legal basis (Art. 38 LGPD).
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 complexity (a nested object with six boolean criteria), the absence of annotations and output schema, and a sparse description, the agent lacks essential information about how to interpret the result and how the criteria are evaluated. The description alone is not enough to use the tool confidently.
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 50% at the top level, and the description adds no parameter-level meaning. Although the nested boolean criteria have descriptions in the schema, the description does not help map the legal requirements to the 'criterios' object or explain how 'descricao_processamento' contributes.
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: it indicates whether data processing requires a PIA/RIPD report under Article 38 of LGPD. This specific legal reference and the PIA/RIPD focus distinguish it from sibling tools like avaliar_risco_tratamento or validar_base_legal.
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 legal context (Art. 38 LGPD) and implies the tool is for determining PIA necessity, but it does not explicitly state when to use it versus alternatives, nor does it mention exclusions or prerequisites. Usage guidance is therefore only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Avaliação simplificada de risco de um tratamento de dados pessoais
| Name | Required | Description | Default |
|---|---|---|---|
| descricao | Yes | Descrição do tratamento de dados a ser avaliado | |
| respostas | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for disclosing behavioral traits. It only states that it is a 'simplified risk assessment,' without any information about side effects, required permissions, output format, or state changes. This is insufficient for an agent to anticipate the tool's behavior safely.
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 directly states the function without any extraneous detail. It is optimally concise and front-loaded, containing no redundant or vague phrases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, no annotations, and a non-trivial input structure. The description only provides a high-level purpose and fails to explain what the risk assessment returns, how results are presented, or any practical usage notes. This leaves a significant gap for the agent to understand the full context of 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?
The tool description adds no information about the parameters (descricao and respostas). With only 50% schema description coverage, the description was expected to compensate, but it remains silent. The nested 'respostas' object is partially self-explanatory through its subfields, but the description does not clarify the overall input structure 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 'Avaliação simplificada de risco de um tratamento de dados pessoais' clearly states the tool's function: assessing the risk of personal data processing. It uses a specific verb ('avaliar') and resource ('tratamento de dados pessoais'), making the purpose unambiguous. However, it does not explicitly differentiate this from sibling tools such as 'avaliar_necessidade_pia' or 'checklist_compliance', so it does not achieve the top score.
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 no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or comparative scenarios. Without this context, an agent cannot determine when this risk assessment is appropriate relative to other compliance tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gera checklist de conformidade LGPD para um cenário específico
| Name | Required | Description | Default |
|---|---|---|---|
| ambito | No | Âmbito do tratamento (comercial, saúde, educação, governo, geral) | |
| cenario | Yes | Breve descrição do cenário ou processo a ser avaliado |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must convey behavioral traits. It only says 'Gera' (generates), which implies a read-only operation, but does not disclose permissions, reversibility, or output format. This leaves the agent uncertain about side effects or result structure.
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 starts with the action verb 'Gera', making the tool's purpose immediately clear. There is no redundant information or overly long explanation. It is perfectly sized for the tool's simplicity.
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 parameter coverage and lack of output schema, the description sufficiently conveys the tool's purpose and scenario input. However, it does not explain what the compliance checklist includes or how the 'ambito' option affects the output, which would be helpful for the agent. Still, this is a minor gap for a straightforward generator.
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?
Both parameters ('cenario' and 'ambito') have complete descriptions in the schema, covering 100% of the parameter space. The description's mention of 'cenário específico' aligns with the 'cenario' parameter but adds no new semantic detail. Therefore, the baseline score of 3 is appropriate as the schema does the heavy lifting.
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 'Gera' (generates) and names the resource 'checklist de conformidade LGPD', scoped to 'um cenário específico'. This clearly differentiates it from sibling tools like 'gerar_modelo_consentimento' or 'validar_base_legal', which have distinct outputs. It fully states 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?
The description provides no guidance on when to use this tool versus the other LGPD compliance tools. It simply states that it generates a checklist without mentioning scenarios where it's preferred or exclusions. Sibling tools exist, but no alternatives or distinctions are offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lista e explica os direitos do titular aplicáveis (Arts. 17 e 18 LGPD)
| Name | Required | Description | Default |
|---|---|---|---|
| contexto | No | Contexto em que os direitos são consultados (ex: solicitação de acesso, revogação) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behavioral traits. 'Lista e explica' implies a non-mutating, informational operation, which is a form of transparency. However, it does not explicitly state read-only behavior, confidentiality, or any limitations.
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, front-loaded sentence that directly states the tool's purpose. Every word earns its place with no filler or redundant restatement.
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 one optional parameter and no output schema, so the description is largely sufficient. It names the exact legal articles and the action performed. Minor gaps include lack of usage context or examples, but this does not significantly hinder invocation.
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 provides 100% coverage for the 'contexto' parameter, so the description does not need to add parameter details. The description adds no extra parameter semantics beyond the schema, warranting the baseline score of 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 uses specific verbs 'Lista e explica' (lists and explains) with a clear resource 'direitos do titular' and legal reference (Arts. 17 e 18 LGPD). This clearly differentiates it from sibling tools that handle consent, legal basis, or privacy policies.
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 no guidance on when to use this tool versus alternatives or prerequisites. It merely states what the tool does, leaving the context of use to be inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gera modelo de termo de consentimento conforme LGPD (Art. 8º)
| Name | Required | Description | Default |
|---|---|---|---|
| retencao | No | Prazo ou critério de retenção dos dados | |
| finalidade | Yes | Finalidade do tratamento para a qual o consentimento é solicitado | |
| dados_coletados | No | Lista resumida dos dados coletados (ex: nome, e-mail, CPF) | |
| dados_sensiveis | No | Se o tratamento envolve dados sensíveis | |
| compartilhamento | No | Se haverá compartilhamento de dados com terceiros |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only discloses that the tool 'generates' a consent model, which implies a non-destructive action, but it fails to describe output format, side effects, or any other behavioral traits. The description is too minimal to provide adequate transparency.
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, succinct sentence that front-loads the action (Gera) and resource. There is no redundant or extraneous information, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has five parameters (one required), no output schema, and no annotations. The description does not explain what the generated model looks like, how inputs influence the output, or any important context about the legal basis. This is insufficient for a tool of this 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 each parameter is already documented. The description does not elaborate on parameter semantics, but the LGPD Art. 8 reference adds some contextual meaning by implying the parameters align with legal requirements for consent forms. This meets the baseline but does not exceed it.
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 with a specific verb ('Gera') and resource ('modelo de termo de consentimento'), and adds legal specificity ('conforme LGPD (Art. 8º)'). This distinguishes it from sibling tools like 'gerar_politica_privacidade', which generates a different legal 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 implies the tool is used when a consent term model is needed, but it does not provide explicit usage context, exclusions, or references to alternative tools. No guidance is given on when to prefer this tool over siblings like 'validar_base_legal' or 'verificar_consentimento'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Auxilia na estruturação de política de privacidade conforme LGPD
| Name | Required | Description | Default |
|---|---|---|---|
| retencao | No | Prazo ou critério de retenção dos dados | |
| base_legal | No | Bases legais utilizadas (ex: consentimento, execução de contrato) | |
| contato_dpo | No | Canal de contato do encarregado (DPO) | |
| finalidades | No | Finalidades principais do tratamento (separadas por vírgula) | |
| nome_empresa | Yes | Nome da empresa ou organização | |
| dados_coletados | No | Tipos de dados coletados (ex: nome, e-mail, CPF) | |
| compartilhamento | No | Se e com quem os dados são compartilhados |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden of behavioral disclosure. It only states the tool 'assists in structuring a privacy policy' without revealing any side effects, output format, permissions, or whether it is a read-only operation. This is similar to the mid-tier example where mutation tools lacking behavioral details scored 2.
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 with no fluff, front-loading the key purpose. It is appropriately concise for the information it conveys, though 'Auxilia' could be more direct. There is no wasted wording, earning a strong score for conciseness.
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 has 7 parameters and no output schema or annotations, the description should provide more context about what the tool produces and how it behaves. It only states 'assists in structuring a privacy policy', leaving out details about the generated output, any constraints, or the overall workflow. This is insufficient for a moderately complex 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 description coverage is 100%, so the baseline is 3. The description does not add any parameter-specific meaning beyond what the schema already provides. All seven parameters (e.g., nome_empresa, finalidades, base_legal) are well-described in the schema, so no information is lost, but the description itself contributes no additional semantic 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 clearly identifies the tool as assisting in structuring a privacy policy according to LGPD, which distinguishes it from siblings like gerar_modelo_consentimento or validar_base_legal. The verb 'Auxilia na estruturação' is specific enough, though slightly softer than the title 'Gerar'. Overall, it clearly states the primary 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?
There is no guidance about when to use this tool versus alternatives. The description does not mention any exclusions, prerequisites, or contexts where another sibling tool would be more appropriate. This leaves the agent without clear decision-making information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ajuda a identificar categorias de dados sensíveis conforme Art. 11º LGPD
| Name | Required | Description | Default |
|---|---|---|---|
| contexto | No | Contexto do tratamento para análise | |
| categorias_informadas | No | Categorias de dados que você suspeita serem sensíveis (separadas por vírgula) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that it helps identify categories; it does not disclose whether this is a read-only analysis, what the output looks like, or any prerequisites. The legal reference provides context but not behavioral transparency.
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, concise sentence that front-loads the main purpose. There is no wasted text or redundant 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 relatively simple with two optional parameters and no output schema. The description conveys the core purpose but lacks details about return values or usage context. While not ideal, it is minimally adequate for a tool of this 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?
Both parameters have descriptions in the schema, providing 100% coverage. The description does not add additional parameter context beyond the schema, 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 clearly states the tool's purpose: to help identify categories of sensitive data according to Art. 11 of the LGPD. The verb 'identify' and resource 'categories of sensitive data' are specific, and the legal reference adds scope. It doesn't explicitly contrast with sibling tools, but the purpose is distinct.
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?
There is no explicit guidance on when to use this tool versus alternatives. The usage is implied by the name and description: use it when you need to map or identify sensitive data categories. However, no exclusions or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verifica se uma base legal é adequada para determinado tratamento de dados (Art. 7º e 11º LGPD)
| Name | Required | Description | Default |
|---|---|---|---|
| tipo_dado | Yes | Tipo de dado: 'pessoal' (Art. 7º) ou 'sensivel' (Art. 11º) | |
| base_legal | Yes | Nome ou identificador da base legal utilizada | |
| finalidade | No | Finalidade do tratamento para análise de adequação |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the validation purpose but does not reveal whether the operation is read-only, what output format to expect (e.g., boolean, explanation), or any preconditions like the optional finalidade parameter. This leaves significant behavioral ambiguity.
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 verb and resource, with no filler or redundant information. Every word contributes to the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, so the description must clarify return values and operational context. It does not explain what the tool returns (e.g., a verdict or detailed analysis) or address the optional finalidade parameter's role. Given the 3-parameter complexity, the description is incomplete.
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% for all three parameters, so the schema already provides full parameter semantics. The description adds little beyond referencing LGPD Articles, which aligns with the tipo_dado enum but does not enhance understanding of the parameters themselves.
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 ('Verifica') and clearly identifies the resource ('base legal') and context ('determinado tratamento de dados') with references to LGPD Articles 7 and 11. This distinguishes it from sibling tools like verificar_consentimento or avaliar_necessidade_pia.
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 a clear use case (validating legal basis adequacy) but does not explicitly state when to use this tool over alternatives or provide exclusions. No guidance is given on when not to use it or how it differs from similar validation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Valida se o consentimento atende aos requisitos do Art. 8º da LGPD
| Name | Required | Description | Default |
|---|---|---|---|
| criterios | Yes | ||
| observacoes | No | Observações adicionais sobre o contexto do consentimento |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It merely states the validation purpose but does not explain how validation is performed, what the output looks like, whether the tool is read-only, or what side effects (if any) occur. This is insufficient for the agent to predict the tool's behavior.
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, concise sentence with no unnecessary words. It communicates the core purpose directly, achieving maximum conciseness.
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 involves a nested object with five criteria and an observations field, yet the description gives no detail about the validation logic, expected results, or error conditions. There is no output schema or annotations to complement the gap, making the description inadequate for an agent to properly invoke and interpret 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?
The description does not mention any parameters or criteria. Although the schema includes descriptive property labels, the description adds no semantic meaning beyond the schema itself. Given 50% schema coverage, the description fails to compensate for undocumented aspects or clarify how the criteria relate to the validation.
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 ('Valida') and resource ('consentimento') tied to a legal article (Art. 8º da LGPD), which clearly distinguishes it from sibling tools like 'validar_base_legal' or 'gerar_modelo_consentimento'. However, it does not explicitly contrast itself with these alternatives in the description.
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 its use case via the name and legal reference, but it does not explicitly state when to use this tool versus the sibling compliance tools. There is no 'when-not' guidance or mention of prerequisites, leaving the agent to infer the appropriate context.
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.3avaliar_necessidade_piaavaliar_risco_tratamentochecklist_complianceconsultar_direitos_titulargerar_modelo_consentimentogerar_politica_privacidademapear_dados_sensiveisvalidar_base_legalverificar_consentimentoScored across 9 tools
Each tool targets a distinct aspect of LGPD compliance: consent generation/validation, legal bases, PIA necessity, checklists, privacy policies, data subject rights, sensitive data mapping, and risk assessment. No two tools have overlapping purposes.
Most tools follow a consistent verb_noun pattern in Portuguese (e.g., gerar_modelo_consentimento, validar_base_legal), but 'checklist_compliance' deviates by starting with a noun instead of a verb. This minor inconsistency does not hinder readability.
With 9 tools, the server is well-scoped for an LGPD compliance assistant. Each tool covers a distinct compliance requirement without unnecessary bloat or redundancy.
The toolset covers major LGPD aspects including consent, legal bases, PIA, risk, privacy policy, data subject rights, and sensitive data. Minor gaps exist, such as missing specific tools for DPO appointment or incident response, but the core compliance workflows are well represented.
GDPR/CCPA cookie consent: scan sites for cookies, track consent rates, generate privacy policies.
One-step legal compliance for vibe-coded apps: privacy, terms, cookie banner and EU AI Act check.
Brazilian legal stack in one MCP: lawsuits, court publications, case law, tenders, certificates.
Verificação de segurança e conformidade de sites: cabeçalhos, TLS, DNS, e-mail, LGPD e pentest.