Skip to main content
Glama
CSOAI-ORG

MEOK DORA Tlpt Planner MCP

scope_tlpt

Generate a DORA Article 26 TLPT scope document for financial entities, including phase plan, deliverables, RACI, and budget breakdown.

Instructions

Generate a DORA Article 26 TLPT scope document for a financial entity.

Args: entity_name: Legal name of the financial entity (e.g., "Acme Bank N.V."). entity_type: One of credit-institution / investment-firm / insurance / pension-fund / payment-institution / e-money-institution / market-infrastructure / CCP. sector: ISIC sector code (default: credit-institution). critical_functions: List of critical/important functions to be scoped (per Art. 26(2)). E.g., ["retail-payments", "trading-platform", "customer-onboarding"]. last_tlpt_date: ISO date of last TLPT (YYYY-MM-DD) — DORA mandates 3-year cycle. annual_budget_estimate_eur: Estimated TLPT engagement budget (drives RT-provider tier).

Returns: Structured scope document with phase plan, deliverables, RACI, and budget breakdown.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
entity_nameYes
entity_typeYes
sectorNocredit-institution
critical_functionsNo
last_tlpt_dateNo
annual_budget_estimate_eurNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • The main handler function 'scope_tlpt' decorated with @mcp.tool(). Generates a DORA Article 26 TLPT scope document for a financial entity. Takes parameters like entity_name, entity_type, sector, critical_functions, last_tlpt_date, annual_budget_estimate_eur and returns a structured dict with entity info, scoped functions, cycle dates, TIBER phases, white-team RACI, RT provider requirements, and budget breakdown.
    @mcp.tool()
    def scope_tlpt(
        entity_name: str,
        entity_type: str,
        sector: str = "credit-institution",
        critical_functions: list[str] | None = None,
        last_tlpt_date: str | None = None,
        annual_budget_estimate_eur: int | None = None,
    ) -> dict[str, Any]:
        """Generate a DORA Article 26 TLPT scope document for a financial entity.
    
        Args:
            entity_name: Legal name of the financial entity (e.g., "Acme Bank N.V.").
            entity_type: One of credit-institution / investment-firm / insurance / pension-fund /
                payment-institution / e-money-institution / market-infrastructure / CCP.
            sector: ISIC sector code (default: credit-institution).
            critical_functions: List of critical/important functions to be scoped (per Art. 26(2)).
                E.g., ["retail-payments", "trading-platform", "customer-onboarding"].
            last_tlpt_date: ISO date of last TLPT (YYYY-MM-DD) — DORA mandates 3-year cycle.
            annual_budget_estimate_eur: Estimated TLPT engagement budget (drives RT-provider tier).
    
        Returns:
            Structured scope document with phase plan, deliverables, RACI, and budget breakdown.
        """
        critical_functions = critical_functions or ["retail-payments", "core-banking"]
        today = datetime.now(timezone.utc).date().isoformat()
    
        # Cycle math: DORA Art. 26(1)(b) — TLPT every 3 years for significant/systemic FIs
        next_tlpt_due = "TBD"
        if last_tlpt_date:
            try:
                last = datetime.fromisoformat(last_tlpt_date).date()
                next_tlpt_due = last.replace(year=last.year + 3).isoformat()
            except ValueError:
                next_tlpt_due = "INVALID_DATE_FORMAT"
    
        # Budget tiering (rough; final RT-provider quotes vary)
        if annual_budget_estimate_eur is None:
            budget_tier = "UNKNOWN"
        elif annual_budget_estimate_eur < 100_000:
            budget_tier = "INSUFFICIENT — DORA TLPT typically EUR 250-500K minimum"
        elif annual_budget_estimate_eur < 500_000:
            budget_tier = "TIER-3 (mid-cap FI)"
        elif annual_budget_estimate_eur < 2_000_000:
            budget_tier = "TIER-2 (large FI)"
        else:
            budget_tier = "TIER-1 (G-SIB)"
    
        return {
            "entity": {
                "name": entity_name,
                "type": entity_type,
                "sector": sector,
            },
            "scope": {
                "critical_functions_in_scope": critical_functions,
                "exclusions_to_document": [
                    "Functions outside DORA Art. 6(8) operational risk perimeter",
                    "Sandbox/test environments not used by customers",
                    "Functions covered by parent-level group TLPT in last 12 months",
                ],
            },
            "cycle": {
                "last_tlpt_date": last_tlpt_date,
                "next_tlpt_due": next_tlpt_due,
                "cycle_basis": "DORA Art. 26(1)(b) — significant/systemic FIs every 3 years",
            },
            "phases": TIBER_PHASES,
            "white_team_raci": WHITE_TEAM_RACI,
            "rt_provider_requirements": RT_PROVIDER_REQUIREMENTS,
            "budget": {
                "estimate_eur": annual_budget_estimate_eur,
                "tier": budget_tier,
                "breakdown_typical": {
                    "threat_intelligence_eur": "30000-80000",
                    "red_team_eur": "100000-500000",
                    "white_team_internal_eur": "60000-200000 (FTE-equivalent)",
                    "remediation_reserve_eur": "100000-500000 (post-test)",
                },
            },
            "scope_document_metadata": {
                "drafted_on": today,
                "drafted_by_tool": "meok-dora-tlpt-planner-mcp",
                "tool_version": "1.0.0",
            },
        }
  • TIBER_PHASES constant — defines the three TLPT phases (preparation, testing, closure) with durations, deliverables, and stakeholders. Used by scope_tlpt in the returned 'phases' key.
    TIBER_PHASES = {
        "preparation": {
            "duration_weeks": "4-8",
            "description": "Scope definition, white-team assembly, threat-intel commission",
            "deliverables": [
                "TLPT scope document (critical/important functions selected)",
                "White-team Terms of Reference (ToR)",
                "Threat-intelligence provider engagement letter",
                "Red-team provider qualification (DORA Art. 27 RTS)",
                "Notification to lead overseer (TIBER-EU Cyber Team / national authority)",
            ],
            "stakeholders": ["white-team-lead", "ciso", "head-of-it-risk", "tlpt-cyber-team"],
        },
        "testing": {
            "duration_weeks": "12-16",
            "description": "Threat intelligence + red-team engagement against live production",
            "deliverables": [
                "Targeted Threat Intelligence (TTI) report",
                "Red-team Test Plan (TTP-mapped to MITRE ATT&CK)",
                "Live red-team engagement against production systems",
                "Daily situation reports to white-team",
                "Test summary findings report",
            ],
            "stakeholders": ["red-team", "threat-intel-provider", "white-team-lead"],
        },
        "closure": {
            "duration_weeks": "6-10",
            "description": "Findings, remediation, replay, attestation",
            "deliverables": [
                "Findings report with severity-ranked detected gaps",
                "Remediation plan (90/180/365-day milestones)",
                "Purple-team replay test (validate fixes)",
                "Final TLPT attestation (signed by white-team + RT lead)",
                "Submission to lead overseer for sign-off (Art. 26(7) DORA)",
            ],
            "stakeholders": ["white-team-lead", "remediation-owner", "lead-overseer"],
        },
    }
  • RT_PROVIDER_REQUIREMENTS constant — lists DORA Article 27 red-team provider requirements. Used by scope_tlpt in the returned 'rt_provider_requirements' key.
    RT_PROVIDER_REQUIREMENTS = [
        "Independent from the financial entity (no commercial conflict in last 24 months)",
        "Hold ISO/IEC 27001 + ISO/IEC 27037 certifications",
        "Minimum 5 years of red-team engagements in financial sector",
        "Per Art. 27(2): qualified personnel with documented competence in MITRE ATT&CK",
        "Civil liability insurance ≥€10M",
        "GDPR-compliant data handling for any captured live data",
        "Background-checked staff for engagements above EUR 1B in critical functions",
    ]
  • WHITE_TEAM_RACI constant — defines white-team roles and responsibilities per TIBER-EU framework. Used by scope_tlpt in the returned 'white_team_raci' key.
    WHITE_TEAM_RACI = {
        "white-team-lead": {
            "responsibility": "Overall test integrity + safety; sole authority to abort/pause test",
            "accountability": "Reports directly to CEO/CISO; signs final attestation",
        },
        "operations-coordinator": {
            "responsibility": "Real-time situation awareness during red-team engagement; SOC-liaison",
            "accountability": "Briefs white-team-lead twice daily during testing phase",
        },
        "evidence-custodian": {
            "responsibility": "Cryptographic chain-of-custody for all findings, screenshots, packet captures",
            "accountability": "Maintains tamper-evident artifact log; produces signed evidence pack at closure",
        },
        "remediation-owner": {
            "responsibility": "Tracks remediation tickets to closure; coordinates purple-team replay",
            "accountability": "Reports to CTO/CISO; produces 90/180/365-day milestone reports",
        },
        "comms-lead": {
            "responsibility": "Internal stakeholder communication; ensures NO leak of test status to blue-team",
            "accountability": "Reports to white-team-lead; signs comms-discipline attestation",
        },
    }
  • Registration of scope_tlpt via the @mcp.tool() decorator on line 118. The FastMCP server is instantiated on line 22 as 'mcp = FastMCP("meok-dora-tlpt-planner")'.
    # === Tools ===
Behavior4/5

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

No annotations are provided, so the description carries full burden. It discloses that the tool returns a structured scope document and outlines its contents (phase plan, deliverables, RACI, budget breakdown). This provides clear behavioral expectations, though it could explicitly confirm no side effects or authorization needs.

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 Args and Returns sections, and each sentence adds value. It is moderately concise, though the parameter explanations could be slightly more compact 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?

Given the tool's complexity (6 parameters, 2 required, has output schema), the description covers all parameters and the return value comprehensively. It provides sufficient context for an agent to invoke the tool correctly without ambiguity.

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

Parameters5/5

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

Schema description coverage is 0%, but the description compensates by explaining each parameter in detail (e.g., allowed values for entity_type, default for sector, purpose of critical_functions, format for last_tlpt_date). This adds significant meaning beyond the schema's property names and types.

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 'Generate a DORA Article 26 TLPT scope document for a financial entity', a specific verb+resource. Sibling tools (list_phases, pricing, etc.) address different use cases, so this tool is well-distinguished.

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 context (generating a TLPT scope document) but does not explicitly state when to use this tool versus alternatives like pricing or threat_intel_brief. No exclusion criteria or guidance on when not to use it.

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

Install Server

Other Tools

Latest Blog Posts

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/meok-dora-tlpt-planner-mcp'

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