What can you do with this server?

This server allows Claude to query your Lucca HR instance in natural language, providing read-only access to employee, department, and absence data. * List and search employees (lister-collaborateurs): Search for employees by first name, last name, or email; retrieve details such as ID, position, department, manager, seniority date, and trial period end dates. Can optionally include former employees. * List departments (lister-departements): Retrieve all departments/teams with their IDs and codes. Can filter to active departments only. * List absences (lister-absences): View absences (paid leave, RTT, etc.) over a date range, filtered by a specific employee ID or department ID. Results are returned per half-day. * Track leave consumption (consommation-conges): Calculate the number of absence days taken by type (paid leave, RTT, etc.) over a period for an employee or department. Note: this reflects consumption, not remaining balance. A typical workflow involves calling lister-collaborateurs to find an employee's ID, then using that ID with lister-absences or consommation-conges to view their absences or leave consumption.

How do I use satelia-mcp-lucca?

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., "@satelia-mcp-lucca Qui est absent dans l'équipe Sales cette semaine?" 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.

satelia-mcp-lucca

by Para-FR

Overview Schema Related Servers Score Discussions

TypeScript

Remote

satelia-mcp-lucca

Un serveur MCP (Model Context Protocol) qui permet a Claude d'interroger votre instance Lucca en langage naturel : lister les collaborateurs, les departements, consulter les absences et la consommation de conges par type.

🚀 Vous installez le projet sur votre Mac ? Suivez le guide pas a pas : SETUP.md.

C'est quoi ?

Un serveur MCP est un petit programme qui ajoute des « outils » a Claude. Une fois branche a Claude Desktop, vous pouvez demander a Claude d'utiliser ces outils pendant une conversation (ex. « Qui est absent la semaine prochaine dans l'equipe Sales ? »).

Ce serveur expose 4 outils, en lecture seule :

lister-collaborateurs — liste / recherche les salaries (par prenom, nom ou email) et donne, pour chacun : identifiant, poste, departement, manager, date d'anciennete, fin de periode d'essai et fin de 2nde periode d'essai (renouvellement). Par defaut, les anciens collaborateurs (contrat termine) sont masques.
lister-departements — liste les departements (services / equipes) avec leur identifiant et leur code.
lister-absences — liste les absences (conges, RTT, etc.) sur une periode donnee, pour un collaborateur (via son id) ou un departement (via son id).
consommation-conges — calcule les jours d'absence PRIS par type (conges payes, RTT, recuperation…) sur une periode, pour un collaborateur ou un departement. NB : c'est la consommation, pas le solde restant (l'API Lucca n'expose pas les soldes).

Enchainement typique : Claude appelle d'abord lister-collaborateurs pour trouver l'id d'une personne, puis lister-absences avec cet id.

Related MCP server: HR MCP Server

Prerequis

Node.js version 18 ou superieure (node --version). Sinon : https://nodejs.org (version « LTS »).
Un acces a l'API Lucca : le sous-domaine de votre instance et une cle API.

Installation

npm install
npm run build

Si tout va bien, un dossier build apparait (build/index.js, build/lucca.js).

Acces Lucca (important)

Le serveur ne contient aucun secret. Les acces sont lus dans des variables d'environnement :

Variable	Role	Exemple
`LUCCA_INSTANCE`	le sous-domaine de votre instance : `https://<ICI>.ilucca.net`	`satelia`
`LUCCA_API_KEY`	votre cle API (Parametres Lucca → Cles API)	`xxxxxxxx-xxxx-...`
`LUCCA_BASE_URL`	(optionnel) URL complete, pour surcharger (ex. environnement de test)	`https://satelia.ilucca-test.net`

Pour recuperer une cle API : dans Lucca, Parametres → Cles API → creer une cle (une cle dediee par integration, avec le role/perimetre minimal necessaire).

Pour un test rapide en local, copiez .env.example en .env (ignore par git) et remplissez vos acces.

Connecter le serveur a Claude Desktop

Claude Desktop lit un fichier de configuration ou vous declarez vos serveurs MCP.

macOS : ~/Library/Application Support/Claude/claude_desktop_config.json
Windows : %APPDATA%\Claude\claude_desktop_config.json

Ajoutez votre serveur dans mcpServers (remplacez le chemin et la cle). La cle va dans le bloc env, jamais dans le code :

{
  "mcpServers": {
    "satelia-mcp-lucca": {
      "command": "node",
      "args": ["/chemin/absolu/vers/satelia-mcp-lucca/build/index.js"],
      "env": {
        "LUCCA_INSTANCE": "satelia",
        "LUCCA_API_KEY": "votre-cle-api"
      }
    }
  }
}

Pour obtenir le chemin absolu, lancez pwd dans le dossier du projet et ajoutez /build/index.js.

Fermez puis rouvrez Claude Desktop. Essayez : « Liste-moi les departements Lucca » ou « Qui est absent en juillet dans l'equipe Sales ? ».

Note : apres toute modification du code, relancez npm run build puis redemarrez Claude Desktop.

Tester

Un smoke test verifie que le serveur demarre, expose les 3 outils, et — si les acces Lucca sont dans l'environnement — fait un vrai appel a l'API :

# sans acces : test structurel seulement
node test/smoke.mjs

# avec acces (charge le .env local) : test + vrais appels
set -a; . ./.env; set +a; node test/smoke.mjs

Pour explorer visuellement les outils :

npm run build
npx @modelcontextprotocol/inspector node build/index.js

Ajouter votre propre outil

Tout se passe dans src/index.ts, dans le bloc bien visible :

// ====== AJOUTEZ VOTRE OUTIL ICI ======

Copiez un des outils existants (ex. lister-departements), adaptez le nom, la description (en francais), les champs d'entree (inputSchema) et l'appel luccaFetch(...), puis relancez npm run build. Le client Lucca (src/lucca.ts) gere deja l'authentification et les erreurs.

Commandes utiles

npm run build : compile le projet dans build.
npm run start : lance la version compilee.
npm run dev : lance directement le code source (pratique en developpement).
node test/smoke.mjs : smoke test.

Licence

MIT. Voir le fichier LICENSE.

Available Tools

3 tools

lister-absencesLister les absencesA

Liste les absences (conges, RTT, etc.) sur une periode donnee, pour UN collaborateur (via son id) OU pour un departement (via son id). Les dates sont au format AAAA-MM-JJ. Chaque ligne correspond a une demi-journee.

ParametersJSON Schema

Name	Required	Description
`fin`	Yes	Date de fin de la periode, au format AAAA-MM-JJ (ex. 2026-01-31).
`debut`	Yes	Date de debut de la periode, au format AAAA-MM-JJ (ex. 2026-01-01).
`limite`	No	Nombre maximum de demi-journees a renvoyer (defaut 500, max 1000).
`departementId`	No	Identifiant (id) du departement dont on veut les absences. Utiliser lister-departements pour le trouver.
`collaborateurId`	No	Identifiant (id) du collaborateur dont on veut les absences. Utiliser lister-collaborateurs pour le trouver.

TDQS

A4.2/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. It discloses that it lists absences (read operation) and that each line is a half-day. Lacks details on authentication or limits beyond the limit parameter.

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?

Very concise two sentences, front-loaded with main purpose, no unnecessary words.

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?

Given no output schema, description explains output format (each line is a half-day) and date format. Includes limit parameter details. Could improve by mentioning default sorting or that the two ID parameters are mutually exclusive.

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% with good descriptions, and the description adds value by clarifying the exclusive use of collaborateurId or departementId and linking to sibling tools for ID lookup. Cannot score 5 because description does not explicitly state that the parameters are mutually exclusive.

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 it lists absences over a period for one employee or one department, distinguishing it from sibling tools that list employees or departments.

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?

Specifies that the tool can be used with either employee ID or department ID, and mentions how to find those IDs using sibling tools. However, does not explicitly state when not to use it.

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

lister-collaborateursLister les collaborateursA

Liste les collaborateurs (salaries) de l'instance Lucca. Permet de rechercher une personne par prenom, nom ou email et de recuperer son identifiant (id), utile pour ensuite consulter ses absences.

ParametersJSON Schema

Name	Required	Description
`limite`	No	Nombre maximum de collaborateurs a renvoyer (defaut 50, max 1000).
`recherche`	No	Texte a rechercher dans le prenom, le nom ou l'email (ex. 'Dupont' ou 'marie'). Laisser vide pour tout lister.
`inclureAnciens`	No	Inclure aussi les anciens collaborateurs (contrats termines). Par defaut false.

TDQS

