Skip to main content
Glama
Hei33enberg

ZomPP MCP Server

by Hei33enberg
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

📖 O projekcie

ZomPP MCP Server to potężny, niezależny interfejs API zbudowany w oparciu o architekturę Model Context Protocol. Umożliwia on zewnętrznym agentom sztucznej inteligencji (np. Claude 3.5 Sonnet w aplikacji Claude Desktop, narzędziom orkiestracyjnym) na bezpośrednią, bezpieczną komunikację z silnikiem prawnym ZomPP.

Dzięki temu serwerowi, Twój lokalny lub chmurowy Agent AI zyskuje pełny wgląd w ekosystem ZomPP – od zarządzania wygenerowanymi zawiadomieniami po głęboką diagnostykę procesu twórczego (Chyłka-Pattern).

Related MCP server: Pro Se Engine

🛠️ Dostępne Narzędzia (Tool Catalog)

Serwer wystawia następujące narzędzia (Tools) gotowe do użycia przez LLM:

  • 📋 list_reports — Pobiera stronicowaną listę zawiadomień ZomPP z bazy Supabase. Pozwala na zaawansowane filtrowanie po statusach (np. paid, draft).

  • 🔍 get_report — Zwraca pełny, surowy zrzut danych JSON konkretnego raportu na podstawie jego UUID.

  • 🧠 diagnose_orchestration — Zaawansowane narzędzie diagnostyczne. Agent analizuje wygenerowane sekcje prawne (output silnika Chyłki), wykrywa zablokowane pętle, zlicza sekcje i diagnozuje błędy mechanizmów Fallback.

💻 Uruchomienie lokalne (Claude Desktop)

Aby podpiąć ZomPP bezpośrednio pod Twojego lokalnego asystenta Claude Desktop, nie potrzebujesz Dockera. Wystarczy uruchomić serwer w locie przez ts-node.

  1. Sklonuj repozytorium:

    git clone https://github.com/Hei33enberg/zompp-mcp-server.git
cd zompp-mcp-server
npm install

  2. Dodaj poniższą konfigurację do pliku claude_desktop_config.json:

    {
  "mcpServers": {
    "zompp-mcp": {
      "command": "npx",
      "args": ["ts-node", "/BEZWZGLEDNA/SCIEZKA/DO/zompp-mcp-server/src/index.ts"],
      "env": {
        "SUPABASE_URL": "https://jbgfptzpnhedukqfudkr.supabase.co",
        "SUPABASE_ANON_KEY": "TWÓJ_KLUCZ_ANON_KEY",
        "SUPABASE_SERVICE_ROLE": "TWÓJ_KLUCZ_SERVICE_ROLE"
      }
    }
  }
}

☁️ Wdrożenie Produkcyjne (Hetzner VPS)

Serwer jest w 100% gotowy na wdrożenie kontenerowe (Docker) na maszynach typu VPS (np. Hetzner Cloud), co pozwala wpiąć go w globalną sieć agentów (np. platformy White Intel czy Marocain).

  1. Zaloguj się na swojego VPS-a i sklonuj to repozytorium.

  2. Utwórz plik .env i wklej swoje klucze Supabase.

  3. Odpal środowisko jedną komendą:

    docker-compose up -d --build

System automatycznie zbuduje lekki obraz oparty na node:20-alpine i uruchomi serwer MCP w tle.

Available Tools

5 tools
diagnose_orchestrationA

Analyzes generated sections of a report to diagnose Chyłka AI progress or find AI fallback errors.

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesReport UUID to diagnose

TDQS

A3.5/5.0
Behavior2/5

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

No annotations are provided, so the description must fully disclose behavioral traits. It does not state whether the tool modifies data, requires special permissions, or how it handles invalid inputs. The term 'diagnose' suggests a read-only operation, but this is not explicitly confirmed.

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?

A single, well-structured sentence that immediately conveys the action and purpose. No redundant words or information, front-loaded with the verb and resource.

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 tool has only one parameter, no output schema, and no annotations, the description adequately covers the core purpose. However, it lacks details on return format, error handling, or edge cases, which would make it more 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 schema has 100% coverage for the single parameter 'id' with a clear description. The tool description adds no further meaning beyond 'Report UUID to diagnose', which is already in the schema. Baseline 3 is appropriate as the schema already does the work.

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 'Analyzes', the resource 'generated sections of a report', and the dual purposes 'diagnose Chyłka AI progress or find AI fallback errors'. It effectively distinguishes from sibling tools like get_report or list_reports, all of which serve different functions.

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 this tool versus alternatives is provided. The context implies it is for diagnostic purposes, but there are no 'use when' or 'do not use when' statements, nor mention of prerequisites or alternatives.

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

