Adeu vs MCP FactorialHR
A side-by-side look at the Adeu and MCP FactorialHR MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.
Verdict: choose Adeu for workplace & productivity work as a local process; choose MCP FactorialHR for workplace & productivity as a local process. You can also run both side by side in one mcpServers block.
Which MCP server should you choose?
Choose Adeu when
- You need dedicated capabilities in the Workplace & Productivity domain.
- You prefer a local stdio subprocess transport.
- Its auth model fits you: No auth required.
- You want tools like
accept_all_changes, apply_text_revision, diff_docx_files.
Choose MCP FactorialHR when
- You need dedicated capabilities in the Workplace & Productivity domain.
- You prefer a local stdio subprocess transport.
- You want tools like
factorial_discover, factorial_employees, factorial_teams.
Feature & specification comparison
Rows where the two servers differ are marked.
| Spec | ||
|---|---|---|
| Category | Workplace & Productivity | Workplace & Productivity |
| Quality signal | 71/100 · Great | 61/100 · Good |
| Install command | Confirmed | Confirmed |
| Transport | Local subprocess (stdio) | Local subprocess (stdio) |
| Auth | No auth required | Not declared |
| Pricing | Free | Not declared |
| Required env vars | None listed | None listed |
| Verified owner | Community listing | Community listing |
| GitHub stars | 168 | 3 |
| Directory activity | 5 views 0 installs 0 upvotes | 5 views 0 installs 0 upvotes |
| Tools | 6 | 14 |
| Full listing | View Adeu | View MCP FactorialHR |
Tools & capabilities
Adeu tools 6
accept_all_changesAccepts every tracked change in the document, producing a finalized clean document. remove_comments (boolean, DEFAULT TRUE): also delete every comment. The default is TRUE because this tool's purpose is a distributable clean document, and comments are internal review notes that must not travel to a counterparty. Pass remove_comments=false to accept the tracked changes while KEEPING the comments — use that when the review conversation is still live. Either way the response reports how many comments were deleted and names each one with its author, and comments whose anchored text an accepted deletion consumes are removed regardless, exactly as Word does. [Adeu v3.0.6+df9e00c]apply_text_revisionApplies whole-text revised text to a DOCX document by computing a diff and generating tracked changes. Includes a clean-text verification gate to ensure the applied document matches the supplied text. `revised_text` must be the complete CLEAN view of the document: read it with `read_docx` (`clean_view=true`, `page='all'`), edit that text, and send ALL of it back. Never CriticMarkup ({++, {--, {>>) — this tool diffs against the clean view, so markup tokens would land in the document as literal prose. Never one page of a paginated extract — everything absent from the text is applied as a tracked deletion. INTERLOCK: a revision that drops >50% of the characters (>75% for documents under 2000 characters) is refused unless you pass allow_major_deletions=true. If the applied document's clean text does not then match `revised_text`, NOTHING is written to output_path: a diagnostic copy is kept at <name>.unverified.docx and the call fails. output_path defaults to <name>_redlined.docx; an existing _redlined/_processed artifact is revised in place. [Adeu v3.0.6+df9e00c]diff_docx_filesCompares two DOCX files and returns a compact `@@ Word Patch @@` diff — Adeu's token-level, sub-word patch format — of their text content. Useful for analyzing differences between versions before editing. [Adeu v3.0.6+df9e00c]finalize_documentPrepares a document for external distribution or e-signature. Note: in this zero-dependency environment, protection_mode='encrypt' is unsupported and falls back to a native read-only lock; export_pdf and password are ignored. [Adeu v3.0.6+df9e00c]process_document_batchApplies a batch of edits and review actions to a DOCX. Batches apply SEQUENTIALLY: each change validates against state from prior changes. Valid changes apply when others fail (salvage default): response LEADS with `PARTIAL: applied K of N` listing unapplied changes. Pass partial=false for all-or-nothing. Each item in `changes` needs a `type`: 1. 'modify': search-and-replace. `target_text` must match uniquely (`match_mode`:'strict', default) — add context or set `match_mode`:'first'/'all'. Set `regex`:true for regex matching (groups in `new_text` as $1, $2…). `new_text` supports Markdown: '#'–'######' headings, '**bold**', '_italic_', '\n\n' paragraph split. Omit it (with a comment) to annotate without changing text; empty string deletes. Never write CriticMarkup manually — use `comment`. • EMPTY CELLS: blank cells carry `{#cell:<id>}` anchors — set `target_text` to the anchor and value in `new_text`. Pipes are display separators. 2. 'accept'/'reject': finalize or revert a tracked change by `target_id` (e.g. 'Chg:12'). 3. 'reply': reply to a comment by `target_id` (e.g. 'Com:5') with `text`. 4. 'set_field': fill a form field — `field` is its 'CC:<N>' id, tag or alias, `value` the text; list via `read_docx` `mode`:'fields'. Checkboxes take true/false, dates YYYY-MM-DD, dropdowns a listed option. Dual-writes bound stores. A locked/protected control refuses and names the override permitting it. 5. 'insert_row': add table row — `target_text` anchors on an existing row's text, `cells` holds cell values (left-to-right), `position` is 'above'/'below' (default below). 'delete_row': remove row matching `target_text`. Disk mode only. ID VOLATILITY: 'Chg:N'/'Com:N' ids shift between states — call `read_docx` before accept/reject/reply; never reuse ids from earlier turns. `author_name` sets Track Changes attribution; defaults to 'Adeu AI (TS)' when omitted. [Adeu v3.0.6+df9e00c]read_docxReads a DOCX file. Returns text with inline CriticMarkup for Tracked Changes and Comments: {++inserted++}, {--deleted--}, {==highlighted==}{>>comment<<}. Set clean_view=True for the finalized 'Accepted' text without markup. Modes: - 'full' (default): paginated body content. Use page=N to navigate. - 'outline': heading map only — start here for large docs to plan targeted reads. Defaults to L1-L2 headings; pass outline_max_level=3-6 to see deeper structure. - 'appendix': defined terms, anchors, and cross-reference targets. Consult before editing legal/technical docs to avoid breaking references. - 'changes' (mode='changes'): a ledger of every tracked change and comment (id, type, author, page, snippet) — start here for review work instead of reading pages. Filter with changes_author, page, and changes_offset. - 'fields' (mode='fields'): a ledger of every content control (ordinal, class, alias/tag, location, lock/binding state, current value) — start here to discover fillable fields. Paginate with fields_offset; `page` and `search_query` do not apply. `page`: a positive integer (1-indexed, default 1), a page RANGE like '2-6' (returns up to 8 pages in one call, then names the next range), or 'all'. Pages are synthetic length-based chunks sized for LLM consumption, NOT printed Word pages. In mode='full', page='all' returns the whole body with no page chrome; oversized documents are refused with an outline and a bounded-read recipe unless force=true. With `search_query`, `page` instead restricts matches to that page (default: search all pages). [Adeu v3.0.6+df9e00c]
MCP FactorialHR tools 14
factorial_discoverList available FactorialHR tool categories and their actions. Use this first to understand what operations are available.factorial_employeesManage employees: list, get, search, create, update, terminatefactorial_teamsManage teams: list, get, create, update, deletefactorial_locationsManage locations: list, get, create, update, deletefactorial_contractsContract and salary data: list, get with employee, filter by job role/levelfactorial_time_offManage leave requests: list, get, create, update, cancel, approve, reject, view types and allowancesfactorial_attendanceAttendance (registro horario): list/get/create/update/delete shift records, clock_in, clock_out and status for live clocking, gaps and audit to find days that do not match the contract, log_range / log_days to enter many days at once, and list_edit_requests / create_edit_request for days whose timesheet has already been signed off. Without date and time, clock_in and clock_out record the current moment; given both, they record the declared moment instead, for someone who forgot to clock and knows when they started or stopped. A declared moment in the future is refused before anything is sent, and clock_out with a declared moment is refused if nothing is open or if it would close a shift before it started. Bulk writes, writes for another employee and edit requests preview first: the call returns a plan and a confirmation_token, and nothing is written until the identical call is repeated with that token within 15 minutes. audit, gaps and every preview begin with a Data read line saying how much of the window was actually read; audit reports a day Factorial returned nothing for as no_contract_data, and log_range never writes such a day (log_days, which takes explicit dates, will). Times are HH:MM in company local time, applied by Factorial in the company zone; the server never converts. Declared time versus entry time: a shift carries two independent sets of timestamps. The declared working time is date, clock_in, clock_out and, for a shift that crosses midnight, reference_date; these are inputs, and they are what the attendance sheet and the hour totals show. Separately, Factorial sets created_at, updated_at, in_source and out_source on the server to record when and how the record was entered; they are read-only through this API and no action here can set or change them. For example, a record written on 2026-09-07 for 2024-01-02 09:59 comes back with date: 2024-01-02, clock_in: 09:59, created_at of 2026-09-07 and in_source: api; that is the correct and only correct outcome. Both facts are true at once: a backfilled record shows the real working day on the attendance sheet while Factorial's activity log shows it was entered later through the API.factorial_documentsDocument management: list folders, list/get documents, search, download (OAuth2 required for downloads)factorial_job_catalogView job roles and levelsfactorial_projectsProject management: projects, tasks, workers, time records. Full CRUD operations.factorial_trainingTraining programs, sessions, and enrollments. Full CRUD operations.factorial_work_areasManage work areas within locations- +2 more on the listing page
Ready-to-paste client configs
Paste either block (or both) into your client config, e.g. claude_desktop_config.json or ~/.cursor/mcp.json. We only show a config when the install command is confirmed.
Adeu
{
"mcpServers": {
"adeu": {
"command": "npx",
"args": [
"-y",
"@adeu/mcp-server"
]
}
}
}
MCP FactorialHR
{
"mcpServers": {
"mcp-factorialhr": {
"command": "npx",
"args": [
"-y",
"@t4dhg/mcp-factorial"
]
}
}
}
Frequently asked questions
Adeu is categorized under Workplace & Productivity and uses a local stdio subprocess. MCP FactorialHR belongs to Workplace & Productivity and uses a local stdio subprocess. Pick Adeu for workplace & productivity work and MCP FactorialHR for workplace & productivity.
Copy the mcpServers block from the config section on this page into your client's config (for example claude_desktop_config.json or ~/.cursor/mcp.json), then fully restart the client.
Adeu is listed as free. Auth: no auth required. MCP FactorialHR has no declared pricing — check the project's own site. If a server needs environment variables such as API keys, define them under the env key in your client's MCP config.
Yes. MCP clients support multiple servers: add adeu and mcp-factorialhr as separate keys in the same mcpServers object, and your assistant will call tools from either one.
On AllMCPs, Adeu has a quality signal of 71/100 (Great) with 5 views, 0 installs and 168 GitHub stars. MCP FactorialHR has 61/100 (Good) with 5 views, 0 installs and 3 GitHub stars.