How do I use CareMan MCP?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@CareMan MCP Show duty roster for planning group 'Station A' in October 2024" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

CareMan MCP

by jalibu

Overview Schema Related Servers Score Discussions

JavaScript

Remote

@jalibu/careman-mcp

Read-only MCP server for CareMan Dienstplan (opta data / SIEDA).
Exposes the CareMan REST API as MCP tools so LLMs can query duty rosters, shift requests, vacant duties, and shift swaps.

⚠️ Disclaimer
This is an unofficial, community-developed MCP server. It is not affiliated with, endorsed by, or in any way connected to CareMan or any other company behind the CareMan product. All product and company names are trademarks of their respective owners.
Use at your own risk. This project reverse-engineers an undocumented private API. It may break at any time without notice. The author accepts no liability for any damage, data loss, account suspension, or other consequences arising from its use.
Data privacy warning. CareMan contains sensitive personal and operational data (duty rosters, employee information, etc.). Whenever you use an MCP client that connects to a cloud-hosted AI model (e.g. Claude Desktop → Anthropic, ChatGPT, Gemini, …), your CareMan data will be transmitted to and processed on the AI provider's servers. This is likely incompatible with your organisation's data protection obligations (GDPR / DSGVO). The only way to keep data under your full control is to use a locally running, self-hosted AI model (e.g. Open WebUI + Ollama). You are solely responsible for compliance with applicable data protection laws.

Setup

Open WebUI + Ollama ✅ Recommended (privacy-friendly)

Open WebUI with a locally running Ollama model keeps all data on your own machine — nothing is sent to external servers.

Prerequisites: Open WebUI and Ollama must already be running locally.

In Open WebUI, go to Settings → Tools → MCP Servers (or Admin Panel → Settings → Tools).
Add a new MCP server entry:
- Name: careman
- Command: npx
- Args: -y @jalibu/careman-mcp@latest
- Environment variables:
  CAREMAN_URL=https://careman.mycompany.com CAREMAN_USERNAME=your-username CAREMAN_PASSWORD=your-password
Save and reload. The CareMan tools are now available in your local chat.

Supported Ollama models with good tool-calling ability: qwen2.5:14b, llama3.1:8b, mistral-nemo.

Claude Desktop ⚠️ Cloud — data leaves your network

Privacy notice: Claude Desktop sends your conversations — including all data returned by CareMan — to Anthropic's cloud servers for inference. Only use this setup if you have reviewed and accepted the implications for your organisation's data protection policy.

Add to claude_desktop_config.json (Settings → Developer → Edit Config):

{
  "mcpServers": {
    "careman": {
      "command": "npx",
      "args": ["-y", "@jalibu/careman-mcp@latest"],
      "env": {
        "CAREMAN_URL": "https://careman.mycompany.com",
        "CAREMAN_USERNAME": "your-username",
        "CAREMAN_PASSWORD": "your-password"
      }
    }
  }
}

Restart Claude Desktop. The tools become available immediately.

Environment variables

Variable	Required	Description
`CAREMAN_URL`	✓	Base URL of your CareMan instance
`CAREMAN_USERNAME`	✓	Your CareMan login name
`CAREMAN_PASSWORD`	✓	Your CareMan password

Related MCP server: wealify-kpi-mcp

Tools

`get_planungsgruppen`

Lists all planning groups available for a given month.
Call this first to discover group IDs for get_abteilungsdienstplan.

get_planungsgruppen(year, month)
→ [{ name: "Group A", id: 100 }, { name: "Group B", id: 101 }, ...]

`get_abteilungsdienstplan`

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

get_abteilungsdienstplan(year, month, planningGroupId, planningGroupName?)
→ { data: { data: [{ item1: { name, id }, item2: { data: [...] } }], legendDuties, ... } }

Each day entry in item2.data:

day.date — UTC timestamp of local Berlin midnight
day.bankHolidayName — non-empty string if public holiday
shortName — duty code, e.g. "H31T", "H31N", "H51T"

