What can you do with this server?

This server provides automated compliance tooling for the NIS2 Directive (EU 2022/2555), helping organizations classify their regulatory status, audit cybersecurity controls, and manage incident reporting obligations. * Classify Entities (classify_entity): Determine whether an organization is an essential entity, important entity, or out-of-scope under NIS2 Article 2, based on sector, employee count, and annual turnover. * List Article 21 Measures (list_article_21_measures): Retrieve all 10 mandatory cybersecurity risk-management measures required under NIS2 Article 21. * Audit Article 21 Controls (audit_article_21): Audit current security controls against NIS2 Article 21's 10 measures, returning per-measure evidence status, identified gaps, and sanction exposure tier. * Classify Incidents (classify_incident): Assess a cyber incident against NIS2 Article 23 thresholds to determine if it is "significant," triggering mandatory reporting timelines (24h early warning, 72h notification, 1-month final report). * Management Body Checklist (management_body_checklist): Generate an Article 20 accountability checklist for directors and management bodies, who can be held personally liable for NIS2 non-compliance. * Generate Compliance Certificate (get_nis2_certificate): Produce a timestamped, signed NIS2 compliance certificate based on entity name and compliance score (Pro/Enterprise tier). * Check Enforcement Status (enforcement_status): Retrieve the current NIS2 enforcement status and national transposition tracker across EU member states.

de en es ja ko ru zh

NIS2 Compliance MCP

by CSOAI-ORG

Overview Schema Related Servers Score Discussions

Python

Remote

🔏 Free tier: 50 calls/day. Need audit-ready proof?
Pro (£199/mo) turns every result into an HMAC-signed attestation with a public verify URL your auditor validates without an account — EU AI Act Art 11/12 ready. → Start: https://proofof.ai · pip install meok-attestation-verify to verify any cert.

MCP Scorecard: 86/100

Nis2 Compliance MCP

MEOK AI Labs PAYG enabled EU AI Act License PyPI

NIS2 (Directive EU 2022/2555) Article 21+23 compliance MCP

NIS2 (Directive EU 2022/2555) Article 21+23 compliance MCP. Entity classification, 10 measures audit, incident reporting. MIT

🚀 Quick Start

# Install via pip
pip install nis2_compliance_mcp

# Or install via Smithery
npx -y @smithery/cli@latest install nis2-compliance-mcp --client claude

Related MCP server: EU AI Act Compliance MCP

⚡ Pay-per-call (PAYG) — no subscription

This MCP supports universal pay-per-call billing across the MEOK compliance fleet:

# One-time setup
export MEOK_PAYG_KEY="your_topup_token"

# Every tool call now deducts £0.05 from your balance.
# When balance hits zero, the tool returns a top-up URL.
# Works across all 7 MEOK compliance MCPs with the same token.

No subscription — top up once, deduct per call.
£0.05/call default (configurable via MEOK_PAYG_RATE_GBP).
USDC on Base L2 accepted — set MEOK_X402_RECEIVER and pay via stablecoin.
Backward-compatible — when MEOK_PAYG_KEY is unset, behaviour is unchanged.

Get a token: councilof.ai/payg (£10 / £50 / £200 top-up tiers).

✨ Features

MCP protocol compliant
Easy installation
Well-documented API
Production-ready
Active maintenance

📖 Documentation

🛡️ Compliance

This MCP server is built with EU AI Act compliance built-in:

✅ Article 9 — Risk Management System
✅ Article 13 — Transparency & Instructions for Use
✅ Article 15 — Bias Detection & Testing
✅ Article 26 — FRIA Support (where applicable)
✅ Article 50 — AI Content Watermarking (where applicable)

Need help getting compliant? Book a free 15-min diagnostic →

🏢 Enterprise

Need custom development, SLA guarantees, or white-label deployment?

Pro: £79/mo — Full MCP suite + EU AI Act tracking
Enterprise: £499/mo — Custom dev + SLA + Dedicated support

View Pricing → | Contact Sales →

🤝 Part of the MEOK Ecosystem

This server is part of the MEOK AI Labs ecosystem — 26 PyPI packages · ~16,300 monthly installs.

Domain	Purpose
councilof.ai	EU AI Act compliance marketplace
safetyof.ai	AI safety & monitoring
meok.ai	Sovereign AI platform
cobolbridge.ai	Legacy modernization

📜 License

MIT © CSOAI-ORG

Configuration

Add to your claude_desktop_config.json (Claude Desktop) or your MCP client config:

