Server definition

Hash: sha256:d5a42a9663935ee1a8848f1a1f118caf9b0375e2db986d2e9f76785c80edf0fb
What it is: What a remote MCP server returned when asked what it offers: 6 tools

The blob, as servednamed by its sha256

{
  "instructions": "Löst Dienstpläne (shift schedules) über die vigotime Planner API. Ablauf: 1) example_payload ansehen, 2) solve_submit mit einem self-contained Payload (Mitarbeiter/Schichten/Regeln als JSON, IDs statt Klarnamen — Datenminimierung!), 3) solve_status pollen bis 'completed', 4) solve_result holen. Datumsformat ISO (YYYY-MM-DD), Zeiten HH:MM. Ein Solve kostet Tokens (account_balance zeigt das Guthaben; HTTP 402 = Guthaben aufladen, 429 = warten). WICHTIG: Der Solver erzwingt NUR die Regeln im Payload (planning_rules) — ohne sie gilt nur 'max. eine Schicht pro Tag': keine Ruhezeiten, keine Folgetage-Grenzen, keine Wochenstunden-Kappen. Fuer rechtssichere Plaene (z.B. ArbZG) Regeln explizit mitgeben — example_payload(kind='rules') zeigt ein verifiziertes Beispiel. Param-Namen sind EXAKT (requireMinRest {hours}, limitConsecutiveDays {maxDays, requiredRestDays}): falsche Namen machen die Regel STILL wirkungslos — im Ergebnis rule_effectiveness pruefen und den Nutzer auf fehlende Regeln hinweisen. ZUKUNFTSKONTEXT bei Datums-Kopplungen (worksOnDate->blockDate, z.B. 'Ostern gearbeitet -> Pfingsten frei'): liegen die Block-Tage HINTER dem Planfenster, MUESSEN bekannte Abwesenheiten fuer diese Tage im Payload stehen — vacations DARF und SOLL Termine nach end_date enthalten. Der Solver waehlt dann bevorzugt Personen als Feiertags-Crew, deren Block ohnehin in Abwesenheit fiele; ohne diese Angaben plant er blind und Folgeplaene koennen unloesbar werden. Im Zweifel den Nutzer aktiv nach Urlauben/Abwesenheiten im Block-Zeitraum fragen. PRECHECKS: solve_submit liefert ggf. prechecks[] (z.B. RULE_NEEDS_FUTURE_CONTEXT). Diese Rueckfragen MUESSEN an den Nutzer weitergegeben werden — Daten nachliefern (vacations um die genannten blockDates ergaenzen) oder die Bestaetigung des Nutzers einholen, NIE stillschweigend weitermachen. PLANBILD-Regeln fuer menschliche Plaene (alle mit exakten Params, Referenz im Developer-Portal): requireMinWorkBlock/requireMinFreeBlock {minDays}, keepShiftTypeBlocks {minBlock}, preferForwardRotation {order} (immer weich), requireShiftBlocks {shiftType, minBlock, targetBlock, maxBlock, minIsHard} (dreistufig: minBlock+minIsHard=harte Untergrenze, targetBlock=weiches Ziel, maxBlock=immer harte Obergrenze; ohne minIsHard ist minBlock das weiche Ziel; es gilt minBlock <= targetBlock <= maxBlock, sonst wird die Regel verworfen), keepWeekendsWhole {}, limitConsecutiveWorkingWeekends {max}, limitShiftTypesPerWeek {max}. SERIEN-Regel shiftSequence {pattern: [{shiftType, days}|{free}], repeat, tail, cycle, anchorDate, employeeOffsets}: feste Rotation (z.B. 2 Frueh, 2 Spaet, 2 Nacht, 3 frei) ab absolutem Anker-Datum, je Mitarbeiter phasenversetzt — die Phasenlage bleibt ueber Planungszeitraeume erhalten.",
  "tools": [
    {
      "description": "Aktuelles Token-Guthaben der eigenen Organisation (Solves kosten Tokens).",
      "inputSchema": {
        "properties": {},
        "title": "account_balanceArguments",
        "type": "object"
      },
      "name": "account_balance",
      "outputSchema": {
        "additionalProperties": true,
        "title": "account_balanceDictOutput",
        "type": "object"
      }
    },
    {
      "description": "Ein sofort lauffähiger Beispiel-Payload für solve_submit. kind='simple' (1 Woche, 3 MA, 2 Schichten), kind='wishes' (Wünsche, Social Points, Wunschkosten) oder kind='rules' (ArbZG-Planungsregeln: 11 h Ruhe hart + max. 5 Folgetage — zeigt, wie Regeln den Plan formen; Param-Namen sind exakt, falsche werden still ignoriert).",
      "inputSchema": {
        "properties": {
          "kind": {
            "default": "simple",
            "title": "Kind",
            "type": "string"
          }
        },
        "title": "example_payloadArguments",
        "type": "object"
      },
      "name": "example_payload",
      "outputSchema": {
        "additionalProperties": true,
        "title": "example_payloadDictOutput",
        "type": "object"
      }
    },
    {
      "description": "Build-Stand des laufenden Planner-Service: version (fortlaufende Build-Nummer), gitCommit, buildTime (UTC). Fuer Support-Anfragen und um Ergebnisse einem Software-Stand zuzuordnen.",
      "inputSchema": {
        "properties": {},
        "title": "service_infoArguments",
        "type": "object"
      },
      "name": "service_info",
      "outputSchema": {
        "additionalProperties": true,
        "title": "service_infoDictOutput",
        "type": "object"
      }
    },
    {
      "description": "Ergebnis eines fertigen Solve-Jobs: assignments [{employee_id, shift_id, date}], unassigned_shifts mit Begründung, Statistiken.",
      "inputSchema": {
        "properties": {
          "job_id": {
            "title": "Job Id",
            "type": "string"
          }
        },
        "required": [
          "job_id"
        ],
        "title": "solve_resultArguments",
        "type": "object"
      },
      "name": "solve_result",
      "outputSchema": {
        "additionalProperties": true,
        "title": "solve_resultDictOutput",
        "type": "object"
      }
    },
    {
      "description": "Status eines Solve-Jobs (pending/running/completed/failed) inkl. Fortschritt.",
      "inputSchema": {
        "properties": {
          "job_id": {
            "title": "Job Id",
            "type": "string"
          }
        },
        "required": [
          "job_id"
        ],
        "title": "solve_statusArguments",
        "type": "object"
      },
      "name": "solve_status",
      "outputSchema": {
        "additionalProperties": true,
        "title": "solve_statusDictOutput",
        "type": "object"
      }
    },
    {
      "description": "Reicht einen Dienstplan-Solve-Job ein. `payload` ist der self-contained Request: Pflicht: start_date, end_date (ISO), department {id}, employees [{id, contractHoursPerWeek, qualificationIds}], shifts [{id, departmentId, name, startTime, endTime, shiftType, minStaff}]. Optional u. a.: planning_rules, wishes, vacations, sick_leaves, holiday_dates, locked_assignments, social_points, wish_costs, config {timeout_seconds}. vacations darf Termine NACH end_date enthalten — noetig bei Datums-Kopplungsregeln mit Block-Tagen hinter dem Fenster (siehe Instructions). Datenschutz: IDs statt Namen verwenden. Antwort: {job_id, status}.",
      "inputSchema": {
        "properties": {
          "payload": {
            "additionalProperties": true,
            "title": "Payload",
            "type": "object"
          }
        },
        "required": [
          "payload"
        ],
        "title": "solve_submitArguments",
        "type": "object"
      },
      "name": "solve_submit",
      "outputSchema": {
        "additionalProperties": true,
        "title": "solve_submitDictOutput",
        "type": "object"
      }
    }
  ]
}

Verify it yourself

curl -s https://api.teppi.xyz/v1/evidence/sha256:d5a42a9663935ee1a8848f1a1f118caf9b0375e2db986d2e9f76785c80edf0fb | sha256sum