CareMan MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CAREMAN_URL | Yes | Base URL of your CareMan instance | |
| CAREMAN_PASSWORD | Yes | Your CareMan password | |
| CAREMAN_USERNAME | Yes | Your 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
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| 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
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
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.
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.
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.
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.