{
  "mcpServers": {
    "nis2-compliance-mcp": {
      "command": "uvx",
      "args": ["nis2-compliance-mcp"]
    }
  }
}

Or: pip install nis2-compliance-mcp then run the nis2-compliance-mcp command (stdio transport).

Examples

Once configured, ask your assistant, for example:

"Use classify_entity to …"
"Use list_article_21_measures to …"
"Use audit_article_21 to …"

Available Tools

7 tools

audit_article_21A

Audit your current controls against NIS2 Article 21's 10 mandatory risk-management measures. Returns per-measure evidence status + gap list + sanction exposure tier.

Behavior: This tool is read-only and stateless — it produces analysis output without modifying any external systems, databases, or files. Safe to call repeatedly with identical inputs (idempotent). Free tier: 10/day rate limit. Pro tier: unlimited. No authentication required for basic usage.

When to use: Use this tool when you need to assess, audit, or verify compliance requirements. Ideal for gap analysis, readiness checks, and generating compliance documentation.

When NOT to use: Do not use as a substitute for qualified legal counsel. This tool provides technical compliance guidance, not legal advice.

Args: entity_description (str): The entity description to analyze or process. current_controls (str): The current controls to analyze or process. api_key (str): The api key to analyze or process.

Behavioral Transparency: - Side Effects: This tool is read-only and produces no side effects. It does not modify any external state, databases, or files. All output is computed in-memory and returned directly to the caller. - Authentication: No authentication required for basic usage. Pro/Enterprise tiers require a valid MEOK API key passed via the MEOK_API_KEY environment variable. - Rate Limits: Free tier: 10 calls/day. Pro tier: unlimited. Rate limit headers are included in responses (X-RateLimit-Remaining, X-RateLimit-Reset). - Error Handling: Returns structured error objects with 'error' key on failure. Never raises unhandled exceptions. Invalid inputs return descriptive validation errors. - Idempotency: Fully idempotent — calling with the same inputs always produces the same output. Safe to retry on timeout or transient failure. - Data Privacy: No input data is stored, logged, or transmitted to external services. All processing happens locally within the MCP server process.

ParametersJSON Schema

Name	Required	Description	Default
`entity_description`	Yes
`current_controls`	No
`api_key`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior5/5

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

With no annotations provided, the description carries the full burden and fully discloses all relevant behaviors: read-only, stateless, idempotent, rate limits (10/day free), authentication needs (none for basic), error handling, and data privacy. This exceeds requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

The description is well-structured with sections but contains redundancy, notably the 'Behavior' and 'Behavioral Transparency' sections that repeat the same points (read-only, idempotent). This could be condensed without losing information.

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 has moderate complexity (auditing against NIS2) and an output schema is indicated. The description covers return values (evidence status, gaps, sanction tier), usage guidance, and behavior. However, parameter descriptions are vague, and with 3 parameters (1 required), more specific guidance on entity_description and current_controls would improve completeness.

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 0%, so description must compensate. However, the 'Args' section only restates parameter names and types generically (e.g., 'The entity description to analyze') without explaining expected formats, examples, or constraints. This adds little value 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 audits controls against NIS2 Article 21's 10 measures. The verb 'audit' and resource 'controls against NIS2 Article 21 measures' are specific, and sibling tools like classify_entity or enforce_status have different purposes, making this distinct.

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 provides explicit 'When to use' (assessment, gap analysis) and 'When NOT to use' (not legal advice) sections, offering clear context. However, it does not explicitly contrast with sibling tools like classify_entity or list_article_21_measures, which could further guide selection.

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

classify_entityA

Classify an entity's NIS2 scope (essential / important / out-of-scope) + sector. Size-cap rules (Article 2): essential if in Annex I AND medium-size (>50 FTE or >€10M) — generally large (>250 FTE or >€50M). Important if Annex II + medium-size.

When to use: Use this tool when you need to assess, audit, or verify compliance requirements. Ideal for gap analysis, readiness checks, and generating compliance documentation.

When NOT to use: Do not use as a substitute for qualified legal counsel. This tool provides technical compliance guidance, not legal advice.

Args: entity_description (str): The entity description to analyze or process. employees (int): The employees to analyze or process. turnover_million_eur (float): The turnover million eur to analyze or process. api_key (str): The api key to analyze or process.

ParametersJSON Schema

Name	Required	Description	Default
`entity_description`	Yes
`employees`	No
`turnover_million_eur`	No
`api_key`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior5/5

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