Days without an assignment are omitted (sparse array).

`get_rosters_preload`

Returns personal roster data for one month — covers three areas in a single API call:

Einsatzwünsche (shift requests) — in rosterUrlaubEinsatzwunsch.data.data[0].item2.data[]:

einsatzwunsch: true flags days with a shift request
shortNameSollplan — requested duty code
genehmigt / beantragt — approval status

Vakante Dienste (vacant duties) — in vacantDutiesOccupied.data.duties[] and vacantDutiesAssumed.data.duties[]:

idVacantDuty — use with get_vakante_duty_details
duty, nameWorkstation, atDate, state, comment

Diensttausch (shift swaps) — in swapDutyOffersOffered.data.offers[] (incoming) and swapDutyOffersOwn.data.offers[] (own):

offerer, acceptor, dutiesOfferer, dutiesAcceptor
workstationsOfferer, planninggroupsOfferer
state, comment

get_rosters_preload(year, month)
→ { rosterUrlaubEinsatzwunsch, swapDutyOffersOffered, swapDutyOffersOwn,
    vacantDutiesOccupied, vacantDutiesAssumed, fehlzeiten }

`get_vakante_duty_details`

Returns full shift details for a single vacant duty entry.

get_vakante_duty_details(idVacantDuty)
→ { entries: [{ shortName, nameWorkplace, from, to, stringDuration, ... }] }

Architecture

   LLM
    │  MCP (stdio)
    ▼
CareMan MCP Server
    ├─ Session Manager  (auto-login, token cache, employeeId)
    ├─ get_planungsgruppen        → POST /api/-/vacant-duties/possible-planninggroups
    ├─ get_abteilungsdienstplan   → POST /api/-/team-duty/roster/{employeeId}
    ├─ get_rosters_preload        → POST /api/-/rosters/preload
    └─ get_vakante_duty_details   → GET  /api/-/vacant-duties/roster-details-id/{id}

Notes

Undocumented API. All endpoints were reverse-engineered from the minified CareMan JavaScript bundle and verified via browser network inspection. They may change with CareMan updates. If a tool starts returning errors after a CareMan upgrade, compare the request/response format in browser DevTools against the code in src/api.js.

Login format. The login request body uses { item1: username, item2: password } — a generic tuple wrapper pattern used throughout the CareMan codebase. If login fails, verify this against a live browser login via DevTools → Network → POST /api/-/auth/login.

Token lifetime. JWTs expire after roughly 8 hours. The server tracks expiry and re-logs in automatically.

Read-only. No tool submits, modifies, or deletes data. POST requests are used only where the API requires them for data retrieval (a common pattern in this codebase).

Available Tools

4 tools

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.

ParametersJSON Schema

Name	Required	Description
`year`	Yes	Year, e.g. 2026
`month`	Yes	Month (1–12)
`planningGroupId`	Yes	Planning group ID (e.g. 948 for RW 44 Haßloch)
`planningGroupName`	No	Optional: group name for clarity, e.g. 'RW 44 Haßloch'

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations provided, the description carries the burden and does well by stating 'Returns raw API data' and showing the complete response structure, including the sparse nature of assigned days. It adds meaningful behavioral context, though it does not mention auth requirements or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the purpose, followed by a detailed JSON example that illustrates the return format. While the JSON block is long, it is directly useful given no output schema, and the structure is clean with each sentence earning its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Since there is no output schema, the description compensates by providing a complete JSON response layout and explaining the data's granularity. It also covers the prerequisite planningGroupId lookup and the temporal scope. This is sufficient for an agent to invoke the tool correctly, despite not covering error scenarios.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so all parameters already have descriptions. The description adds value beyond the schema by giving a concrete example for planningGroupId ('e.g. 948 for RW 44 Haßloch') and instructing to use get_planungsgruppen to find it, which enriches the schema's bare definition.

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 'Returns' and the specific resource 'full team duty roster' scoped to one planning group and month. It also differentiates from siblings by noting it contains every employee's duty codes per day and references get_planungsgruppen for finding the planningGroupId.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly instructs 'Use get_planungsgruppen first to find the planningGroupId', providing a clear prerequisite and naming an alternative tool. However, it does not explicitly contrast with other sibling tools like get_vakante_duty_details or get_rosters_preload, so it lacks a full when-not explanation.

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

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

ParametersJSON Schema

Name	Required	Description	Default
`year`	Yes	Year, e.g. 2026
`month`	Yes	Month (1–12)

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that results are scoped to the logged-in employee, provides the return structure (Array of { name, id }), and warns that example IDs may vary per installation. These are useful behavioral details beyond a generic 'get' operation, though it does not mention edge cases like empty results or errors.

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 concise and well-structured: a single-purpose statement, a return type line, and a helpful example section. Every sentence contributes value, and the formatting makes it easy to scan. There is no unnecessary filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list-returning tool with two well-documented parameters, the description includes all essential elements: purpose, usage context, return format, and example IDs. It also benefits from sibling tool context, making it sufficiently complete for an agent to select and invoke correctly.

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 already provides complete descriptions for both parameters (year and month) with ranges and examples, achieving 100% coverage. The description's phrase 'given month' only lightly echoes the schema without adding new semantic meaning. The baseline of 3 is appropriate because no additional parameter context is needed.

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 ('Returns'), the resource ('all planning groups'), and the scope ('visible to the logged-in employee for the given month'). It also distinguishes itself from siblings by explicitly stating it should be used before get_abteilungsdienstplan, making its purpose unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says 'Use this to discover available group IDs before calling get_abteilungsdienstplan,' providing direct guidance on when to use the tool and its relationship to a sibling. This is a clear, actionable usage instruction that goes beyond merely describing the tool.

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

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 }

ParametersJSON Schema

Name	Required	Description	Default
`year`	Yes	Year, e.g. 2026
`month`	Yes	Month (1–12)

TDQS

A4/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and provides substantial behavioral context: it states that the API call is single-call covering multiple areas, returns 'raw API data', and explicitly notes that the days list is 'not sparse' (all days included). It also details the structure of each response section. However, it does not mention permissions, error handling, or side effects, which would have made it more complete.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but exceptionally structured: the first sentence states purpose, and the rest is a well-organized code block with comments explaining each top-level key and nested fields. Every section earns its place given the absence of an output schema. It could be slightly trimmed, but the density of useful information justifies the length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of an output schema, the description thoroughly documents the return value with nested structures, making the tool's behavior fully understandable. It covers all major response areas (calendar, swap offers, vacant duties, absences). Error handling and pagination are not discussed, but for a single-call preload with a clearly defined output, the description is sufficiently complete for an agent to select and invoke the tool.

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 input schema already provides descriptions for both parameters (year and month) with 100% coverage. The description adds no additional meaning beyond confirming the tool targets 'one month', which aligns with year/month but does not enrich the parameter semantics. Baseline 3 applies because schema coverage is high.

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 what the tool does: 'Returns the personal roster preload for one month' and lists the specific areas it covers (Einsatzwünsche, Vakante Dienste, Diensttausch). This is a specific verb+resource+scope that distinguishes it from siblings like get_planungsgruppen or get_vakante_duty_details, which are narrower in focus.

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 it is a single combined call for a month's personal roster, but does not explicitly state when to prefer it over alternatives or when not to use it. Sibling names suggest other tools for specific details, but no direct guidance is given. Usage context is implied rather than explicitly stated.

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

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 }] }

ParametersJSON Schema

