Skip to main content
Glama
Ansvar-Systems

Portuguese Cybersecurity MCP

by Ansvar-Systems
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
TypeScript
Hybrid

Portuguese Cybersecurity MCP

The Portuguese cybersecurity corpus is now served through the Ansvar Gateway. Connect your AI assistant (Claude, Copilot, Cursor, custom MCP client) to https://gateway.ansvar.eu/mcp — one OAuth connection, free tier available, covering this corpus plus EU regulations, national law across dozens of audited jurisdictions (Europe + the US), and CVE/security intelligence, every result with a verbatim source citation. Start at https://ansvar.eu/docs/quickstart

Connect

Claude Code (one line):

claude mcp add ansvar --transport http https://gateway.ansvar.eu/mcp

Claude Desktop / Cursor — add to claude_desktop_config.json (or mcp.json):

{
  "mcpServers": {
    "ansvar": {
      "type": "url",
      "url": "https://gateway.ansvar.eu/mcp"
    }
  }
}

Claude.ai — Settings → Connectors → Add custom connector → paste https://gateway.ansvar.eu/mcp

First request opens an OAuth signup flow (setup details: ansvar.eu/docs/quickstart). After signup, your client is bound to your account; tier (free / premium / team / company) determines fan-out, quota, and which downstream MCPs are reachable.

Self-host this MCP

You can also clone this repo and build the corpus yourself. The schema, fetcher, and tool implementations all live here. What is not in the repo is the pre-built database — TDM and standards-licensing constraints on the upstream sources mean we host the corpus on Ansvar infrastructure rather than redistribute it as a public artifact.

Build your own: run this repo's ingestion script (entry-point varies per repo — typically scripts/ingest.sh, npm run ingest, or make ingest; check the repo root).

Portuguese cybersecurity data for AI compliance tools.

License CI

Query Portuguese cybersecurity data -- regulations, decisions, and requirements from CNCS (Centro Nacional de Ciberseguranca) -- directly from Claude, Cursor, or any MCP-compatible client.

Built by Ansvar Systems -- Stockholm, Sweden

Related MCP server: Estonian Cybersecurity MCP

Available Tools (6)

Tool

Description

pt_cyber_search_guidance

Full-text search across CNCS (Centro Nacional de Ciberseguranca) guidelines and technical reports. Covers cybersecuri...

pt_cyber_get_guidance