No annotations provided, but the description covers side effects (read-only, stateless), authentication (no auth for basic, API key for pro), rate limits (free 10/day), error handling, idempotency, and data privacy. Very thorough.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

Well-structured with clear sections, but contains redundancy (e.g., 'Behavioral Transparency' repeated). Some sentences could be merged for better conciseness.

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?

Covers size-cap rules, rate limits, auth, and error handling. With an output schema present, return values are not needed. Lacks clarity on possible sector values, but overall adequate for agent use.

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 has 0% description coverage. The 'Args' section adds generic phrases like 'to analyze or process' that barely clarify meaning. Although the main description mentions size-cap rules, parameter-specific semantics are weak.

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 classifies an entity's NIS2 scope (essential/important/out-of-scope) and sector, with specific rules. It distinguishes from siblings like classify_incident by focusing on entity classification.

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?

Explicit 'When to use' and 'When NOT to use' sections provide context for gap analysis and compliance checks, and warn against legal advice. However, it does not contrast with sibling tools or specify when to prefer alternatives.

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

classify_incidentA

Classify a cyber incident against NIS2 Article 23 thresholds. Returns whether 'significant' — triggering 24h early warning, 72h incident notification, 1-month final report.

When to use: Use this tool when you need to assess, audit, or verify compliance requirements. Ideal for gap analysis, readiness checks, and generating compliance documentation.

When NOT to use: Do not use as a substitute for qualified legal counsel. This tool provides technical compliance guidance, not legal advice.

Args: incident_description (str): The incident description to analyze or process. users_affected (int): The users affected to analyze or process. duration_hours (float): The duration hours to analyze or process. cross_border (bool): The cross border to analyze or process. data_breach (bool): The data breach to analyze or process. financial_loss_eur (float): The financial loss eur to analyze or process. api_key (str): The api key to analyze or process.

ParametersJSON Schema

Name	Required	Description	Default
`incident_description`	Yes
`users_affected`	No
`duration_hours`	No
`cross_border`	No
`data_breach`	No
`financial_loss_eur`	No
`api_key`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior5/5

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

Despite no annotations, the description comprehensively covers read-only, stateless, idempotent nature, authentication requirements, rate limits, error handling, and data privacy. No contradictions with annotations.

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 well-structured with clear sections (behavior, usage, args, transparency) and front-loaded purpose. However, the arg descriptions are repetitive, slightly reducing conciseness.

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 no annotations and an output schema present, the description covers behavior, authentication, rate limits, and error handling well. The output format (returning 'significant' status and triggers) is implied but not fully explicit.

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?

With 0% schema description coverage, the arg descriptions are generic ('The X to analyze or process'), adding minimal meaning beyond parameter names and types. They fail to explain how each parameter influences classification.

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 classifies cyber incidents against NIS2 Article 23 thresholds and specifies the 'significant' output triggering regulatory timelines. It distinguishes from sibling tools like 'classify_entity' or 'audit_article_21' by its incident-specific focus.

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

Usage Guidelines5/5

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

The description includes explicit 'When to use' (gap analysis, compliance checks) and 'When NOT to use' (not legal advice) sections, providing clear context and differentiation from alternatives.

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

enforcement_statusA

Current NIS2 enforcement status + national transposition tracker.

When to use: Use this tool when you need to assess, audit, or verify compliance requirements. Ideal for gap analysis, readiness checks, and generating compliance documentation.

When NOT to use: Do not use as a substitute for qualified legal counsel. This tool provides technical compliance guidance, not legal advice.

Args: api_key (str): The api key to analyze or process.

ParametersJSON Schema

Name	Required	Description	Default
`api_key`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.6/5.0

Behavior5/5

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

Despite no annotations, the description thoroughly discloses side effects (none), authentication requirements, rate limits, error handling, idempotency, and data privacy, exceeding basic expectations.

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?

Well-structured with clear sections, but somewhat verbose. Could be shortened without losing clarity.

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?

Covers all necessary aspects given the tool's simplicity: behavior, when to use, side effects, error handling, and output schema exists. Very complete.

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 description adds little beyond the schema for the only parameter (api_key), mentioning it in the Args section but without additional detail. With 0% schema description coverage, more guidance would be beneficial.

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 it provides 'Current NIS2 enforcement status + national transposition tracker' and lists specific use cases like gap analysis and readiness checks, distinguishing it from sibling tools.

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

Usage Guidelines5/5

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

Explicitly states when to use (assess, audit, verify compliance) and when NOT to use (not a substitute for legal counsel). Provides clear context for usage.

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