get_reportA

Fetch full details of a ZomPP report by its ID.

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesReport UUID

TDQS

A3.6/5.0
Behavior3/5

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

With no annotations, the description must fully disclose behavior. It implies a read operation ('Fetch full details') but lacks details on authentication, rate limits, side effects, or what 'full details' includes. It is adequate for a simple fetch 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?

One sentence, no wasted words. Front-loaded with verb and resource. Efficient and clear.

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 simple single-parameter fetch tool, the description is mostly complete. It states the purpose and access method. Lacks output schema, but given low complexity, this is acceptable.

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% (one parameter 'id' with format/pattern described). The description adds no extra meaning beyond the schema. Baseline 3 is appropriate as schema does the work.

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 ('Fetch full details'), the resource ('ZomPP report'), and the method ('by its ID'). It distinguishes from siblings like 'list_reports' (likely a list without full details) and 'get_legal_precedent' (different resource).

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?

No explicit guidance on when to use this tool versus siblings like 'list_reports' or 'search_legal_precedents'. It does not mention prerequisites or conditions for use.

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

list_reportsA

List ZomPP reports (zawiadomienia). Use limit to paginate.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMax rows
statusNoFilter by status (e.g. 'paid', 'draft')

TDQS

A3.7/5.0
Behavior3/5

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

Without annotations, the description bears full burden. It correctly implies a read-only list operation but does not explicitly confirm non-destructiveness. It mentions pagination via the limit parameter but lacks details on ordering, empty results, or response format, which are acceptable for a simple list tool.

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 extremely concise with only two sentences, front-loading the key purpose and pagination instruction. Every word earns its place; no fluff.

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 lack of annotations and output schema, the description is adequate for a simple list tool. It covers the main action and pagination but omits details like default ordering and result structure. Could be more complete with response hints.

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% with both parameters described. The description adds a hint to use limit for pagination, which is valuable, but does not mention the status parameter. This provides marginal extra value beyond the schema, meeting the baseline for high coverage.

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 'List' and the resource 'ZomPP reports', with the Polish term in parentheses for clarity. It also mentions pagination using the limit parameter, which differentiates it from the sibling tool get_report that retrieves a single report.

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 listing reports is needed and mentions pagination, but it does not explicitly contrast with sibling tools like get_report or search_legal_precedents. There is no guidance on when not to use this tool, such as for single report retrieval.

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. 5 tool updatesv1.0.0
    • First observeddiagnose_orchestration
    • First observedget_legal_precedent
    • First observedget_report
    • First observedlist_reports
    • First observedsearch_legal_precedents
Deploy Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.8/5.0

Scored across 5 tools

Disambiguation5/5

Each tool targets a distinct operation: analyzing report sections, fetching report details, listing reports, fetching legal precedent, and searching precedents. There is no overlap in purpose.

Naming Consistency5/5

All tool names consistently follow the verb_noun pattern with snake_case (e.g., diagnose_orchestration, get_legal_precedent), making the naming predictable.

Tool Count5/5

With 5 tools, the server is well-scoped for its domain of legal reports and precedents, providing essential operations without overcomplicating the surface.

Completeness4/5

The tool set covers listing and retrieving reports, searching and fetching legal precedents, and diagnosing AI orchestration. Missing write operations (create/update/delete) are acceptable given the likely read-only focus, and the diagnostic aspect is covered, though additional tools for handling found errors could enhance completeness.

Maintenance

ActivityMaintained
ResponsivenessSyncing

Resources

Related MCP Connectors

Related MCP Servers

  • Pro Se Engine

    projectcues
    F
    license
    Not graded
    quality
    C
    maintenance
    Pro Se Engine is an MCP server that provides 39 legal research tools across 6 government APIs, enabling AI agents to access case law, SEC filings, federal legislation, regulations, government contracts, and document processing workflows.
    -
  • @deepidv/mcp-server by Deep-Identity-Inc

    @deepidv/mcp-serverofficial

    Deep-Identity-Inc
    A
    license
    Not graded
    quality
    C
    maintenance
    Enables AI agents to perform identity verification, KYC/KYB, PEP & sanctions screening, bank statement analysis, and workflow automation via the Model Context Protocol.
    MIT

  • RaportAgent MCP Server

    raportagent
    A
    license
    A
    quality
    C
    maintenance
    Enables AI assistants to generate sourced RaportAgent reports and retrieve their audit trails through any MCP client.
    8
    42
    MIT