Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
CAREMAN_URLYesBase URL of your CareMan instance
CAREMAN_PASSWORDYesYour CareMan password
CAREMAN_USERNAMEYesYour CareMan login name

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
get_planungsgruppenA

Returns all planning groups (Planungsgruppen) visible to the logged-in employee for the given month. Use this to discover available group IDs before calling get_abteilungsdienstplan.

Returns: Array of { name: string, id: number }

Example IDs (may vary per installation): 948 = RW 44 Haßloch 949 = RW 51 Neustadt

get_abteilungsdienstplanA

Returns the full team duty roster (Abteilungsdienstplan) for one planning group and month. Contains every employee with their assigned duty codes per day.

Returns raw API data: { data: { from, to, data: [{ // one entry per employee item1: { id, name }, // employee info item2: { data: [{ // assigned days only (sparse) day: { date, bankHolidayName, isSchoolHoliday }, shortName // duty code, e.g. "H31T" }]} }], legendDuties: { ... }, // duty code definitions with times legendLeavePeriods: { ... } } }

Use get_planungsgruppen first to find the planningGroupId.

get_rosters_preloadA

Returns the personal roster preload for one month. A single API call that covers multiple areas: Einsatzwünsche, Vakante Dienste, and Diensttausch.

Returns raw API data with these top-level keys: { rosterUrlaubEinsatzwunsch: { // personal calendar + shift requests data: { data: [{ item1: { name, id }, // employee (self) item2: { data: [{ // all days of the month (not sparse) day: { date, bankHolidayName, isSchoolHoliday }, shortName, // duty type label shortNameSollplan, // concrete duty code, e.g. "H31T" einsatzwunsch: boolean, // true = shift request exists for this day prioritaet: boolean, beantragt: boolean, // requested genehmigt: boolean, // approved einsatzwunschWunsch: number, // wish priority level kommentar: string }]} }]} },

swapDutyOffersOffered: { // Diensttausch: offers from others (can accept) data: { offers: [{ id, date, offerer, acceptor, dutiesOfferer: { data: [string] }, dutiesAcceptor: { data: [string] }, workstationsOfferer, planninggroupsOfferer, workstationsAcceptor, planninggroupsAcceptor, state, comment }]} },

swapDutyOffersOwn: { // Diensttausch: own offers data: { offers: [...] } },

vacantDutiesOccupied: { // Vakante Dienste: taken on by employee data: { duties: [{ idVacantDuty, atDate, nameWorkstation, duty, occupyUntil, state, comment, isAssumed, idPlanningGroup, namePlanningGroup }], legendDuties: { ... } } },

vacantDutiesAssumed: { // Vakante Dienste: assumed but pending data: { duties: [...] } },

fehlzeiten: { ... } // absences }

get_vakante_duty_detailsA

Returns full shift details for a single vacant duty entry.

Use idVacantDuty from get_rosters_preload → vacantDutiesOccupied.data.duties[].idVacantDuty

Returns: { day, from, to, employeeId, entries: [{ shortName, // duty code nameWorkplace, shortNameWorkplace, nameShiftType, nameRole, from, to, // UTC shift start/end times stringDuration, // e.g. "12h00" genehmigungsebene }] }

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.3/5.0

Scored across 4 tools

Disambiguation5/5

Each tool targets a distinct resource: planning groups, team duty roster, personal preload, and vacant duty details. The only potential overlap is between get_abteilungsdienstplan and get_rosters_preload, but one is team-wide and the other is personal, making them clearly complementary.

Naming Consistency3/5

All tool names start with 'get_', but the object part mixes German and English inconsistently (e.g., 'planungsgruppen' vs. 'rosters_preload' vs. 'abteilungsdienstplan'). This mixed-language pattern is predictable at the verb level but not at the noun level.

Tool Count5/5

With 4 tools, the server is well-scoped for a read-only duty management API. Each tool serves a clear, non-redundant purpose, and the count fits within the ideal 3-15 range.

Completeness5/5

The tools cover the core read operations: discovering planning groups, retrieving team rosters, accessing personal roster data with multiple sub-areas, and drilling into vacant duty details. No obvious read-only gaps exist for the implied domain of viewing duty plans.

Maintenance

ActivityStale
ResponsivenessNo issues