get_nis2_certificateA

Generate a timestamped signed NIS2 compliance certificate (Pro/Enterprise tier).

Behavior: This tool generates structured output without modifying external systems. Output is deterministic for identical inputs. No side effects. Free tier: 10/day rate limit. Pro tier: unlimited. No authentication required for basic usage.

When to use: Use this tool when you need to assess, audit, or verify compliance requirements. Ideal for gap analysis, readiness checks, and generating compliance documentation.

When NOT to use: Do not use as a substitute for qualified legal counsel. This tool provides technical compliance guidance, not legal advice.

Args: entity_name (str): The entity name to analyze or process. overall_score (float): The overall score to analyze or process. api_key (str): The api key to analyze or process.

ParametersJSON Schema

Name	Required	Description	Default
`entity_name`	Yes
`overall_score`	Yes
`api_key`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior5/5

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

With no annotations, the description carries full burden and excels: discloses read-only nature, authentication requirements, rate limits per tier, error handling, idempotency, and data privacy. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

Well-structured with clear sections, but contains redundancy (e.g., 'Behavior' line repeats later 'Behavioral Transparency' details). Slightly verbose for the amount of unique 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?

Covers behavioral aspects thoroughly but lacks detail on output format or semantics of parameters (entity_name, overall_score). Output schema exists but description doesn't hint at certificate structure.

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 0%, yet the description's 'Args' only restates parameter names and types without adding meaning (e.g., format, constraints, examples). This fails to compensate for the sparse 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 it generates a timestamped signed NIS2 compliance certificate, specifying the resource and action. It is distinct from sibling tools which audit, classify, or list, making purpose unambiguous.

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?

Provides explicit 'When to use' and 'When NOT to use' sections, covering appropriate contexts like gap analysis and warning against legal substitution. Lacks direct comparison to siblings but is sufficient for differentiation.

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

list_article_21_measuresA

List all 10 cybersecurity risk-management measures required under NIS2 Article 21.

When to use: Use this tool when you need to assess, audit, or verify compliance requirements. Ideal for gap analysis, readiness checks, and generating compliance documentation.

When NOT to use: Do not use as a substitute for qualified legal counsel. This tool provides technical compliance guidance, not legal advice.

Args: api_key (str): The api key to analyze or process.

ParametersJSON Schema

Name	Required	Description	Default
`api_key`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations provided, the description fully discloses behavioral traits: read-only, stateless, idempotent, rate limits, authentication requirements, error handling, and data privacy. This exceeds the minimum needed for safe invocation.

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 well-structured with clear sections (Behavior, When to use, etc.), front-loads the main purpose, and every sentence adds value. It is appropriately sized for the detail provided.

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 optional parameter, output schema exists), the description covers purpose, usage, behavior, authentication, rate limits, and error handling comprehensively. It meets all needs for correct 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 description mentions the api_key parameter as 'The api key to analyze or process,' but this is vague and does not clarify its actual role (e.g., for rate limiting or authentication). The behavioral transparency section explains authentication separately, creating confusion. Given 0% schema coverage, the description should provide clearer parameter meaning.

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 lists all 10 cybersecurity risk-management measures under NIS2 Article 21, using a specific verb and resource. It distinguishes itself from siblings like audit_article_21 or classify_entity by focusing on listing measures.

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

Usage Guidelines5/5

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

The description includes explicit 'When to use' and 'When NOT to use' sections, providing context for compliance assessment and gap analysis while warning against substituting for legal counsel. This gives clear guidance on appropriate usage scenarios.

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

management_body_checklistA

NIS2 Article 20 — management body accountability checklist. Directors can be held personally liable.

When to use: Use this tool when you need to assess, audit, or verify compliance requirements. Ideal for gap analysis, readiness checks, and generating compliance documentation.

When NOT to use: Do not use as a substitute for qualified legal counsel. This tool provides technical compliance guidance, not legal advice.

Args: api_key (str): The api key to analyze or process.

ParametersJSON Schema

Name	Required	Description	Default
`api_key`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior5/5

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