A3.7/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It explains that the tool lists and searches collaborators, and that the ID is useful for absences. However, it does not disclose the return format (beyond ID), pagination behavior, or ordering. For a simple tool, this is acceptable but not exhaustive.

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 very concise: two sentences that efficiently cover purpose and a specific use case. Every sentence is necessary and adds value without redundancy.

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's simplicity (3 optional parameters, no output schema), the description is mostly complete. It explains the main function and a key use case. However, it lacks explicit mention of the return structure (e.g., which fields are returned besides id) and pagination details, leaving some gaps for a fully self-contained description.

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 has 100% description coverage, so the baseline is 3. The description adds minimal extra meaning beyond the schema: it reiterates the search fields (prenom, nom, email) and the utility of the ID. It does not provide new parameter semantics beyond what the schema already offers.

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 it lists collaborators (salaries) of the Lucca instance and allows searching by first name, last name, or email to retrieve an ID. This distinguishes it from sibling tools like lister-absences and lister-departements, which handle different resources.

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 the tool is used to find a collaborator's ID for later consulting absences, but it does not explicitly state when to use this tool versus alternatives or provide exclusions. There is no mention of when not to use it or what to do if results are empty.

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

lister-departementsLister les departementsA

Liste les departements (services / equipes) de l'organisation Lucca, avec leur identifiant (id) et leur code. Utile pour filtrer les absences par departement.

ParametersJSON Schema

Name	Required	Description	Default
`actifsSeulement`	No	Ne garder que les departements actifs. Par defaut true.

TDQS

A3.8/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It does not disclose any behavioral traits such as read-only nature, destructive potential, authorization requirements, or side effects. The description only states the function without additional transparency.

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 two sentences, front-loaded with the main action, and contains no unnecessary words. Every sentence adds value.

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?

The description explains what is returned (id and code) and provides a use case. Given the tool's simplicity (single optional parameter, no output schema), it is mostly complete. Missing details like pagination or default behavior, but these are not critical for this 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?

Schema coverage is 100% with one parameter. The description does not add meaning beyond the schema's description for 'actifsSeulement'. Baseline 3 is appropriate as the schema already documents the parameter.

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 tool lists departments with their ID and code, and specifies the organization (Lucca). It differentiates from siblings by mentioning it's useful for filtering absences, which implies distinct function from lister-absences and lister-collaborateurs.

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 provides a specific use case (filtering absences by department), giving context for when to use this tool. However, it does not explicitly state when not to use it or compare with siblings beyond the mention.

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.

3 tool updatesv0.1.0Jul 8, 2026
- First observedlister-absences
- First observedlister-collaborateurs
- First observedlister-departements

Install Server

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

TDQS

A3.9/5.0

Disambiguation5/5

Each tool targets a distinct entity: absences, collaborators, and departments. There is no overlap as they handle different data types, making disambiguation straightforward for an agent.

Naming Consistency5/5

All tools follow a consistent 'lister-' verb-noun pattern in French, with clear and predictable naming. No mixing of conventions.

Tool Count4/5

With only 3 tools, the server is focused and uncluttered. The count is slightly below typical ranges but appropriate for a minimal read-only HR data access server.

Completeness3/5

The set covers listing of three core entities, but lacks write operations (create, update, delete) and more advanced filters. For a read-only server it's acceptable, but there are notable gaps in full lifecycle coverage.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

GitHub Repository

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

hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237
mcp COAuth
com.wix
A Model Context Protocol server for Wix AI tools
Developer Tools Content Management Systems App Automation
216
Artificial Wit AIOAuth
com.artificialwit
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
ERP Systems CRM Knowledge & Memory
2
Apideck MCP A
dev.apideck.mcp
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
Developer Tools
42

Related MCP Servers

MCP Expert Server
Documentation Access API Testing
crazyrabbitLTC
A
license
Not graded
quality
D
maintenance
A Model Context Protocol server utilizing Claude AI for generating intelligent queries and offering documentation assistance based on API documentation analysis.
Updated 2 years ago (2025-01-07 04:20 UTC)
19
3
MIT
HR MCP Server
Databases Search
gabrielrojasnyc
A
license
D
quality
D
maintenance
A Model Context Protocol server that enables Claude Desktop to access structured employee data and perform HR operations including employee lookups, searches, and global leave requests.
Updated a year ago (2025-03-30 18:09 UTC)
3
1
MIT
Gong MCP Server
API Testing Documentation Access
kenazk
A
license
B
quality
D
maintenance
A Model Context Protocol server that allows Claude to access Gong's API for retrieving call recordings and transcripts through a standardized interface.
Updated 2 months ago (2026-07-09 04:09 UTC)
2
76
39
MIT
MCP Oracle Server
Databases Search
anpy-j
A
license
B
quality
D
maintenance
A Model Context Protocol server that enables Claude to access and interact with Oracle databases through natural language queries.
Updated a year ago (2025-04-30 07:06 UTC)
3
2
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/Para-FR/satelia-mcp-lucca'

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