lgpd-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.3
Disambiguation5/5
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.
Naming Consistency4/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 3.2/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![lgpd-mcp MCP server](https://glama.ai/mcp/servers/LordMendes/lgpd-mcp/badges/card.svg)](https://glama.ai/mcp/servers/LordMendes/lgpd-mcp)

Score Badge

Copy to your README.md:

[![lgpd-mcp MCP server](https://glama.ai/mcp/servers/LordMendes/lgpd-mcp/badges/score.svg)](https://glama.ai/mcp/servers/LordMendes/lgpd-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/LordMendes/lgpd-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server