Get a specific CNCS guidance document by reference (e.g.,

pt_cyber_search_advisories

Search CNCS security advisories and alerts. Returns advisories with severity, affected products, and CVE references w...

pt_cyber_get_advisory

Get a specific CNCS security advisory by reference (e.g.,

pt_cyber_list_frameworks

List all CNCS frameworks and guidance series covered in this MCP, including the Portuguese national cybersecurity str...

pt_cyber_about

Return metadata about this MCP server: version, data source, coverage, and tool list.

All tools return structured data with source references and timestamps.

Data Sources and Freshness

All content is sourced from official Portuguese regulatory publications:

  • CNCS (Centro Nacional de Ciberseguranca) -- Official regulatory authority

Data Currency

  • Database updates are periodic and may lag official publications

  • Freshness checks run via GitHub Actions workflows

  • Last-updated timestamps in tool responses indicate data age

See sources.yml for full provenance metadata.

Security

This project uses multiple layers of automated security scanning:

Scanner

What It Does

Schedule

CodeQL

Static analysis for security vulnerabilities

Weekly + PRs

Semgrep

SAST scanning (OWASP top 10, secrets, TypeScript)

Every push

Gitleaks

Secret detection across git history

Every push

Trivy

CVE scanning on filesystem and npm dependencies

Daily

Docker Security

Container image scanning + SBOM generation

Daily

Socket.dev

Supply chain attack detection

PRs

Dependabot

Automated dependency updates

Weekly

See SECURITY.md for the full policy and vulnerability reporting.

Important Disclaimers

Not Regulatory Advice

THIS TOOL IS NOT REGULATORY OR LEGAL ADVICE

Regulatory data is sourced from official publications by CNCS (Centro Nacional de Ciberseguranca). However:

  • This is a research tool, not a substitute for professional regulatory counsel

  • Verify all references against primary sources before making compliance decisions

  • Coverage may be incomplete -- do not rely solely on this for regulatory research

Before using professionally, read: DISCLAIMER.md | PRIVACY.md

Confidentiality

Queries go through the Claude API. For privileged or confidential matters, use on-premise deployment. See PRIVACY.md for details.

Development

Setup

git clone https://github.com/Ansvar-Systems/portuguese-cybersecurity-mcp
cd portuguese-cybersecurity-mcp
npm install
npm run build
npm test

Running Locally

npm run dev                                       # Start MCP server
npx @anthropic/mcp-inspector node dist/index.js   # Test with MCP Inspector

Data Management

npm run build:db       # Rebuild SQLite database from seed data
npm run check-updates  # Check for new regulatory data

More Ansvar MCPs

Full fleet coverage at ansvar.eu/coverage.

Contributing

Contributions welcome! See CONTRIBUTING.md for guidelines.

License

Apache License 2.0. See LICENSE for details.

Data Licenses

Regulatory data sourced from official government publications. See sources.yml for per-source licensing details.

About Ansvar Systems

We build AI-powered compliance and legal research tools for the European market. Our MCP fleet provides structured, verified regulatory data to AI assistants -- so compliance professionals can work with accurate sources instead of guessing.

ansvar.eu -- Stockholm, Sweden

Available Tools

6 tools
pt_cyber_aboutA

Return metadata about this MCP server: version, data source, coverage, and tool list.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.1/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It discloses return contents but does not mention behavioral traits like idempotency or access requirements. Adequate for a simple info endpoint but minimal.

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?

Single concise sentence with no wasted words. Front-loaded with verb 'Return' and then specifics.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters, no output schema, and simple purpose, the description fully covers what the tool does and what it returns. Complete for this context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist (schema coverage 100%), description adds no param info which is appropriate. Baseline for 0-parameter tools is 4.

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?

Description clearly states the tool returns metadata about the MCP server, listing version, data source, coverage, and tool list. This distinguishes it from siblings that search or retrieve specific guidance/advisories/frameworks.

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?

No explicit guidance on when to use vs alternatives. The context implies use when server metadata is needed, but lacks when-not or alternative references.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

pt_cyber_get_advisoryA

Get a specific CNCS security advisory by reference (e.g., 'CNCS-2024-001').

ParametersJSON Schema
NameRequiredDescriptionDefault
referenceYesCNCS advisory reference

TDQS

A3.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description only states the basic action without disclosing behavioral traits such as what happens if the reference is not found, rate limits, or authentication requirements.

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 extraneous information. Every word contributes to understanding the tool's purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one required parameter, no output schema), the description is complete enough for an agent to understand its function and how to invoke it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema covers 100% of parameters, and the description adds value by providing an example format ('CNCS-2024-001'), clarifying the expected input beyond the schema's generic 'CNCS advisory reference'.

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 verb (Get), resource (CNCS security advisory), and identifier (reference). It also provides an example format, distinguishing it from sibling tools like search_advisories.

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 usage when you have a specific reference, but does not explicitly contrast with sibling tools like pt_cyber_search_advisories or provide when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

pt_cyber_get_guidanceA

Get a specific CNCS guidance document by reference (e.g., 'CNCS-2023-01', 'CNCS-Guia-001').

ParametersJSON Schema
NameRequiredDescriptionDefault
referenceYesCNCS document reference

TDQS

A3.7/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description must cover behavioral traits. It does not mention whether the operation is read-only, what data is returned, or any side effects. For a retrieval tool, missing return format is a gap.

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?

Single sentence, no filler, directly states purpose and input format. Highly concise and front-loaded.

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?

Given the simplicity (1 required param, no output schema), the description is adequate but lacks details on return content or error cases. Could be more complete for a new user.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers 100% of parameters with basic description. The tool's description adds value by providing concrete format examples (e.g., 'CNCS-2023-01'), which clarifies acceptable input beyond the schema.

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 retrieves a specific CNCS guidance document by reference, providing example references. This verb+resource structure distinguishes it from siblings like search_guidance.

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 usage when a specific reference is known but does not explicitly state when to avoid this tool or mention alternatives like search_guidance. No exclusions are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

pt_cyber_list_frameworksA

List all CNCS frameworks and guidance series covered in this MCP, including the Portuguese national cybersecurity strategy and NIS2 implementation framework.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses the listing behavior but does not mention whether it is read-only (implied), rate limits, or any side effects. Adequate but limited.

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, clear sentence with no wasted words. It is appropriately sized for a simple list tool.

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?

For a no-parameter list tool, the description is mostly complete. However, lacking an output schema means the agent must infer the return format. Sibling tools with search/get provide more detail, so this is sufficient context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist so schema coverage is 100%. The description adds value by specifying what is listed (frameworks and guidance series), which is beyond the empty schema.

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 action (list) and resource (CNCS frameworks and guidance series), including specific examples. It distinguishes from sibling tools which are for search/get or about.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies this tool is for obtaining an overview of all frameworks, but does not explicitly state when not to use or mention alternatives. Context is clear but lacks exclusion guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

pt_cyber_search_advisoriesA

Search CNCS security advisories and alerts. Returns advisories with severity, affected products, and CVE references where available.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of results to return. Defaults to 20.
queryYesSearch query in Portuguese or English (e.g., 'vulnerabilidade critica', 'ransomware', 'phishing')
severityNoFilter by severity level. Optional.

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description should disclose behaviors. It mentions return data (severity, products, CVEs) but lacks details on authentication, rate limits, or error cases. It does not contradict annotations (none provided).

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 only two sentences, front-loaded with the action and result. Every sentence is meaningful with no wasted words.

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?

Although no output schema exists, the description covers the main return fields (severity, products, CVE). For a simple search tool, it is fairly complete, but missing details on pagination or empty results.

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 coverage is 100%, so baseline is 3. The description does not add extra meaning beyond the schema; the schema already describes query format and severity filter. No augmented semantics.

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 searches CNCS security advisories and specifies the output includes severity, affected products, and CVE references. It distinguishes from siblings like 'pt_cyber_search_guidance' by focusing on advisories.

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 usage for searching advisories but provides no explicit guidance on when to use this versus siblings like 'pt_cyber_search_guidance' or 'pt_cyber_get_advisory'. No when-not or alternative hints.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

pt_cyber_search_guidanceA

Full-text search across CNCS (Centro Nacional de Ciberseguranca) guidelines and technical reports. Covers cybersecurity guides, NIS2 implementation guidance, RGPD technical measures, and sector-specific recommendations. Returns matching documents with reference, title, series, and summary.

ParametersJSON Schema
NameRequiredDescriptionDefault
typeNoFilter by document type. Optional.
limitNoMaximum number of results to return. Defaults to 20.
queryYesSearch query in Portuguese or English (e.g., 'ciberseguranca', 'NIS2 requisitos', 'gestao de vulnerabilidades', 'encryption')
seriesNoFilter by guidance series. Optional.
statusNoFilter by document status. Defaults to returning all statuses.

TDQS

A4/5.0
Behavior3/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 states the tool returns matching documents with specific fields but does not mention that it is read-only, any pagination behavior, or potential side effects. For a search 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences front-loaded with purpose, followed by coverage and return fields. Every sentence adds value with no redundancy or wasted words.

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 description covers what the tool does and what it returns (reference, title, series, summary). Given the schema richness and lack of output schema, this is largely sufficient. However, it could mention default limit or that query is required (though schema covers that).

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 coverage is 100%, and each parameter is well-described with enums and defaults. The description adds no additional detail beyond the schema, so the baseline score of 3 is appropriate.

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 performs full-text search across CNCS guidelines and technical reports, listing specific content types. The name and description distinguish it from sibling tools like pt_cyber_search_advisories, which searches advisories instead.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for searching guidance documents, and sibling names provide clear differentiation. However, it does not explicitly state when to use this tool versus alternatives like pt_cyber_search_advisories or pt_cyber_get_guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 6 tool updatesv0.1.0
    • First observedpt_cyber_about
    • First observedpt_cyber_get_advisory
    • First observedpt_cyber_get_guidance
    • First observedpt_cyber_list_frameworks
    • First observedpt_cyber_search_advisories
    • First observedpt_cyber_search_guidance
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0

Scored across 6 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: search guidance, get specific guidance, search advisories, get specific advisory, list frameworks, and server metadata. No ambiguity or overlap.

Naming Consistency5/5

All tools follow a consistent 'pt_cyber_verb_noun' pattern using snake_case (search_guidance, get_guidance, search_advisories, get_advisory, list_frameworks, about). The prefix unifies them.

Tool Count5/5

6 tools is well-scoped for a focused domain of Portuguese cybersecurity resources. Each tool serves a specific need without bloat or insufficiency.

Completeness4/5

The tool surface covers search and retrieval of guidance and advisories, plus listing frameworks and server metadata. Minor gaps like direct framework detail retrieval or combined search are absent but not critical for the domain.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers