TicketDesk MCP – Produktionsreifer MCP-Server & -Client

Ein Server auf Basis des Model Context Protocol (MCP), der eine interne Warteschlange für Support-Tickets bereitstellt, gekoppelt mit einem Client, der dessen Tools, Ressourcen und Prompts entdeckt und aufruft. Gebaut für das Labor „Build a Production MCP Server & Client“ (Modul 4, Model Context Protocol).

Inhaltsverzeichnis

• Architektur

• Einrichtung & Ausführung der Demo

• docs/tools-resources-prompts.md – was der Server bereitstellt

• docs/architecture.md – Transportwahl & Begründung

• docs/security-summary.md – Authentifizierung, Least-Privilege-Prinzip, Fehlerbehandlung

• demo/session_log.txt – ein echter, aufgezeichneter Discovery- und Invocation-Lauf

Related MCP server: TicketAI

Architektur

flowchart TD
    HOST["Host application\n(e.g. an AI assistant / chatbot)"] --> CLIENT

    subgraph Client["client.py — fastmcp.Client"]
        CLIENT["Discovery: list_tools / list_resources /\nlist_resource_templates / list_prompts"]
        ELICIT["elicitation_handler\n(client-side safety gate for\nhigh-impact actions)"]
        CLIENT <--> ELICIT
    end

    CLIENT <-->|"Streamable HTTP\nAuthorization: Bearer <token>"| SERVER

    subgraph Server["server.py — FastMCP('TicketDesk')"]
        AUTH["StaticTokenVerifier\n(read:tickets / write:tickets scopes)"]
        TOOLS["Tools: search_tickets, get_ticket,\nadd_ticket_note, close_ticket"]
        RES["Resources: ticket://{ticket_id},\npolicy://sla"]
        PROMPT["Prompt: triage_ticket"]
        AUTH --> TOOLS
        AUTH --> RES
        AUTH --> PROMPT
    end

    SERVER --> DATA[("data/tickets.json,\ndata/sla_policy.md")]

Transport: Streamable HTTP – begründet in docs/architecture.md (Kurzfassung: Dies ist als gemeinsame interne Fähigkeit gedacht, an die die KI-Anwendungen mehrerer Teams anschließen, nicht als einzelnes lokales Prozesspaar, wofür stdio geeignet ist).

Was der Server bereitstellt

• 4 Tools: search_tickets, get_ticket, add_ticket_note, close_ticket (das letzte ist eine Aktion mit großer Auswirkung, die durch eine client-seitige Rückfrage abgesichert ist)

• 2 Ressourcen: ticket://{ticket_id} (vorlagenbasiert) und policy://sla (statisch)

• 1 Prompt: triage_ticket

Die vollständige Dokumentation aller Elemente: docs/tools-resources-prompts.md.

Einrichtung & Ausführung der Demo

pip install -r requirements.txt

# Terminal 1
python server.py

# Terminal 2
python client.py                # interactive: real confirmation prompts via input()
python client.py --auto-confirm # non-interactive demo mode (used to produce demo/session_log.txt)

client.py verbindet sich mit dev-agent-token (Scopes für Lesen und Schreiben), führt die Discovery aus, ruft je ein Tool, eine Ressource und einen Prompt auf, demonstriert beide Fehlermodi (Anforderung 8), führt die Aktion close_ticket mit großer Auswirkung über eine client-seitige Rückfrage aus (Anforderung 6) und endet mit einer Least-Privilege-Demo, die zeigt, dass dev-readonly-token korrekt von einem Tool mit Schreib-Scope abgelehnt wird.

Sicherheit

Vollständige Darlegung: docs/security-summary.md. Kurzfassung: Bearer-Token-Authenfiserung über StaticTokenVerifier, explizite Scope-Prüfungen pro Tool (eine echte original Lücke – alleinige Scope-Anforderungen auf Veretzungsebene beschränken die einzelnen Tool-Aufrufe nicht – wurden während der Entwicklung entdeckt and behoben; see das Sicherheitsdokument für den erflichen Rahmen), sowie ToolError + mask_error_details=True, um vom Benutzer behebbare Fehler von Hairinterne Fehler, die niemals unverebndert beim Client ankommen dürfen, zu unterscheiden.

Anforderungszuordnung