Name	Required	Description	Default
`idVacantDuty`	Yes	Vacant duty ID from vacantDutiesOccupied or vacantDutiesAssumed

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations, the description must carry the behavioral transparency burden. It clearly indicates this is a read operation ('Returns'), documents the return shape, and adds context like UTC times and duration format. It does not mention failure modes or side effects, but for a simple read with a well-defined output, this is strong.

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 efficiently structured: a one-sentence purpose, a concise usage pointer, and a compact return schema with inline comments. No filler or redundancy; every line contributes to understanding the tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter read tool with no output schema, the description is complete: it states what it does, where to get the parameter, and precisely what the response contains. It provides enough detail for an agent to select and invoke the tool successfully, and even to interpret the response fields.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already covers the parameter with a description (100% coverage). The tool description adds significant value by pinpointing the exact source (get_rosters_preload → vacantDutiesOccupied.data.duties[].idVacantDuty), which is more actionable than the schema's generic mention of 'vacantDutiesOccupied or vacantDutiesAssumed'.

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 opens with a specific verb+resource: 'Returns full shift details for a single vacant duty entry.' This clearly distinguishes it from siblings like get_rosters_preload (which preloads a list) and get_abteilungsdienstplan (a department plan). The scope ('single vacant duty') is explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly instructs the agent to obtain idVacantDuty from get_rosters_preload and provides the exact response path. This gives a clear 'when to use' (after preloading). However, it does not explicitly mention when not to use or name alternative tools for different scenarios, so it falls short of a 5.

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. Dates show when Glama detected each change.

4 tool updatesv1.0.1Aug 6, 2026
- First observedget_abteilungsdienstplan
- First observedget_planungsgruppen
- First observedget_rosters_preload
- First observedget_vakante_duty_details

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.3/5.0

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

ActivitySlowing

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

classquill-mcp
io.github.EquateItAu
Read-only MCP server for ClassQuill, a tutoring-business-management platform.
Education & Learning Tools CRM
2
mcp-serverOAuth
io.klokin
MCP server exposing klokin time-tracking operations (employees, time entries, stores) to AI clients.
Workplace & Productivity Project Management
2
Sandwich Public Care Directory A
com.joinsandwich
Read-only MCP server for Sandwich aging-parent care resources and cost data.
Health & Wellness Government Data
32
ORANO MCP Server
io.github.infotik
Read-only MCP server exposing a user ORANO library to their own AI agent.
Note Taking Knowledge & Memory Search
1

Related MCP Servers

Constructoo MCP Server
CRM Project Management
fgambling
F
license
Not graded
quality
D
maintenance
Mock MCP server for validating Constructoo Copilot data access, exposing read-only tools like counting customer properties, retrieving project status, and fetching appointments.
Updated 4 months ago (2026-05-19 04:52 UTC)
-
wealify-kpi-mcp
Monitoring Finance
ngkienmkqn
F
license
A
quality
D
maintenance
Read-only MCP server for Wealify KPI dashboard that allows AI agents to query KPI data, scoring status, alerts, member performance, and rubric documents via predefined tools and REST endpoints.
Updated 3 months ago (2026-06-08 02:46 UTC)
13
-
deephr-mcp
ERP Systems Workplace & Productivity
leevydanomalik
F
license
Not graded
quality
C
maintenance
Read-only MCP server that proxies deepHR's API to MCP clients, enabling interaction with deepHR modules such as payroll and employees through natural language.
Updated 2 months ago (2026-06-24 02:10 UTC)
-
MOJAQofficial
Monitoring Observability
mojaqhq
A
license
Not graded
quality
B
maintenance
Read-only MCP server for MOJAQ: give any AI assistant natural-language access to your EU-hosted app's deploys, errors, logs, uptime and incidents.
Updated 2 months ago (2026-07-04 12:58 UTC)
16
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/jalibu/careman-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

@jalibu/careman-mcp

Setup

Open WebUI + Ollama ✅ Recommended (privacy-friendly)

Claude Desktop ⚠️ Cloud — data leaves your network

Environment variables

Tools

get_planungsgruppen

get_abteilungsdienstplan

get_rosters_preload

get_vakante_duty_details

Architecture

Notes

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

MOJAQofficial

Latest Blog Posts

MCP directory API

`get_planungsgruppen`

`get_abteilungsdienstplan`

`get_rosters_preload`

`get_vakante_duty_details`