With no annotations provided, the description carries full burden. It includes a dedicated 'Behavioral Transparency' section covering side effects (read-only, no side effects), authentication, rate limits, error handling, idempotency, and data privacy. This is comprehensive and fully informs the agent.

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 well-structured with clear sections and front-loaded purpose. However, there is slight redundancy between the initial 'Behavior' paragraph and the later 'Behavioral Transparency' section, which could be merged for conciseness.

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 output schema exists, the description needn't detail return values. It covers input, behavior, usage, and limitations. Lacks only deeper context about the checklist content, but overall sufficient for agent selection and invocation.

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 schema has 0% description coverage for its only parameter (api_key). The description merely repeats 'api key to analyze or process', adding minimal value. It fails to explain the key's purpose, source, or format, which is insufficient for a parameter with no schema description.

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 provides a checklist for NIS2 Article 20 management body accountability, using a specific verb ('assess, audit, verify'). It distinguishes itself from sibling tools like audit_article_21 and classify_entity by focusing on this specific compliance aspect.

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 explicitly states when to use (gap analysis, compliance documentation) and when not to use (substitute for legal counsel). However, it does not mention when to prefer this over specific siblings, missing a chance for clearer differentiation.

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. Dates show when Glama detected each change.

7 tool updatesv1.2.4May 8, 2026
- First observedaudit_article_21
- First observedclassify_entity
- First observedclassify_incident
- First observedenforcement_status
- First observedget_nis2_certificate
- First observedlist_article_21_measures
- First observedmanagement_body_checklist

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0

Disambiguation5/5

Each tool addresses a distinct compliance aspect: scope classification, incident classification, auditing, listing measures, enforcement tracking, certificate generation, and management accountability. No two tools have overlapping purposes.

Naming Consistency3/5

Names mix verb_noun patterns (audit_article_21, classify_entity) with noun_phrases (enforcement_status, management_body_checklist) and get_ prefix (get_nis2_certificate). While mostly understandable, the inconsistency reduces predictability.

Tool Count5/5

Seven tools cover the key NIS2 compliance tasks without bloat. The count is well-scoped for a focused compliance assessment server.

Completeness4/5

Core compliance workflows are covered (scoping, incident classification, auditing, listing, enforcement, certification, management accountability). Missing remediation guidance or supply chain checks, but no critical dead ends.

Maintenance

ActivityStale

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

mcp-agentcore A
com.geiant
AI governance MCP server for EU AI Act compliance and jurisdiction verification
Legal & Compliance AI & Machine Learning Government Data
32
NORMA MCP Server A
io.github.kynosure-ai
EU compliance corpus across 8 frameworks (NIS2, DORA, AI Act, ISO 27001 + more) via MCP.
Legal & Compliance Security
2
Nizh
com.nizh
Compliance frameworks (SOC 2, ISO 27001, CMMC, NIST, more) delivered to AI agents as MCP tools.
1
meok-mcp-hardening-mcp
io.github.CSOAI-ORG
MEOK MCP Hardening MCP — automated security red-team for any MCP server. Maps OWASP LLM Top 10
Penetration Testing Security
1

Related MCP Servers

ISO 27001 AI MCPofficial
Security Legal & Compliance
CSOAI-ORG
A
license
Not graded
quality
B
maintenance
ISO 27001 AI - MCP server providing AI-powered tools and automation by MEOK AI Labs
Updated 2 days ago (2026-09-04 12:40 UTC)
18
3
MIT
EU AI Act Compliance MCP
Legal & Compliance Security
CSOAI-ORG
A
license
A
quality
B
maintenance
EU AI Act Compliance - MCP server providing AI-powered tools and automation by MEOK AI Labs
Updated 2 days ago (2026-09-04 12:38 UTC)
11
17
1
MIT
Cybersecurity AI MCP
Security AI & Machine Learning Autonomous Agents
CSOAI-ORG
A
license
A
quality
B
maintenance
Cybersecurity AI - MCP server providing AI-powered tools and automation by MEOK AI Labs
Updated 3 months ago (2026-06-15 14:40 UTC)
5
17
MIT
SOC2 Compliance AI MCPofficial
Legal & Compliance Security
CSOAI-ORG
A
license
A
quality
C
maintenance
SOC2 Compliance AI - MCP server providing AI-powered tools and automation by MEOK AI Labs
Updated a month ago (2026-08-04 12:56 UTC)
6
16
MIT

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/CSOAI-ORG/nis2-compliance-mcp'

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

🔏 Free tier: 50 calls/day. Need audit-ready proof?

Nis2 Compliance MCP

🚀 Quick Start

⚡ Pay-per-call (PAYG) — no subscription

✨ Features

📖 Documentation

🛡️ Compliance

🏢 Enterprise

🤝 Part of the MEOK Ecosystem

📜 License

Configuration

Examples

See also

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

ISO 27001 AI MCPofficial

SOC2 Compliance AI MCPofficial

Latest Blog Posts

MCP directory API